A practical guide to writing design briefs that align teams, prevent scope creep, and survive contact with real project constraints.
A design brief is the document that sits between "we should do something about this" and "here is what we are actually building." When it is done well, every person on the team can explain the project's purpose, boundaries, and success criteria without checking Slack. When it is done poorly, which happens far more often, the brief becomes a formality that nobody reads after the kickoff meeting.
The difference between a useful brief and a decorative one usually comes down to specificity. Vague briefs attract scope creep. Specific briefs create alignment. This guide walks through each component of a design brief, explains why it matters, and provides a fill-in structure you can adapt to your own projects.
Before covering what goes into a good brief, it helps to understand the three most common failure modes. First, the brief is written too early, before the team has done any empathy work, so it encodes assumptions rather than insights. Second, the brief is written by one person in isolation, usually a project manager or product owner, so the rest of the team treats it as someone else's document rather than a shared commitment. Third, the brief tries to do too much, combining strategic objectives, technical specifications, and creative direction into a single unwieldy document that nobody reads end to end.
In a design thinking context, the brief should come after the{" "} Define stage, once you have a clear problem statement and enough user insight to frame the project meaningfully. Writing the brief earlier risks locking in the wrong problem.
Not every brief needs every section. A two-week internal sprint needs less formality than a six-month product redesign. But these eight components cover the questions that consistently cause confusion when left unanswered.
1. Background and context. Two to three sentences that explain why this project exists now. What changed in the market, the user research, or the business that makes this work necessary? Link to the relevant research artifacts if they exist. This section prevents the "why are we doing this again?" conversation three weeks in.
2. Problem statement. The single sentence that defines what you are trying to solve. If you have gone through a proper{" "} How Might We process, use the winning HMW question here. If not, write a sentence that names the user, their unmet need, and the insight that makes this problem interesting. Refer to{" "} problem statement examples for models to follow.
3. Target audience. Who specifically are you designing for? Avoid "everyone" or "all users." Name the primary persona and, if relevant, the secondary persona whose needs you will accommodate but not optimize for. If you have built{" "} user personas, reference them here.
4. Goals and success metrics. What does success look like, and how will you measure it? Separate business goals (increase conversion by 15%) from user goals (reduce time to complete checkout to under 90 seconds). Each goal needs a metric, a baseline, and a target. Without these, you cannot evaluate your prototype during{" "} user testing.
5. Scope and constraints. What is included and what is explicitly excluded? Name the technical constraints (must work on iOS 15+), the business constraints (cannot change the pricing model), and the timeline constraints (prototype by March 15). Being explicit about what is out of scope prevents more arguments than being explicit about what is in scope.
6. Competitive and market context. What do competitors do, and where are the gaps? A brief{" "} competitive analysis summary here prevents the team from unknowingly reinventing something that already exists in the market.
7. Key stakeholders and approvers. Who needs to be consulted, and who has final approval? Use a simple RACI (Responsible, Accountable, Consulted, Informed) format. This is where stakeholder mapping pays off.
8. Timeline and milestones. Major dates only, not a detailed project plan. Research complete by X. Concepts presented by Y. Prototype testing by Z. Final delivery by W. Four to six dates are enough.
Here is a stripped-down template you can copy into your preferred tool. Replace the bracketed text with your specifics.
Design Brief: [Project Name] Background: [2-3 sentences on why this project exists now] Problem: How might we [verb] for [user] so that [outcome]? Audience: Primary: [persona name and one-line description]. Secondary: [persona or "none"]. Goals: Business: [metric] from [baseline] to [target] User: [metric] from [baseline] to [target] In scope: [list] Out of scope: [list] Constraints: [technical, business, timeline] Competitive context: [2-3 sentences or link to full analysis] Approvers: [names and roles] Milestones: [Date]: Research complete [Date]: Concepts presented [Date]: Prototype testing [Date]: Final delivery
The template above is for a mid-size product design project. Other contexts require adjustments. For a one-week design sprint, compress the brief to a single page and focus on the problem statement, the sprint questions, and the decision-maker. For an agency project, add sections on brand guidelines, deliverable formats, and revision rounds. For an internal innovation project, add a section on how success will be measured if the idea moves to a pilot phase.
In enterprise settings, briefs often need to satisfy governance requirements. Add a section on data privacy considerations, legal review status, and alignment with existing product strategy. The brief becomes longer, but each section earns its place by preventing a specific type of delay later in the project.
Describing solutions instead of problems. A brief that says "build a chatbot for customer support" has already skipped the design thinking process. The brief should say "reduce average resolution time for billing questions from 12 minutes to 3 minutes" and let the team discover whether a chatbot, a better FAQ, or a redesigned billing page is the right solution.
Listing features instead of outcomes. Feature lists belong in product requirements documents, not design briefs. The brief defines the problem and the criteria for success; the features emerge from the ideation and prototyping process.
Writing in isolation. A brief created by one person and emailed to the team is a memo, not an alignment tool. The most effective briefs are co-created in a working session where the team discusses and negotiates each section. This takes an hour but saves weeks of misalignment.
A design brief is a living document, but it should not change constantly. The right moments to revisit and update the brief are: after completing user research that contradicts initial assumptions, after a pivot in project direction, and after stakeholder feedback that changes the scope. Each update should be versioned and shared with the full team, not silently edited.
The brief sits at a critical junction in the design thinking process. It codifies the output of the Define stage into a form that can guide the Ideate and Prototype stages. Without it, teams tend to drift: the researcher thinks the project is about one thing, the designer thinks it is about another, and the engineer thinks it is about a third.
Once your brief is locked, the next question becomes which assumptions are riskiest and should be tested first. That is where{" "} assumption mapping picks up, giving you a systematic way to prioritize what to prototype. If you are working in a context where the brief needs to persuade leadership, the guidance in{" "} presenting design thinking results will help you frame the brief as part of a larger narrative about why this work matters.
Related guides: dot voting prioritization · problem statement examples · design thinking templates
Design Thinker Labs Home · All Guides · How It Works · Pricing