A great design brief states the user, the problem, the constraints, and what success looks like, then stops. It does not describe the screen. Give designers a tightly bounded problem and the freedom to solve it, and you get exploration; give them a spec dressed up as a brief, and you get compliance.
Quick Answer: A good design brief covers user, problem, jobs-to-be-done, constraints, success metrics, and explicit non-goals. It never specifies layout, components, or UI patterns. If your brief could be handed to two different designers and produce two genuinely different (both valid) solutions, you've written a brief, not a spec.
Why Most "Design Briefs" Are Actually Specs in Disguise
Most documents PMs call design briefs are secretly wireframes written in prose. They describe a modal, a dropdown, a three-step flow, and a button label, then call it "context." The designer's job shrinks to picking colors and spacing for a decision the PM already made.
This happens for an understandable reason: PMs think in solutions because they've been staring at the problem longest and a solution shape has already formed in their head. Writing it down feels like helpful specificity. It's actually the opposite of what a brief is for.
A brief and a spec solve different problems in the product lifecycle:
| Design brief | Design spec | |
|---|---|---|
| When it's written | Before design exploration starts | After design direction is chosen |
| What it fixes | Problem, user, constraints, success | Screens, states, components, copy |
| What it leaves open | The solution | Nothing (by design) |
| Who "owns" the content | PM + designer, jointly framed | Designer, PM reviews |
| Failure mode if wrong | Designer builds the wrong thing | Designer builds the wrong thing anyway, just faster |
Notice the shared failure mode. A precise spec written too early doesn't protect you from building the wrong thing, it just lets you build it with more confidence. The brief is the checkpoint that's supposed to catch that before pixels get spent. If you skip straight to spec-thinking, you've skipped the one step designed to prevent expensive rework.
There's a related trap worth naming directly: over-specification isn't a tone problem, it's an information problem. A brief that says "add a confirmation modal before the user deletes a project" has quietly decided the interaction pattern (modal, not inline undo, not a two-step button, not a soft-delete with a recovery window) without ever stating the actual constraint, which is something closer to "deletion must be hard to do accidentally and easy to reverse for at least 24 hours." State the constraint. Let the designer find the pattern.
The Six Things a Brief Must Define, and Only These
A design brief that gets you good design covers exactly six things: user, problem, jobs, constraints, success metrics, and non-goals. Nothing about screens, components, or visual direction belongs here — that's the designer's territory, informed by everything above it.
1. User: who, specifically
"Users" is not a user. Name the segment, their context, and their relationship to the product at the moment this problem occurs. "A freelance bookkeeper managing 12 client accounts, checking status mid-commute on a phone" gives a designer something to design toward. "Our users" gives them nothing.
If you have more than one meaningfully different user for the same problem, say so and rank them. Designers need to know whose experience wins a tradeoff, because tradeoffs are guaranteed. Grounding this in real behavioral and needs data, not assumption, is the difference between a persona and a caricature; the jobs-to-be-done-complete-guide on JTBD interviewing is worth revisiting before you write this section.
2. Problem: the friction, not the fix
State what's currently broken, confusing, slow, or anxiety-inducing, from the user's point of view, in one or two sentences. Not "we need a better onboarding flow" (that's already a solution category), but "new users can't tell whether their first action succeeded, so 40% repeat it or abandon."
A useful test: if your problem statement contains a UI noun (modal, tab, card, dropdown), you've drifted into solution territory. Rewrite it without one.
3. Jobs-to-be-done: what the user is hiring the product to do
This section separates a brief that produces genuinely useful design from one that produces decoration. Frame the problem as a job: the functional outcome the user needs, plus the emotional and social dimensions around it (Clayton Christensen's Jobs-to-be-Done framing, later formalized by Tony Ulwick's outcome-driven innovation work, is the clearest lineage here).
- Functional job: what task needs to get done ("confirm the payment went through")
- Emotional job: what the user needs to feel ("confident, not anxious, that money moved correctly")
- Social job: how this reflects on the user to others, if relevant ("looks competent to their client")
A designer who understands the emotional job might solve "confirm payment succeeded" with a moment of calm reassurance rather than a terse success toast, a solution you'd never have specified yourself, and a better one. For the deeper mechanics of translating jobs into design decisions, the jobs-to-be-done-complete-guide walks through the full method, and pairing it with a customer-journey-complete-guide view helps you place the job in the moment it actually occurs.
4. Constraints: the real boundaries, stated as boundaries
Constraints are the load-bearing wall of a good brief, they're what keeps "freedom" from becoming "no direction at all." List every hard boundary: technical (what the current data model can and can't support), regulatory (accessibility, data residency, financial compliance), timeline, platform (must work at 320px, must work offline), and brand.
Constraints should read like a fence around a field, not a floor plan of the house you want built inside it.
Common constraint categories worth checking every time:
- Technical — API limitations, existing component library, performance budgets
- Accessibility — WCAG conformance target, keyboard-navigation requirements
- Platform — device sizes, offline behavior, input methods (touch vs. mouse vs. voice)
- Business/legal — compliance requirements, brand guidelines, existing commitments to customers
- Timeline — hard external deadlines versus soft internal ones (say which is which)
If you're unsure whether something is a real constraint or a preference wearing a constraint's clothes, ask whether violating it would actually break something. If not, it's a preference, note it separately and mark it negotiable.
5. Success metrics: how you'll know it worked
Define the metric before design starts, not after you see the mockups and decide what to measure. A metric stated up front discourages arguing backward from "I like this design, so let's call it a success." Tie it to behavior, not aesthetics: task completion rate, time-to-first-success, error/abandonment rate, support-ticket volume on the flow, not "feels cleaner."
Where possible, state a current baseline and a target direction, even a directional one ("currently ~35% of first-time uploads fail silently; we want that meaningfully lower, not a specific percentage promised in advance"). Nielsen Norman Group's usability heuristics remain a useful lens for translating a vague success feeling into something observable and testable, rather than a matter of taste.
6. Non-goals: what you are explicitly not asking for
This is the most underused section in most briefs, and often the one that saves the most rework. State what's out of scope this round: "not solving multi-user permissions in this pass," "not redesigning the navigation shell," "not addressing the desktop experience yet." Non-goals prevent scope creep from both directions, a designer padding the solution and a stakeholder later asking "why doesn't this also fix X."
The Over-Specification Anti-Pattern, and How to Catch It in Your Own Draft
Over-specification happens when a brief describes the solution instead of the problem, and it's almost always well-intentioned: the PM is trying to be helpful, specific, and unambiguous. The result is a designer who either complies with a mediocre idea or has to reverse-engineer the actual problem before they can improve on it.
Here's what it looks like in practice, side by side:
| Over-specified (a spec wearing a brief's clothes) | Properly scoped (a real brief) |
|---|---|
| "Add a banner at the top of the dashboard warning about expiring trials" | "Trial users don't realize they're about to lose access until it's too late, and support gets a spike of confused cancellation requests in the final 48 hours" |
| "Use a stepper component for the 4-step signup" | "New users need to understand where they are in setup and that it's short; current signup has a 22% drop-off between steps 2 and 3" |
| "Put a tooltip on the icon explaining what it does" | "Users can't tell what this control does without trial and error, and the icon has no accompanying label anywhere in the flow" |
The tell, in every left-column example: it names a UI element. The right-column version names a user, a behavior, and a consequence, and leaves the element entirely open. Before sending a brief, re-read every sentence and flag any that contains a UI noun, run the "if I deleted this sentence, would the designer still know the problem?" test, and if the sentence only tells them what to build, cut it.
Over-specification also tends to hide unexamined assumptions about the user's mental model. A tooltip assumes the user will hover; a stepper assumes the user cares about step count more than time-to-done. Getting comfortable naming and questioning those assumptions is core design literacy for a PM, not something to outsource entirely to the design team; design-literacy-fundamentals-pms is a good primer if this instinct doesn't yet feel natural.
How to Give Feedback Once Design Comes Back, Without Re-Specifying
The brief's discipline has to survive the review meeting too, or you've just moved the over-specification problem two weeks downstream. Good brief-writing and good critique are the same skill applied at different points: react to whether the problem was solved, not to your personal solution preference.
When a design comes back, check it against the brief itself, not against the mockup you privately imagined:
- Does it solve the stated problem for the stated user, in their stated context?
- Does it respect every constraint, or does it quietly violate one (a pattern that won't work at 320px, a flow that assumes always-online)?
- Does the success metric move, or is there a plausible story for why it would, even before you can measure it?
- Did it stay inside the non-goals, or has scope crept back in?
If your reaction is "I'd have done it differently," that's not automatically useful feedback, it might just be a preference. If your reaction is "this doesn't address the emotional job we identified," that's a real, brief-grounded critique. The distinction between a legitimate critique and an overreach into the designer's craft deserves its own discipline; design-critique-pm-without-overstepping covers exactly where that line sits. Related, a design that technically works but taxes the user's attention to parse is its own kind of failure to catch early, which is what cognitive-load-simple-screen-overwhelms is useful for diagnosing.
The Design Brief Template
Below is a compact template you can copy directly. Keep every section short; a brief that runs past one page has usually smuggled solution detail back in.
DESIGN BRIEF: [feature/problem name]
1. USER
Who, specifically, experiences this problem? Segment, context, device.
2. PROBLEM
1-2 sentences. No UI nouns. What's broken from the user's point of view?
3. JOBS-TO-BE-DONE
Functional job:
Emotional job:
Social job (if relevant):
4. CONSTRAINTS
Technical:
Accessibility:
Platform:
Business/legal:
Timeline (hard vs. soft):
5. SUCCESS METRICS
Current baseline (if known):
Target direction:
How/when we'll measure it:
6. NON-GOALS
Explicitly out of scope for this round:
OPEN QUESTIONS FOR DESIGN
[Questions you genuinely don't know the answer to, don't fake certainty here]
Notice the template has no field for "proposed solution" or "reference screenshots." If you have inspiration references, share them separately as mood or pattern inspiration, labeled clearly as optional input, not embedded in the brief itself where they'll get read as instructions.
Where This Brief Lives as the Project Evolves
A brief isn't a document you write once and archive, it needs to stay current as constraints shift, metrics get refined, and the problem itself gets sharper through design exploration. Treating it as a living artifact rather than a one-time handoff is what actually keeps design and PM aligned past kickoff.
This is the gap Prodinja's Spec Studio is built to close: it holds the problem statement, constraints, success criteria, and readiness status in one evolving document, with PR-style diffs so you can see exactly what changed between the brief you wrote and the one the team is now building against. Rather than a brief and a PRD drifting apart in separate tools, the same living document can carry the brief's discipline all the way through to hand-off.
Key Takeaways
- A brief defines the problem's boundaries, not its solution: user, problem, jobs, constraints, success metrics, and non-goals, nothing about screens or components.
- Over-specification is an information problem, not a tone problem: a brief containing a UI noun ("modal," "dropdown," "tooltip") has usually smuggled in a solution instead of stating the real constraint.
- Jobs-to-be-done (functional, emotional, social) reveals design opportunities a plain problem statement can't, because it explains why the current experience fails, not just where.
- Constraints should read as a fence, not a floor plan: state technical, accessibility, platform, business, and timeline boundaries explicitly, and mark which are hard versus soft.
- Success metrics belong in the brief before design starts, tied to observable behavior (completion rate, error rate, time-to-success), not to how a mockup feels.
- Non-goals prevent scope creep in both directions, protecting against both over-building and later "why doesn't this also fix X" requests.
- Critique the delivered design against the brief itself, not against a mockup you privately imagined, that's the same discipline that kept the brief solution-agnostic in the first place.
Frequently Asked Questions
What's the difference between a design brief and a PRD?
A design brief is narrower and earlier: it frames one problem for design exploration (user, jobs, constraints, success metrics). A PRD is broader and typically covers the full feature, including engineering scope, rollout plan, and dependencies. Many teams keep the brief as a section inside a living PRD rather than a separate document.
How long should a design brief be?
One page, or roughly 300-500 words, is a reasonable ceiling for most features. If it's running longer, you've likely drifted into describing the solution rather than the problem, which is the exact anti-pattern the brief exists to avoid.
Should a PM include reference screenshots or competitor examples in a brief?
Only as clearly labeled, optional inspiration, kept separate from the core brief sections. Embedded inline, references get read as implicit instructions ("build something like this") even when that's not the intent, undermining the freedom the brief is supposed to preserve.
Who should write the design brief, PM or designer?
The PM typically drafts it since they hold the user research, business constraints, and success metrics, but it should be reviewed and refined jointly with the designer before work starts. A designer catching a hidden solution assumption during that review is the process working as intended, not a failure of the draft.
What if engineering constraints aren't known yet when the brief is written?
State that explicitly as an open question rather than guessing or omitting it. "Technical constraint: unknown, pending API feasibility check" is more useful to a designer than silence, because it flags a decision point instead of letting them design around an assumption that later turns out to be wrong.