Design Brief Template

What This Template Is For

A design brief is the handoff document between product and design. It gives the designer everything they need to start working: the problem, who it affects, what constraints exist, what success looks like, and when the work is due. Without one, design work starts with a vague verbal request, the first iteration misses the mark, and two rounds of revision later, both the PM and the designer are frustrated.

The best design briefs are concise. They frame the problem without prescribing the solution. A PM who writes "add a sidebar with three tabs" has skipped the designer and gone straight to implementation. A PM who writes "users cannot find their recent activity and are dropping off before completing their second session" has given the designer room to solve the actual problem. The brief should make the designer smarter about the problem, not constrain their solution space.

This template works for any design project: new features, redesigns, micro-interactions, and design system components. It pairs well with the user persona template for grounding design decisions in real user archetypes and the customer journey map template for understanding the full flow a user moves through. For teams doing structured product discovery, the design brief is typically the output of a discovery sprint and the input to a design sprint.

How to Use This Template

1. Fill in the Problem Context first. Copy relevant data from user research, support tickets, and analytics. The designer should understand the severity and frequency of the problem without having to ask follow-up questions.
2. Define the target users by linking to existing personas or writing a brief description. Include behavioral context: what are they trying to accomplish when they encounter this problem?
3. List hard constraints upfront. Technical limitations, brand guidelines, accessibility requirements, and timeline restrictions all shape the design space. Surfacing them early prevents wasted exploration.
4. Write success criteria as measurable outcomes. "Better onboarding" is not a success criterion. "New users complete setup within 3 minutes and reach their first key action within 5 minutes" is.
5. Specify deliverables and timeline. Be explicit about whether you need wireframes, high-fidelity mockups, a prototype, or production-ready assets. Include review checkpoints so feedback happens incrementally.
6. Share the brief with the designer in a 15-minute walkthrough. Answer questions, clarify context, then let them work.

The Template

Project Overview

One-line summary. [What needs to be designed and why, in one sentence.]

Problem Context

What is the problem? [Describe the user pain point in concrete, observable terms. What are users doing today? What goes wrong? What feedback have you received?]

Evidence.

• [Data point: metric, support ticket volume, session recording insight]
• [Data point: user interview quote or survey result]
• [Data point: competitive gap or benchmark]

Impact. Quantify the business impact: churn rate, drop-off %, support cost, revenue at risk. Link to relevant [product metrics if available.]

What does the current experience look like? [Screenshots, links to the current flow, or a brief description of the existing UI. The designer needs to see what exists today before proposing changes.]

Target Users

Secondary users. [Any other user types affected by this design, e.g. admins, teammates, external collaborators]

Constraints

Technical constraints:

• ☐ [e.g., Must work within existing component library]
• ☐ [e.g., No new backend API endpoints available this sprint]
• ☐ [e.g., Must support mobile viewports (375px+)]

Brand and style constraints:

• ☐ [e.g., Follow existing design system tokens]
• ☐ [e.g., Must maintain accessibility (WCAG 2.1 AA)]
• ☐ [e.g., Dark theme only / light theme only / both]

Business constraints:

• ☐ [e.g., Cannot change pricing page layout (legal review required)]
• ☐ [e.g., Must preserve existing URL structure]
• ☐ [e.g., Feature flag rollout required]

Timeline constraints:

• ☐ [e.g., Wireframes needed by [date] for engineering estimation]
• ☐ [e.g., Final mockups due by [date] for sprint planning]

Success Criteria

Qualitative success. [What does "good" look like from a user experience perspective? e.g., "Users should be able to complete setup without referring to documentation."]

Scope

In scope:

• [Specific screen, flow, or component to design]
• [Specific screen, flow, or component to design]
• [Specific interaction or state to address]

Out of scope:

• [Adjacent area explicitly not being redesigned]
• [Future phase work]
• [Edge case being deferred]

Inspiration and References

• [Link to competitor feature or design pattern worth studying]
• [Link to internal design that sets a good precedent]
• [Link to design system component to reuse or extend]
• [Screenshot or Figma link showing an approach the team has discussed]

Deliverables and Timeline

Review process. [How will feedback be given? e.g., async Figma comments, scheduled design review, Slack thread]

Open Questions

Filled Example: Onboarding Flow Redesign

Project Overview

One-line summary. Redesign the post-signup onboarding flow to reduce time-to-first-value and increase 7-day activation from 34% to 50%.

Problem Context

