Write a design brief

Outcome

A one-page design brief, signed off by the people who own the decision. It states why the project exists now, the goal, the users it serves, what is in and out of scope, the constraints, what will be handed over and when, and the measure that will show whether it worked. Everyone who starts design work reads the same page.

When to use it

• A project is about to start and the people involved describe it differently.
• Several stakeholders will judge the result, and you want them to agree on the problem before they see a design.
• The work is large enough that changing direction halfway would be expensive.

When not to use it

• The change is small and one person owns it end to end. A ticket with acceptance criteria is enough.
• Nobody yet knows what the problem is. Do the research first; a brief written now will be guesswork with a signature.
• The project is already in design and the brief would be written to justify decisions already made.

Before you start

• The owner. The person who will sign the brief off and decide when the project is done.
• Inputs. Whatever explains the problem: research findings, a persona, a journey map, analytics, support tickets.
• People. The owner and the leads for design, engineering and anyone else who will judge the result.
• Time. An hour to draft and one meeting to agree.
• The template. Open the Design Brief Template in Figma or print the PDF.

Steps

Step 1: Write why the project exists now

In two or three sentences, describe the problem and the evidence for it, and say why it matters now rather than next quarter.

You should now have: a short background that names the problem and its evidence.

Step 2: State one goal and how it will be measured

Write the goal as a change in what users do or achieve, not as a feature. Add the measure and the target, such as first-week activation rises from 40% to 50%. If you have several goals, rank them.

You should now have: a ranked goal with a measure and a target.

Step 3: Name the users

Say who the work is for, as specifically as you can: a persona, a segment, a role. Name who it is not for if that will be argued about.

You should now have: a named primary user and, where needed, who is out.

Step 4: Set the scope and constraints

List what is in scope and what is explicitly out. Add the hard limits: deadline, budget, platforms, technical or legal constraints. Writing down what is out prevents the most arguments later.

You should now have: an in-scope list, an out-of-scope list and the constraints.

Step 5: List the deliverables and dates

Write what will be handed over, in what form, and when: for example, tested prototype by week 4, final designs and specs by week 6. Add the checkpoints where stakeholders will review.

You should now have: deliverables with dates and review checkpoints.

Step 6: Get it signed off

Send the draft to the owner and leads, then meet to agree it. Change the brief until everyone can sign it as written, and record who signed and when. From now on, a change of scope means changing the brief.

You should now have: a signed brief that everyone starting design has read.

Worked example

A food delivery app wants to reduce how often new customers abandon their first order.

1. Background: a third of new customers who add something to the basket leave at the address step. Interviews show people do not trust the delivery-time estimate until they have entered an address.
2. Goal: more new customers complete a first order. Measure: first-order completion for new customers rises from 52% to 60% within six weeks of launch.
3. Users: first-time customers on mobile. Returning customers are out, because their saved address skips the step.
4. In scope: the address step and the delivery estimate before checkout. Out of scope: payment, restaurant listings, the courier app. Constraints: the address service cannot change this quarter; launch before the holiday campaign.
5. Deliverables: tested prototype in week 3, final designs and copy in week 5. Reviews at the end of weeks 1 and 3.
6. The product owner, design lead and engineering lead sign it. In week 2, a request to redesign payment is refused because payment is out of scope, and goes to the next brief instead.

Checklist

• The background names the problem and the evidence for it.
• The goal is a change for users, with a measure and a target.
• The primary user is named.
• Out-of-scope items are written down, not only in-scope ones.
• Constraints, deliverables and dates are on the page.
• The brief fits on one page.
• The owner and leads have signed it, with the date.

Common mistakes

• Writing a solution as the goal. Redesign the checkout is a deliverable. The goal is what changes for the user.
• No measure. Without one, nobody can say whether the project worked, and the argument moves to taste.
• Leaving out what is out of scope. Every unlisted item becomes a request halfway through.
• Signing without reading. A brief agreed by email reply-all is not agreed. Meet once.
• Never updating it. When the scope changes and the brief does not, the team works to two different documents.

Related

• Design Brief Template: the one-page brief and a matching user story template.
• Create a user persona: the user the brief names.
• Create a customer journey map: find the moment the brief should fix.