write-design-brief

name	write-design-brief
description	Use when starting a design project, commissioning design work, or aligning stakeholders before any visual design begins
source	IDEO Design Kit (Human-Centered Design); Stanford d.school Design Brief framework; D&AD Brief Writing Guide
tags	["design-brief","ux","problem-framing","design-process","stakeholder-alignment","project-initiation"]
verified	true

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

1. 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?"
2. 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.
3. 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).
4. List constraints — Technical (platform, browser, accessibility standards), business (brand guidelines, budget, timeline), and contextual (regulatory, localization). Constraints are not enemies — they focus creativity.
5. 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.
6. 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.
7. 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.