What is the problem? New users sign up, land on an empty dashboard, and do not know what to do next. 66% of signups never complete a key activation action (creating their first project) within the first 7 days. Session recordings show users clicking around the nav for 30-60 seconds, then leaving. The current onboarding is a 5-step wizard that asks for profile information (company size, role, use case) but does not guide users toward creating their first project or inviting teammates.

Evidence.

• 7-day activation rate: 34% (industry benchmark for B2B SaaS: 45-55%)
• Average time from signup to first project creation: 4.2 days (for users who activate)
• NPS for users in their first 30 days: 18 (vs. 52 for users past 90 days)
• Top support ticket category for new users: "How do I get started?" (23% of week-1 tickets)
• 4 of 5 churned trial users in exit interviews said "I didn't understand how to use it"

Impact. Each percentage point of activation improvement is worth approximately $18K ARR based on current trial-to-paid conversion rates and average contract value. Moving from 34% to 50% activation would add an estimated $288K ARR annually.

What does the current experience look like? [Link to Figma: current onboarding flow screenshots. 5 screens: Welcome, Company Info, Role Selection, Use Case, Empty Dashboard.]

Target Users

Secondary users. Invited teammates who join via email link (they skip the wizard but still land on an empty state and need orientation).

Constraints

Technical constraints:

• ☑ Must use existing React component library (no new dependencies this sprint)
• ☑ Backend already supports project creation API. No new endpoints needed for core flow
• ☑ Mobile responsive required (40% of signups start on mobile)
• ☑ Must work with existing analytics events (Amplitude). Can add new events but cannot rename existing ones

Brand and style constraints:

• ☑ Follow design system v2 tokens (color, typography, spacing)
• ☑ WCAG 2.1 AA compliance required
• ☑ Dark and light theme support

Business constraints:

• ☑ Cannot remove the company size question (used for lead scoring by sales)
• ☑ Must preserve the existing signup URL structure (SEO)

Timeline constraints:

• ☑ Wireframes due March 12 for engineering estimation
• ☑ Final mockups due March 22 for sprint 14 planning

Success Criteria

Qualitative success. A new user should create their first project and see meaningful content on their dashboard within 5 minutes of signing up. They should never encounter an empty state without a clear next action.

Scope

In scope:

• Post-signup wizard (reduce from 5 steps to 3, move profile questions to settings)
• First-run experience on dashboard (guided project creation, sample data option)
• Empty states for all core screens (projects, tasks, team)
• Invited teammate onboarding (condensed flow, skip company info)

Out of scope:

• Signup page design (separate project, not changing)
• Pricing page or plan selection
• Email onboarding drip sequence (marketing owns this)
• Admin setup flow for Enterprise accounts (Phase 2)

Inspiration and References

• Linear's onboarding: imports existing issues from Jira during setup, giving users an immediate populated workspace
• Notion's template gallery: lets new users start from a template instead of a blank page
• Figma's first-run: walks users through creating a simple design in under 2 minutes using inline tooltips
• Our own "project template" feature (existing, underutilized) could be promoted during onboarding

Deliverables and Timeline

Review process. Async feedback via Figma comments on wireframes. Synchronous 30-minute design review for the selected direction. Jordan will run 5 usability tests with new signups before finalizing.

Common Mistakes to Avoid

• Prescribing solutions instead of framing problems. "Add a tooltip on the dashboard" is an implementation detail. "Users don't know what to do after signup" is a problem statement. Write the problem. Let the designer propose solutions.
• Skipping the evidence section. A design brief without data is a feature request. Include metrics, user quotes, and session recording insights so the designer can make informed trade-offs.
• Leaving success criteria vague. "Improve the onboarding experience" cannot be measured. "Increase 7-day activation from 34% to 50%" can. Define measurable targets before design starts.
• Forgetting to specify constraints. If the designer does not know about mobile requirements, accessibility standards, or technical limitations, they will design something that needs to be reworked. Surface constraints early.
• Treating the brief as a contract. The brief frames the problem and constraints. The designer may discover through exploration that the scope should shift. Build in review checkpoints so you can adjust the brief as you learn.

Key Takeaways

• Frame the problem, not the solution. The brief makes the designer smarter about the problem space
• Include quantitative evidence so the designer can make informed trade-offs
• Surface all constraints (technical, brand, business, timeline) before design starts
• Define measurable success criteria, not vague goals
• Build in review checkpoints so feedback happens incrementally, not in one big reveal

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use