A PM's job in design collaboration is to define the problem, the constraints, and the rules a UI must obey — not the pixels that satisfy them. You own interaction logic: what happens on error, on empty, on loading, on the fourth click of a double-submit. The designer owns visual execution within your constraints and the design system's rules.
Quick Answer: PMs specify behavior — states, rules, edge cases, and acceptance criteria. Designers specify form — layout, visual hierarchy, and system-compliant components. The spec is where the two meet, and it should describe interactions precisely enough that an engineer never has to guess.
Where the PM's Job Ends and the Designer's Job Begins
The boundary sits at the pixel. A PM defines what the interface must do — the states, rules, and outcomes — while a designer defines how it looks and feels within a design system's constraints. The moment a PM starts specifying corner radii, font weights, or exact spacing, they've stopped adding rigor and started duplicating work a system already governs.
This isn't a turf argument; it's a division of labor that makes both jobs faster. A PM who tries to art-direct slows the designer down and produces worse UI, because they're overriding a system built for consistency with one-off judgment calls. A designer who tries to define business rules without the PM's context produces UI that looks clean and behaves wrong.
The table below is a working boundary, not a legal contract — teams flex it based on trust and seniority. But it's a useful default when a project starts and nobody has agreed on lanes yet.
| Concern | PM owns | Designer owns |
|---|---|---|
| Problem and user need | Yes — defines the "why" | Consumes it |
| Interaction rules (what happens on click, submit, error) | Yes | Partially — refines feel |
| Information architecture (what fields, what order) | Yes | Partially — groups visually |
| Visual hierarchy, layout, spacing | No | Yes |
| Component selection from the system | Recommends | Decides |
| Color, typography, iconography | No | Yes — governed by design tokens |
Accessibility target (e.g. WCAG 2.1 AA) | Sets the requirement | Implements against it |
| Empty, loading, and error states | Defines the state and its intent | Visualizes it |
| Acceptance criteria | Yes | No |
Notice what's missing from the "PM owns" column: nothing about how it looks. A PM can and should sketch a rough wireframe to communicate intent quickly — our PM's guide to responsive wireframing covers how to do that without it being mistaken for a real design. But a wireframe is a communication tool, not a deliverable, and treating it as one is where the boundary usually gets crossed first.
If you're specifying font weights in a spec, you've stopped doing your job and started doing someone else's — badly.
What a Design-Ready UI Specification Actually Contains
A design-ready UI spec answers five questions before a designer opens Figma: what problem this solves, who hits it and when, what the system must do in every state, what "done" looks like, and what's explicitly out of scope. Skip any one of these and the designer fills the gap with a guess — which becomes rework once you see it.
Here's a minimal but real structure, using a generic example from a project-tracking tool's export feature:
### Feature: Bulk export of filtered task list
**Problem:** Power users managing 200+ tasks need to export the
current filtered view to CSV for offline analysis. Today they
screenshot or copy-paste, which drops the applied filters and
truncates any field over ~255 characters.
**Trigger:** User clicks "Export," visible only when the result
set is non-empty.
**Behavior:**
- Export respects the currently applied filters and sort order —
not the full unfiltered list.
- Export is capped at 10,000 rows. Above that, show a warning and
export the first 10,000 in current sort order.
- File is named `{project-name}-export-{yyyy-mm-dd}.csv`.
- Long text fields export unabridged, quoted per standard CSV
escaping (`RFC 4180`).
**Out of scope for v1:** scheduled/recurring exports, export
formats other than CSV, exporting archived tasks.
That's four short paragraphs and it already resolves the questions engineers actually ask in standup: what happens above 10k rows, what's the file called, does it respect my filters. None of that requires a single opinion about layout — which is exactly what separates a real UI specification from a wish list dressed up in Figma comments.
Turning Behavior Into Acceptance Criteria
The spec's prose sets intent; acceptance criteria make it testable. Write them in Given/When/Then form — borrowed from behavior-driven development — so QA and engineering can check a box instead of interpreting a paragraph.
| ID | Given | When | Then |
|---|---|---|---|
| AC-1 | Filtered view has 0 records | Export button renders | Button is disabled, tooltip reads "No records to export" |
| AC-2 | Filtered view has 1–10,000 records | User clicks Export | CSV downloads with exactly those records, in current sort order |
| AC-3 | Filtered view has >10,000 records | User clicks Export | Warning modal shows "Exporting first 10,000 of {n}"; export proceeds on confirm |
| AC-4 | A field contains a comma or line break | CSV is generated | Value is wrapped in double quotes per RFC 4180 |
| AC-5 | Export is in progress | User navigates away | Export continues in background; completion triggers a notification |
Five rows, and there's no ambiguity left for either engineering or QA to resolve on their own. That's the actual bar: could someone build this without asking you a clarifying question? If not, the spec isn't done — as we cover in more depth in a PRD writing masterclass for the AI era, where "testable" is the line between a document and a wish list.
Working With a Design System Without Trying to Own It
This is where design-system PM collaboration usually breaks down: treating the system as a set of assets to raid instead of a shared vocabulary to speak fluently. A PM's job is to know what components exist, what states they already support, and what a genuinely new component costs the team — in design review time, in engineering build time, in long-term maintenance. Request deviations deliberately, never by accident.
Brad Frost's Atomic Design methodology — atoms, molecules, organisms, templates, pages — is the mental model most modern design systems (Google's Material Design, IBM's Carbon, Atlassian's system) are built on. Understanding it changes how a PM asks for things. Instead of "make this card bigger," you learn to ask "is there an existing organism for this, or are we requesting a new one?"
That distinction matters because every new component is a liability, not just a design decision. A one-off button style outside the system means:
- A designer has to create and document it.
- Engineering has to build and maintain a component nothing else reuses.
- Every future redesign or rebrand has to remember it exists.
- Accessibility, responsive behavior, and dark-mode support all have to be solved again from scratch.
A PM who understands this asks a different first question in design review — not "can we tweak this," but "does this already exist in the system, and if not, is it worth the debt?" That's a product decision, and it's squarely a PM's to make.
When It's Legitimate to Ask for Something New
Sometimes the system genuinely doesn't have what the problem needs, and asking for a new pattern is the right call, not scope creep. It's worth it when:
- The interaction is core to the product's differentiation, not incidental.
- Existing components would force a genuine usability compromise, not just an aesthetic one.
- The pattern will recur across multiple features, justifying the investment in documenting it properly.
If none of those apply, the answer is almost always: reuse what exists.
Specifying Edge Cases and States Design Often Skips
Most UI mockups show the happy path — populated, mid-range, first-viewed. A PM's real value is enumerating everything that isn't that, because those are the states that ship broken when nobody wrote them down. Design tools default to showing "good" data; specs are where the rest gets decided.
Before signing off on any UI, walk it against a standard state checklist:
- Empty state — zero records, first-time use. What does the user see and what's the call to action?
- Loading state — how long before a spinner becomes a skeleton screen, and what happens on timeout?
- Error state — network failure, validation failure, server error. Are these visually distinct?
- Partial data — some fields populated, some null. Does layout break?
- Permission-denied — user can see the entry point but not act on it. Hide it or show it disabled?
- At-limit — the export-cap example above; what happens at the boundary, not just below it?
- Extreme content length — a 200-character name, a title with no spaces to wrap on.
- Offline or degraded connectivity — does the action queue, fail silently, or block?
- Concurrent edits — two users acting on the same record at once.
Which of these are even possible is a data question before it's a UI question — a nullable field, a many-to-many relationship, or a soft-deleted record all create states a designer can't guess at from a mockup alone. Our PM's guide to reviewing a data model covers how to map that out before you're stuck retrofitting states after launch.
Nielsen Norman Group's usability research — dating back to Jakob Nielsen's original heuristics in the 1990s and reaffirmed in the group's ongoing studies — consistently finds that error prevention and visibility of system status are among the heuristics most often violated in production software. Both are PM-owned problems wearing a design costume: they're failures of specification, not failures of visual taste.
How PMs and Designers Should Actually Collaborate
The best PM-designer collaboration looks like a shared problem, not a handoff. The PM briefs the problem, constraints, and success criteria; the designer explores solutions; the PM reviews against the acceptance criteria, not their own aesthetic preference; they iterate together until both are satisfied. Handoff-style collaboration — spec thrown over a wall, design thrown back — is where trust and quality both erode.
Marty Cagan's writing at the Silicon Valley Product Group popularized the term "empowered product teams" for a reason: teams where PM, design, and engineering solve a problem together consistently outperform teams where each function executes a queue handed to them by the last one. That's not a process nicety — it changes what gets built.
A few habits separate teams that collaborate well from teams that just coexist:
- Review designs by asking "what happens when X," not "can we move this button." The former is your job; the latter is usually not.
- Bring constraints early, not as feedback on a finished mockup. A designer who learns about a technical or business constraint after three rounds of exploration has wasted real time.
- Let the designer push back on your spec. A rule that's unenforceable in the design system, or that creates a worse experience than an alternative, should change — that's the exploration doing its job, not a failure of the spec.
- Separate "I don't like it" from "it doesn't meet the criteria." Only the second is a legitimate blocker at review.
None of this requires the PM to learn design tools deeply. It requires the PM to show up to design review having already done their job — the states, the rules, the edge cases — so the conversation is about the interface, not about information the PM forgot to supply.
Keeping the Spec in Sync as Design Evolves
A spec that's accurate on the day it's written and stale a week later is worse than no spec, because engineers keep building against it without realizing it's wrong. Design iterates after the PM writes the first draft — new states get discovered, edge cases get renegotiated — and the spec has to move with it or it silently becomes fiction.
The discipline that actually holds is treating the spec as a living document, not a snapshot: one place where requirements, acceptance criteria, and open questions get updated as decisions change, with a visible trail of what changed and why. Our guide on keeping a PRD always current goes deeper on why static, once-written specs are the norm that quietly breaks most teams.
This is the exact gap Prodinja's Spec Studio is built around: it maintains a living PRD — requirements, acceptance criteria, and open questions in one structured document you can edit and version as the spec evolves, rather than a document that's accurate once and stale forever after. It doesn't replace the judgment calls in this article; it's designed to make the resulting spec easier to keep honest as design and engineering both push back on it.
Key Takeaways
- The boundary is behavior versus form. PMs specify what the UI must do — states, rules, outcomes; designers specify how it looks within the design system.
- A wireframe is a communication tool, not a deliverable. Sketch to convey intent; let the designer own the actual layout and visual hierarchy.
- Acceptance criteria, not prose, are what make a spec buildable.
Given/When/Thenformat removes the ambiguity a paragraph leaves behind. - Every new component outside the design system is a liability, not just a design choice — it costs design, engineering, and every future redesign.
- Most broken UI comes from unspecified edge cases, not bad visual design — empty, error, at-limit, and permission states need to be enumerated, not assumed.
- Collaboration beats handoff. Bring constraints early, review against criteria not preference, and let the spec change when the design process surfaces something the PM missed.
- A spec that isn't kept current is actively misleading — treat it as a living document, not a one-time artifact.
Frequently Asked Questions
Does a PM need to know how to use Figma?
No — a PM doesn't need production skill in a design tool, only enough fluency to read a file, leave precise comments, and sketch a rough wireframe when words alone are ambiguous. Depth in Figma is the designer's job; depth in the problem and its rules is yours.
What's the difference between a PRD and a UI specification?
A PRD is the broader document covering problem, goals, and success metrics for a feature; a UI specification is the more granular layer inside or alongside it, detailing every state, rule, and acceptance criterion the interface must satisfy. Most well-run teams treat the UI spec as a section of the living PRD, not a separate artifact that can drift from it.
Who owns accessibility — the PM or the designer?
Both, at different points. The PM sets the requirement (typically WCAG 2.1 AA, which includes concrete criteria like a 4.5:1 contrast ratio for body text), and the designer and engineer implement against it — but if the PM never states the target, accessibility becomes optional by default rather than a requirement.
How detailed should acceptance criteria be for a UI feature?
Detailed enough that engineering and QA never have to guess your intent — as a rule of thumb, if someone could reasonably build two different, defensible interpretations of a criterion, it's not specific enough yet. Given/When/Then format at the level shown earlier in this article is a reasonable default for most features.
What should a PM do if a designer disagrees with the spec?
Treat it as useful signal, not a challenge to resolve by authority — a designer pushing back has usually spotted a constraint that's unenforceable in the design system or a rule that creates a worse experience than an alternative. Revisit the acceptance criteria together; if the designer is right, the spec should change, not the design.