← Go Back

Design Brief

What is a design brief?

A design brief is a short document that defines the problem, audience, scope, success signal, and constraints for a design project — before any design work starts. It creates a shared agreement between Design, Engineering, and Stakeholders so everyone is solving the same thing.

Use it when: you're kicking off a new feature, redesign, or experiment — any time more than one person needs to align on what's being built, why, and for whom.

A design brief is not the same as a detailed spec. It's the contract that makes the spec easier to write.

Copy/paste template

Fill in each field before the kickoff. Leave nothing blank — gaps signal that the scope isn't ready.

Project name:   [Short name for the feature or project]
Problem:        [One or two sentences: what's broken, for whom, and why it matters]
Audience:       [Who this is primarily for — be specific: "returning B2B admin users", not "users"]
Scope:          [What is included. What is explicitly out of scope.]
Success signal: [How you'll know it worked — one measurable outcome + time window]
Constraints:    [Non-negotiables: legal, technical, brand, time, budget, dependencies]
Stakeholders:   [Who approves the final design]
Timeline:       [Key milestones: brief → designs → review → handoff → launch]

Example filled brief:

Project name:   Simplified checkout flow
Problem:        Returning customers are abandoning checkout at the shipping cost reveal step
                (61% completion rate vs 74% industry benchmark). Revenue impact: ~£42k/month.
Audience:       Returning customers on mobile (54% of checkout sessions)
Scope:          IN: Cost summary display, order total formatting, shipping options component.
                OUT: Payment methods, guest checkout, address book.
Success signal: Checkout completion rate increases from 61% to 70% within 4 weeks of launch.
Constraints:    Must work within the existing component library. Cannot change payment processor.
                GDPR: no new data collection. Launch target: end of Q2.
Stakeholders:   Head of Product (approves scope), CTO (approves technical constraints)
Timeline:       Brief → Apr 3 | Designs → Apr 17 | Review → Apr 24 | Handoff → May 1

Why design briefs matter

  • Prevent rework: the brief surfaces scope disagreements before designs exist, not after three review rounds.
  • Give Design clear authority: when constraints are explicit, designers can move fast without second-guessing boundaries.
  • Align Engineering early: technical constraints in the brief mean fewer "that's not buildable" conversations at handoff.
  • Create accountability: a success signal in the brief means the project has a definition of done beyond "shipped."

What a good design brief is not

This is not a brief What it actually is
A wireframe or mockup A deliverable the brief defines
A design spec The detailed breakdown that follows the brief
A project proposal A case for why to start; a brief assumes the work is approved
A list of features Features are solutions; a brief frames the problem and scope
A requirements document An exhaustive list; a brief is a one-pager that unlocks the spec

Weak vs strong examples

Weak brief (redesign project):
"Redesign the onboarding flow to improve activation."

What's wrong: no problem definition, no audience specifics, no scope, no success signal, no constraints. This is a task, not a brief.

Strong brief (same project):
"New users who sign up via paid ads are leaving before completing setup (32% activation within 7 days vs 58% for organic). The brief covers the first 3 steps of onboarding for new B2C users on mobile web. Success: 32% → 45% within 6 weeks. Out of scope: in-app onboarding, email sequences, desktop. Constraint: must use existing UI components."

Weak brief (feature: empty state redesign):
"Make empty states nicer and more helpful."

What's wrong: "nicer" is not a design goal, there's no audience, no scope, and no measurable outcome.

Strong brief:
"First-time users who land on an empty dashboard have a 68% 1-day retention rate vs 81% for users who see content. Brief covers: empty state for Projects, Tasks, and Inbox. Success: 1-day retention for new users reaches 75% within 4 weeks. Constraint: copy changes only for email notifications (not in scope for Engineering this quarter)."

Who owns the design brief?

Usually the Design Lead or Product Manager writes the first draft, but the brief is only complete when all named stakeholders have signed off. Engineering must review the constraints section before design begins.

If no one owns the brief, no one owns the scope — and the scope will expand.

How a design brief connects to the rest of the process

Problem Statement → Design Brief → Design Sprint (if high risk/unknown)
                                  → Specifications (wireframes, prototypes, component list)
                                  → Engineering handoff
                                  → Success metric review (post-launch)

A problem statement is the diagnosis; a design brief is the prescription (problem + scope + constraints + success signal). You need both.

Common pitfalls

  • Writing the brief after designs have started: the brief becomes a post-hoc justification. → Do this instead: treat the brief as the gate before any design work begins.
  • Leaving constraints blank: "TBD" means legal, technical, or brand concerns surface at handoff. → Do this instead: list every known constraint; if genuinely unknown, flag it and add a date to resolve.
  • Vague success signal: "better engagement" → Do this instead: name the metric, baseline, target, and time window. If you can't, the scope needs more definition.
  • Brief owned by one person: if only the PM reads it, Design flies blind. → Do this instead: brief review is a 30-minute meeting with Design, Engineering, and one business stakeholder.
  • No "out of scope" section: scope creep starts here. → Do this instead: be explicit about what this brief does not cover, not just what it does.
  • Design brief vs problem statement: the problem statement defines the user issue; the brief adds scope, constraints, and stakeholder alignment around a specific project.
  • Design brief vs design spec: the brief is a one-pager that unlocks the spec. The spec (wireframes, component breakdowns, interactions) comes after the brief is agreed.
  • Design brief vs PRD (Product Requirements Document): a PRD is typically longer and more formal; a brief is leaner and used more often in design-led teams.
  • Problem statement – the diagnosis that feeds into the brief's "Problem" field.
  • Design sprint – use a sprint when the brief surfaces high unknowns before committing to build.
  • User stories – the brief scope often becomes a set of user stories for the backlog.
  • Success metrics – the brief's "success signal" becomes your project success metric.
  • Feature prioritisation – briefs make prioritisation easier by making scope and value explicit.
  • Design review framework – the brief defines what the design review should evaluate against.

Next step

Before your next design project starts, fill in the brief template above. If you get stuck on the "Problem" field, read Problem statement first. If the brief reveals too many unknowns to proceed safely, read Design sprint — a sprint is the right next step when the risk is high and the answer is unclear.

Related Terms