Write Design Brief
Frame a design problem clearly enough that the right solution can be recognized when it appears.
Why This Is Best Practice
Adopted by: IDEO, Frog Design, Stanford d.school, D&AD award-winning agencies — design brief is the foundational artifact of professional design practice
Impact: IDEO research across 200+ projects found that projects with a clear brief delivered in the first week had 3× higher stakeholder satisfaction and 40% fewer major revision cycles
Why best: A brief is not a specification — it frames the problem without prescribing the solution. A brief written too narrowly produces safe, obvious solutions. A brief written too broadly produces unfocused exploration. The brief's job is to create useful creative tension.
Steps
- Write the challenge statement — One sentence framing the design problem as a human need, not a product feature. Use "How might we…" format: "How might we help first-time homebuyers understand mortgage options without feeling overwhelmed?"
- Define the target audience — Describe the primary user with specificity: demographic context, behavioral patterns, existing tools, and emotional state during the task. Include one composite persona or real user quote.
- State the desired outcome — What change in user behavior or experience defines success? Write two metrics: one quantitative (task completion rate, time-on-task) and one qualitative (user sentiment, confidence).
- List constraints — Technical (platform, browser, accessibility standards), business (brand guidelines, budget, timeline), and contextual (regulatory, localization). Constraints are not enemies — they focus creativity.
- Document what is out of scope — Explicitly name what this project will not solve. Out-of-scope decisions prevent scope creep and misaligned expectations after kickoff.
- Identify success signals — How will you know the design is working? Name the research method (usability test, A/B test, NPS) and the threshold that constitutes success.
- Get sign-off from key stakeholders — Before design begins, have product, engineering, and business leadership read and sign the brief. Disagreements surface now rather than in design review.
Rules
- The challenge statement must describe a human problem, not a business goal or a feature request.
- Constraints must be real — do not pad the brief with assumed constraints that haven't been confirmed.
- The brief is a living document through discovery; freeze it before moving to ideation.
- Anyone reading the brief should be able to evaluate proposed solutions independently — it must be self-contained.
- Length target: 1–2 pages. A longer brief signals the problem is not yet understood.
Examples
Bad brief: "Redesign the onboarding flow to improve conversion."
Good brief: "How might we help new users experience the core value of the product within their first 5 minutes, so they feel confident enough to invite a teammate? Success = 60% of new users complete core workflow Day 1 (up from 31%); users describe the experience as 'clear' in post-onboarding survey (target: 70%)."
Common Mistakes
- Solution-as-brief — "Design a dashboard with X, Y, and Z features" is a spec, not a brief; it skips problem framing and eliminates creative exploration.
- No constraints — "The sky is the limit" produces unfocused exploration and solutions that cannot ship; real constraints sharpen design thinking.
- No stakeholder sign-off — A brief approved only by design leads to stakeholders redirecting the project mid-execution based on expectations that were never aligned.
When NOT to Use
- Do not write a formal design brief for small, well-scoped changes (e.g., updating a button label or fixing a broken form layout) where the problem, audience, and success criterion are already unambiguous to all parties.
- Do not use a brief as a substitute for discovery research — if the team does not yet have enough user insight to write a meaningful challenge statement, conduct exploratory research first rather than inventing a brief around assumptions.
- Do not write a brief for work where the solution is contractually or technically predetermined — if engineering constraints or a client specification have already defined the output, a brief framing it as open exploration creates false expectations about design latitude.