How to Write a Design Brief for a SaaS Product

The quality of a design output is determined as much by the quality of the brief as by the quality of the designer. A good designer with a bad brief will produce the wrong design well. A bad designer with a clear brief will at least produce something in the right direction.

For SaaS founders — particularly non-technical ones who are briefing a designer for the first time — writing a good brief is a skill that pays dividends across every design engagement. This guide explains what goes in a brief, what doesn't, and how to frame problems without over-specifying the solution.

The Core Principle: Brief the Problem, Not the Solution

The most common briefing mistake is describing the design you want rather than the problem you're trying to solve.

"The button should be blue and larger, above the fold" is a solution brief. It describes the answer without explaining the question — and it locks the designer into implementing your hypothesis rather than finding the best solution.

"Users are scrolling past the main CTA without clicking — we think it's not visible enough, but we're not sure" is a problem brief. It describes what's happening, gives the designer relevant context (your hypothesis), and leaves room for them to propose a solution that may or may not be a blue button above the fold.

Problem briefs produce better design for a specific reason: designers bring knowledge of patterns and solutions that founders typically don't have. A designer who understands the problem can evaluate whether your hypothesis is right and propose a better solution if it isn't. A designer given a solution can only implement it.

The Five Elements Every Design Brief Should Have

1. The problem in one or two sentences

What is happening that shouldn't be, or not happening that should? Be specific:

❌ "The onboarding needs improvement." ✅ "Our onboarding flow has a 58% drop-off rate before users reach the activation moment (setting up their first project). The biggest drop occurs at step 4, the integrations setup step."

The specifics matter because they give the designer context to understand the priority. A 58% drop-off at step 4 is a different design problem from a 10% drop-off distributed across all steps.

2. The user this affects

Who experiences this problem? Their role, their level of sophistication with the product, and what they're trying to accomplish:

"B2B SaaS founders who are evaluating whether to commit to a paid plan — they signed up for a trial but haven't set up the core workflow. They're technically capable but time-constrained — they'll give the product 15 minutes before deciding whether to continue."

This profile shapes every design decision. A technically capable but time-constrained user needs different onboarding than a non-technical user with high tolerance for exploration.

3. What success looks like

What is the measurable outcome you're trying to achieve? Not a visual description, but a result:

❌ "A cleaner, more modern onboarding experience" ✅ "Users reach the activation moment (creating their first project with at least one team member) within 10 minutes of signup, and the drop-off at step 4 decreases from 58% to under 25%"

Having a measurable success criterion changes how the designer approaches the problem. They're now designing to a specific outcome they can later evaluate against, not to a subjective aesthetic judgment.

4. Constraints

What limitations does the design need to work within?

Technical: "We can't change the backend flow for the integrations step — the current step structure must remain, but the presentation can change"
Brand: "Must use our existing design system — no new components"
Timeline: "Needs to be ready for engineering handoff in 2 weeks"
Competitive: "We're positioning against Notion — the design should feel equally simple"

Constraints aren't limitations on the designer's creativity — they're information the designer needs to propose a realistic solution. A design that ignores a real technical constraint is a design that can't be built.

5. Reference materials

What does the designer need to understand to do this work?

Links to the current screens being redesigned
Any user research or analytics data relevant to the problem
Brand guidelines or existing design system
Competitor references (framed as directional, not prescriptive)
Previous design attempts, if any

What Not to Include in a Design Brief

Don't specify the visual solution. "Use a card layout with a white background and rounded corners" — if you know the exact visual solution, you don't need a designer; you need an implementer. If you're not sure what the solution should look like, don't pre-specify it.

Don't list every feature that's related to the problem. A brief for an onboarding redesign doesn't need to list all the onboarding features. It needs to describe the problem with onboarding.

Don't include aspirational language. "We want the design to feel premium, modern, and aligned with our brand values of transparency and innovation" — this doesn't give the designer actionable direction. "We want the design to feel as focused and clean as Linear's interface" gives them a concrete reference.

Don't cc everyone who might have an opinion. A brief sent to 8 stakeholders will produce 8 sets of conflicting feedback. Identify one decision-maker for each brief.

The Brief Template

A simple format that covers the five elements:

Problem: [What is happening that shouldn't be, or not happening that should?]

User: [Who is affected by this problem? Role, context, what they're trying to do]

Success: [What measurable outcome would indicate the design worked?]

Constraints: [Technical, brand, timeline, competitive constraints]

Reference materials: [Links to current screens, data, brand guidelines, references]

For most design requests, this template fills in 200–350 words. For complex multi-screen features, it might be 400–600 words with multiple screenshots.

The Brief for a Redesign vs. a New Feature

Redesign brief: Focus on what's not working and why. Include the current design so the designer can audit it. Include any data about the failure mode — where users are dropping off, what support tickets say, what user research shows. The designer needs to understand what's broken before they can fix it.

New feature brief: Focus on the user problem the feature is solving. Include the context in which the problem occurs. Describe the desired outcome. Don't describe the feature itself — "we need a kanban board" is a solution; "project managers need to see the status of all tasks at once and identify which ones are blocked" is the problem that a kanban board (or something better) could solve.

If you're not sure how to translate your product problem into a design brief, or if previous design briefs haven't produced the output you needed, book a free 30-minute call. We'll help you structure the brief and identify what information will make the design work faster and more effectively.

Frequently Asked Questions

What should a design brief for a SaaS product include?+

A good design brief includes: the problem being solved (not the solution), the user whose problem it is, the context in which they encounter it, what success looks like in measurable terms, relevant constraints (technical, brand, timeline), and links to reference materials. It should not describe how the design should look — that's the designer's job.

How long should a design brief be?+

Short — approximately 200–400 words, readable in 5 minutes. A brief that takes 30 minutes to read is a specification. Specifications are useful for complex features with many requirements; for most design requests, a concise problem statement produces better results than a lengthy pre-solved brief.

What is the difference between a design brief and a design specification?+

A brief defines the problem and desired outcome. A specification describes the solution in detail. Briefs are right when the designer has room to propose the best solution. Specifications are right when the solution is already decided and the designer is executing a specific direction.

How do I brief a redesign without dictating the solution?+

Focus on what's not working about the current design and why. 'The onboarding loses 60% of users before activation — we need to redesign it to get users to value faster' is a problem brief. 'Redesign the onboarding to have fewer steps and a progress bar' is a solution brief. The first gives the designer room to find the best solution.

Should I include competitor references in a design brief?+

Yes, but frame them as directional. 'We want it to feel as focused as Linear' gives the designer a quality benchmark. 'Recreate Linear's interface' constrains them to implementing a specific solution rather than solving your users' specific needs.