Design Brief: The Document That Aligns Before You Design

What is it for?

It is for avoiding a debate about the problem after you have already designed the solution. Many projects fail not because the design is bad, but because two people understood the goal differently. The brief forces that shared understanding into writing.

Dovetail explains that the design team and the client typically put the brief together in collaboration (Dovetail: What is a design brief?). Asana adds that both parties should agree on the scope and that both should review and approve the final document before work begins (Asana: Design brief). That approval is not a formality: it is the moment the scope gets fixed.

What should it include?

Dovetail, Maze, and Asana propose a similar core. A practical version has these sections:

1. Context and problem. What happens today and why it matters. One or two sentences are enough if the problem is clear.
2. Purpose and objectives. What the project must achieve. Asana poses the question “what metrics will we use to measure success?” and points to SMART goals.
3. Audience. Who uses the product and what they need. If you already have proto-personas or research, link them here.
4. Scope and deliverables. What is designed and what is not. Dovetail recommends setting scope up front so you can negotiate when changes appear.
5. Constraints. Time, budget, technology, brand, and accessibility. Constraints are the ones that prevent the most arguments.
6. Competitors and references. What others do and what you take as a starting point. Dovetail, Maze, and Asana all include a competitor analysis.
7. Stakeholders. Who decides, who approves, and who is consulted.
8. Success criteria. How you will measure whether the work succeeded.
9. Schedule. Delivery dates and key review points.

What makes an objective useful?

A brief objective is not “improve the experience.” It is something like “raise appointment confirmations from 60% to 75% within six weeks.” Figma’s creative brief guide suggests SMART objectives: specific, measurable, achievable, relevant, and time-bound.

For the objective to be useful, the brief should also say what happens if it is not met. Writing that line in advance avoids deciding under pressure at the last review.

How is it different from a creative brief?

The sources do not agree on the boundary. Figma says a creative brief sets the strategic foundation of the project and a design brief builds on it with specific technical and visual requirements. Dovetail describes the creative brief as covering the goals and key messaging of the whole project, and the design brief as focused on the visual side. Asana, by contrast, places the design brief in pre-production and the business side, and leaves creative execution to the creative brief.

With no standard, the practical rule is to ask the client or agency which document they expect and what it should contain.

Who writes and approves it?

It depends on the organization. Dovetail presents it as joint work between design and the client, and Asana says it can be client-led, designer-led, or collaborative. Figma’s creative brief guide says the project manager usually owns it, gathering input from stakeholders, and that budget and timeline should be approved by their superiors. What matters is that someone is responsible for closing it, and that everyone who signs knows what they are approving.

When is a long brief the wrong choice?

• For a small change to an existing component, a four-page brief is out of proportion. A three-line note with the problem and a success criterion is enough.
• If the brief is written after the design, it works as a justification, not as alignment. When that happens, the document only records decisions already made.
• If no one on the team can make decisions about scope, the brief becomes a wish list with no owner.

Dovetail notes that a brief is usually one or two pages long. That length is a good limit: if it keeps growing, you may be mixing two projects.

Illustrative example

Illustrative example: an insurance company wants customers to report a claim from their phone. The design brief states that the problem is that 40% of reports come in by phone, because the app does not clearly show the photo step. The objective is for 30% of reports to be filed in the app within three months. The audience is people who had an accident in the last two weeks, short on time and stressed. The constraints are that the payments system is not touched and that the flow meets WCAG 2.2 AA. The scope covers the reporting flow, not payments. The success criteria are the share of reports filed in the app and the average photo upload time. All of this fits on one page and lets the team say no to a last-minute request: adding live chat, which moves to the next phase.

Once the brief defines the problem, the next step is usually research to validate it, followed by research synthesis. If the flow has many steps, a wireflow shows the path before the final design exists.

Common mistakes

• Writing vague objectives such as “be more modern.”
• Not fixing the scope, so every review adds screens.
• Leaving constraints for the end, when they can no longer change.
• Signing a brief without stakeholders knowing what they are approving.
• Forgetting success criteria and then not knowing, at the end, whether the project worked.
• Writing the brief after the design and treating it as if it had guided the decisions.

What you can do tomorrow

1. Take the last project you started without a brief and write its problem and success criterion on one page.
2. Before your next kickoff meeting, send a draft with one measurable objective and ask for corrections.
3. Next to each constraint, write who can change it. If nobody can, it is a real constraint.

Sources

• Dovetail: What is a design brief?
• Maze: How to write a powerful design brief in 9 easy steps
• Asana: Design brief, how to write one
• Figma Resource Library: How to write a creative brief