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.