How to Brief a Design Agency for Your SaaS Product
To brief a design agency for your SaaS product, write one or two pages that explain the problem you want solved, who the users are, what success looks like, what exists today and which constraints the design has to respect. Name the decision makers and the timeline, attach whatever data you have, and describe the problem rather than the solution. A good brief lets the agency come back with sharp questions and a realistic scope instead of guesses.
Most briefs fail in one of two ways. Some are a single line ("redesign our dashboard, make it modern"), which forces the agency to guess at everything that matters. Others are a forty-page spec with every screen already decided, which turns the agency into a production team and wastes the judgment you are paying for. The useful brief sits in between.
Why does the brief matter so much?
The brief is the first design decision. It sets what the agency researches, what it ignores and how it will judge its own work. A vague brief creates a vague proposal, and a vague proposal turns into a project where scope is argued every week.
A clear brief also makes agencies comparable. If you are talking to more than one, giving each the same brief is the only fair way to compare their thinking. We covered the rest of that process in how to choose a UX design agency for B2B SaaS.
What should a SaaS design brief include?
The problem and why it matters now
State the problem in terms of user or business behavior. "Trial users who connect a data source convert, but most never get that far" is a problem. "The onboarding is outdated" is an opinion. Add why it matters now: a funding milestone, a big customer, a competitor, churn you can see in the numbers.
Users and the jobs they do
Who uses this part of the product, and what are they trying to get done? In B2B SaaS, name the roles: the admin who sets it up, the analyst who lives in it every day, the executive who opens it once a month. If you have personas, research notes or interview recordings, attach them. If you have none, say so; that tells the agency to plan for research. Our guide to UX research for complex B2B products explains what that research usually covers.
Goals and how you will measure success
Pick one or two outcomes and how you will measure them: activation, time to first value, task completion, support tickets on a feature. Our article on UX metrics that matter can help you choose. If you cannot measure it yet, describe what "better" would look like in plain words.
Scope: what is in and what is out
List the flows, screens or modules in scope. Then list what is explicitly out. The "out" list prevents more scope arguments than anything else in the brief.
What exists today
Share access to the product, a staging account or a recorded walkthrough. Include your design system or component library if you have one, your brand guidelines and any previous design work, including the attempts that did not work and why.
Technical constraints
Tell the agency your front-end framework, component library and anything that cannot change: an API that returns data a certain way, a third-party widget you must keep, accessibility requirements, supported browsers and devices. Designers who know your stack design things your engineers can build. (If you want to compare notes, ours is on our tech stack page.)
People, decisions and timeline
Who is the day-to-day contact? Who gives final approval? How often can you review work? Note any hard dates, such as a launch or a board meeting, and say whether they are fixed or flexible.
How you want to work
Say how you would like to engage: a fixed-scope project, an ongoing stream of requests, or a designer embedded in your team. If you are unsure, say that too. A good agency will suggest a model that fits the work.
A copyable design brief template
Copy this into your doc tool, fill in each section in a few sentences, and delete the prompts.
# Design brief: [product or feature name]
## 1. Problem
- What is going wrong, in terms of user or business behavior?
- Why does it matter now?
## 2. Users
- Roles involved (for example admin, daily user, approver, executive)
- The main job each role is trying to get done
- Research we already have (links), or "none yet"
## 3. Goals and success
- Outcome 1 and how we measure it
- Outcome 2 and how we measure it
## 4. Scope
- In scope: flows, screens or modules
- Out of scope: what we are deliberately not touching
## 5. What exists today
- Product or staging access, or a walkthrough video
- Design system or component library (link)
- Brand guidelines (link)
- Previous attempts and what we learned
## 6. Technical constraints
- Front-end framework and component library
- Constraints that cannot change (APIs, integrations, legacy screens)
- Accessibility, browser and device requirements
## 7. People and timeline
- Day-to-day contact
- Final decision maker
- Review cadence we can commit to
- Key dates, and whether each one is fixed or flexible
## 8. How we want to work
- Fixed-scope project, ongoing requests, or an embedded designer
- Tools we use (Slack, Figma, Jira, Notion)
- Anything confidential that needs an NDA before sharing
## 9. Open questions
- What we do not know yet and want the agency's view onWhat are the most common briefing mistakes?
- Prescribing the solution. "Add a wizard with five steps" skips the thinking. Describe the problem and let the agency propose the wizard, or something better.
- Hiding the constraints. Teams leave out the legacy API or the enterprise customer who refuses change, then reject designs that ignore them.
- No single decision maker. When five people give feedback with equal weight, every review becomes a negotiation.
- Every goal at once. A brief that asks for more conversion, less churn, a new brand feel and a design system in one project will get a thin version of each.
- Skipping what failed before. Previous attempts are some of the most valuable context you have. Share them.
- No access to the real product. Screenshots hide the states, the speed and the friction. Give the agency an account.
What happens after you send the brief?
A good agency reads it and comes back with questions, not a quote by return email. Expect them to challenge parts of it, suggest what to research first and propose a scope with a clear timeline.
At delbueno™ Studio the next step is a short call to agree on scope. Kickoff happens the same day, and first concepts arrive within 48 hours. If the brief shows the real problem is still undefined, our product strategy work ends in a prioritized roadmap and a design brief you can build from. You can also see how we structure projects on our engagements page, or send us your brief and we will tell you honestly what we would do with it.
Frequently asked questions
How long should a design brief be?
One or two pages is enough for most SaaS projects. Link to supporting material (research, analytics, design files) instead of pasting it in. If the brief runs much longer, you are probably specifying the solution.
Should we include a budget in the brief?
It helps to say how you plan to engage and whether you have a fixed budget or a flexible one, because that shapes the scope an agency proposes. If you would rather not share it up front, say what matters more: the date, the scope or the spend.
Do we need an NDA before sharing the brief?
Only if the brief includes confidential material. Ask the agency to sign one before you share it. Many agencies, including delbueno™ Studio, sign NDAs on request.
Should we include our own wireframes or sketches?
Yes, if they help explain the problem or show what you have already tried. Label them as context, not as the expected answer, so the agency feels free to propose something different.
Who should write the brief?
The person who owns the outcome, usually a founder or product lead, with input from engineering on constraints and from sales or success on what customers say. One author keeps the brief coherent.
Photos by UX Indonesia and Nick Morrison on Unsplash.
