How to brief a designer starts with a simple rule: explain the problem and guardrails without pretending you already know the best interface.
A founder may send a feature list, competitor screenshots, and a request for a “clean dashboard.” The designer still does not know which user matters, what task is failing, which data exists, what is included, or who approves the work.
A useful UX brief covers context, problem, outcome, users, evidence, scope, constraints, deliverables, budget, timeline, stakeholders, and the working process. It does not need every answer. It should make facts, assumptions, and unanswered questions visible.
This guide explains how to brief a UX designer for SaaS and includes a copy-ready template and example.
How to brief a designer: the quick answer
A good brief helps a designer understand why the project exists, estimate the work, and identify important unknowns. Include:
- Context: Product purpose and stage
- Problem: What happens now and why it matters
- Outcome: What should improve
- Users: Priority roles and tasks
- Evidence: Data, research, and feedback
- Scope: Included flows, platforms, and states
- Constraints: Technical, legal, brand, and accessibility limits
- Assets: Available files, content, systems, and access
- Deliverables: Expected activities and outputs
- Budget and timeline: Practical guardrails
- Stakeholders: Contributors and final decision-maker
- Process: Feedback, revisions, and changes
“Improve the UX” is vague. “Reduce setup confusion for new workspace administrators” gives the designer a problem to investigate.
What a UX design brief is—and what it is not
A design project brief is a concise starting document that aligns the client, designer, and team. It explains why the work matters, what is known, which boundaries apply, and what outcome is expected.
It is not a final requirements document, project plan, contract, research report, mood board, or fixed solution. The brief gives direction. Discovery investigates unknowns. A proposal recommends an approach. A scope of work formalizes services, responsibilities, timing, outputs, and commercial terms.
Figma’s design brief guidance includes goals, problem, audience, requirements, budget, timeline, and deliverables. Product UX also needs evidence and technical context. Keep the brief accessible and update it when an approved assumption or scope decision changes.
Why vague briefs create expensive design problems
Missing information forces designers to pause or fill gaps with assumptions. Estimates become unreliable, and polished work may solve the wrong problem.
Without defined success, feedback becomes “I like this” or “make it pop.” Scope expands without a baseline, engineering constraints arrive after approval, and expected deliverables remain unclear.
A useful brief exposes uncertainty. “We believe administrators abandon setup because permissions are confusing, but we need to verify it” is more useful than a guessed solution presented as fact. Learning how to brief a UX designer means making the project discussable, not appearing completely certain.
1. Start with product and business context
When deciding how to brief a UX designer, explain what the company and product do in plain language. State whether this is a concept, MVP, live product, new feature, redesign, audit, or design-system project. Add why the work matters now.
Share the business model or strategic goal only where it affects design. A trial-based SaaS product may care about activation, while an internal operations tool may prioritize speed and error reduction.
Avoid pasting a marketing page full of broad claims. The designer needs to understand the product, audience, workflow, and current stage—not only the brand promise.
2. Describe the problem, not your preferred screen
A key lesson in how to brief a designer is that a proposed screen can hide the reason behind the request.
Prescribed solution: “Add a three-step setup wizard.”
Useful problem: “New workspace administrators often leave before inviting a teammate. Support conversations suggest they do not understand role permissions or which information is required.”
The second version gives the designer room to check the evidence and explore a wizard, guided setup, better defaults, contextual help, or another approach.
Include examples of the problem: funnel drop-off, repeated support questions, user workarounds, failed tasks, complaints, or observed confusion. Label facts, assumptions, and ideas separately. This prevents an internal preference from quietly becoming a user requirement.
3. Define the outcome and success signals
A practical answer to how to brief a designer is to state what should be better after the project. Useful outcomes include faster task completion, fewer input errors, clearer permissions, better activation, lower support volume, or accessible completion of a core flow.
Use a measurable baseline when reliable data exists, but do not invent a percentage to make the brief sound rigorous. A qualitative success signal can be valid when the project is early.
Also explain failure. The engagement has not succeeded if a polished onboarding flow still leaves administrators unsure about access levels, even if stakeholders like its colors.
Clear outcomes help everyone evaluate design against the project rather than personal taste.
4. Identify the real users, roles, and context
Name the people who perform the task, not only the person buying the software. A B2B product may involve a buyer, account owner, administrator, manager, daily operator, approver, and the customer served by that operator.
Share what is known about their goals, frequency of use, expertise, devices, environment, language, and accessibility needs. Link research rather than creating decorative personas from guesses.
Sometimes the person commissioning the work is far from the actual user. Strong UX project requirements reflect the needs of people completing the task while respecting business and operational constraints.
5. Share evidence and access the designer can use
A brief becomes far stronger when it links to useful evidence:
- Current product or staging access
- Analytics, funnels, and event definitions
- Support tickets and sales notes
- Interview recordings or research summaries
- Search logs and repeated queries
- Customer access for interviews or testing
- Existing flows, requirements, and roadmap
- Competitors and non-software alternatives
- Previous experiments and what happened
Do not present internal opinion as customer evidence. If the team lacks research, say so. The designer can then include discovery in the proposed work instead of assuming the brief is validated.
Remove personal information that is not needed and share customer data through an approved, secure process.
6. How to brief a designer about scope and priorities
“Redesign onboarding” may include account creation, invitations, role selection, permissions, sample data, emails, responsive behavior, error states, testing, copy, component updates, and developer handoff. That phrase is not enough to estimate.
Define the product area, platforms, user roles, priority flows, and known states. Rank must-have work separately from useful or later work.
| In scope | Out of scope |
|---|---|
| Administrator invitation flow | Billing and subscription management |
| Role selection and permission explanation | Full brand redesign |
| Loading, empty, error, and success states | Frontend development |
| Responsive web behavior | Native mobile applications |
| Prototype testing | Ongoing research recruitment |
Exclusions do not mean those areas are unimportant. They make the current commitment clear. If a dependency outside scope can block the work, identify it.
7. Explain functional, technical, and compliance constraints
Share target platforms, frontend framework, component library, APIs, available data, authentication, user roles, legacy behavior, integrations, and release restrictions where they affect the experience.
Add accessibility, privacy, localization, security, legal, healthcare, or financial requirements early. A beautiful flow is not useful if it cannot meet an essential policy or technical rule.
Identify an engineering contact. Designers should discuss feasibility and data before a direction becomes expensive to change. If a constraint is unknown, mark it as an open question rather than guessing.
8. Provide content, brand assets, and visual references
Share current brand guidelines, logos, fonts, design files, component libraries, UI kits, content tone, approved imagery, and licensed assets. Clarify who owns final product copy and realistic data examples.
Visual references are useful when you explain them. “We like this dashboard’s clear grouping and compact filters” is actionable. “Make ours look like this” invites copying and hides the real need.
References can communicate density, tone, hierarchy, or interaction patterns. They should not replace user evidence, product rules, or professional exploration. The Interaction Design Foundation’s design brief overview similarly treats objectives, audience, constraints, requirements, budget, and timeline as connected parts of the brief.
9. Agree on activities and deliverables
Do not request every familiar UX deliverable by default. Choose work according to the problem and uncertainty.
Possible activities and outputs include:
- UX audit or focused discovery
- Stakeholder and user interviews
- Task flows and information architecture
- Wireframes
- Interactive prototypes
- Usability testing
- High-fidelity interface design
- Responsive and system states
- Starter design system or component updates
- Developer handoff and implementation review
Clarify platforms, priority flows, expected fidelity, source-file ownership, prototype depth, and handoff needs. A screen count may help estimate visual work, but complexity matters more than quantity.
A Figma link alone may not communicate data rules, permissions, responsive behavior, accessibility, or edge cases. The UI/UX design process guide explains how these activities connect from requirements through implementation.
10. How to brief a designer about budget and timing
A budget or workable range helps a designer recommend a realistic process. Hiding it can waste time on proposals that are either too shallow or impossible to fund.
Share fixed launch dates, flexible targets, internal review time, holidays, engineering dependencies, and external approvals. A deadline is only useful when the team also has time to provide access, content, and decisions.
List available resources: developers, researchers, subject experts, users, analytics, tools, and an existing system. More budget does not automatically create better design, but scope, speed, and research depth cannot all expand without cost.
When uncertainty is high, consider a paid discovery phase before fixing the entire project scope.
11. Name stakeholders and one approval owner
List who contributes knowledge, who reviews, and who makes the final decision. A product lead may approve flow and scope, while a brand owner reviews visual direction and engineering confirms feasibility.
Many reviewers can provide useful input, but conflicting comments need one resolution path. Otherwise, the designer is asked to satisfy incompatible preferences.
Record approvals and the reasons behind important decisions. This keeps old debates from returning and helps new team members understand why the product works as it does.
12. How to brief a designer about feedback and changes
Agree on the main communication channel, meeting rhythm, response expectations, review format, and decision deadlines. Feedback should be consolidated where possible and connected to user goals, evidence, business needs, or constraints.
Define how revisions work for the chosen commercial model. “Move this approved component to match the system” is different from adding a new role and workflow. Clarification, revision, and new scope should not be treated as the same thing.
A brief cannot predict every edge case. The important part of how to brief a designer is creating a process for what happens when new information appears. Assess the effect on scope, timeline, and cost before quietly adding work.
A ready-to-copy UX project brief template
Copy this into a shared document and keep each answer focused.
Project and context
- Project name:
- One sentence: Design or improve [feature] for [user] so they can [outcome].
- What does the product do?
- What stage is it in, and why now?
Problem, evidence, and outcome
- What happens today, and who experiences it?
- What evidence supports the problem?
- Which points are assumptions?
- What should improve?
- How will progress or failure be recognized?
Users and scope
- Primary user, role, and task:
- Other affected roles:
- In-scope flows, platforms, and states:
- Priorities:
- Out of scope:
- Dependencies:
Requirements and constraints
- Functional rules and available data:
- Technical and platform limits:
- Brand and content requirements:
- Accessibility, privacy, security, legal, and localization needs:
Assets and access
- Product or staging links:
- Research and analytics:
- Design system and brand assets:
- Engineering, subject-expert, and user access:
Work and delivery
- Expected activities and outputs:
- Prototype, testing, responsive, and handoff needs:
- Source-file ownership:
- Budget and target dates:
- Contributors and approval owner:
- Communication, feedback, and change process:
- Open questions requiring discovery:
These UX project requirements need not be final before contact. Mark gaps honestly so the designer can propose how to resolve them.
UX brief example for a SaaS onboarding redesign
Project: Improve team setup for a live B2B reporting platform.
Problem and evidence: Many account owners leave before inviting a teammate. Support repeatedly receives permission questions. Funnel data identifies the drop-off step, but the reason still needs validation.
Outcome: Improve successful team setup and reduce permission confusion. Review invitation completion, support topics, and usability evidence after launch.
Users: Account owners and workspace administrators. Invited members are secondary in this phase.
In scope: Invitation, role selection, permission explanation, confirmation, responsive behavior, and loading, empty, error, and success states. Include one prototype test and component updates.
Out of scope: Billing, native apps, full rebranding, and frontend development.
Constraints: Use the current API, authentication, and component library. Engineering must confirm which permissions can change later.
Deliverables: Audit, flow, wireframes, prototype, usability findings, final UI, component updates, and developer review.
Budget and timeline: Share the available range and release window; let the designer recommend depth and milestones.
Approval: The product lead decides after consulting engineering and support.
This explains the problem and boundaries without prescribing the interface. For wider context, see Imdshakil’s SaaS product design guide.
What not to put in a UX designer brief
Avoid:
- A fixed interface presented as the only valid answer
- Unexplained competitor screenshots
- Fictional personas treated as research
- Every feature marked urgent
- Personal preferences described as user needs
- Hidden budget or immovable dates
- A large backlog without priorities
- Sensitive passwords or customer data
- Results the designer cannot guarantee
- Detailed unpaid design work requested before engagement
A brief can include preferences and ideas. Label them correctly and explain the reason. Knowing how to brief a designer means providing guardrails without removing the designer’s ability to solve the problem.
Questions to discuss during the kickoff call
Use the kickoff to challenge and clarify the brief rather than read it aloud.
Ask:
- What decision triggered this project now?
- Which user and task matter most?
- What evidence supports the stated problem?
- What has already been tried?
- What cannot change, and why?
- Which assumptions could alter the scope?
- Who can provide technical and user access?
- Who approves each stage?
- What must be ready for development?
- How will success be reviewed after launch?
The designer should ask questions too. A brief that survives without discussion is not necessarily better; collaborative clarification is part of how to brief a designer responsibly.
Frequently asked questions
What should I include when briefing a UI/UX designer?
Include context, problem, outcome, users, evidence, scope, constraints, assets, deliverables, budget, timeline, stakeholders, approval ownership, and feedback process.
How do I write a UX design brief for a freelancer?
Use the same structure, then clarify access, communication, file ownership, review timing, revisions, payment milestones, and handoff in the agreement.
How long should a UX design brief be?
Long enough to answer important questions and short enough to use. A few focused pages with supporting links often work better than one large document.
Do I need complete requirements before hiring?
No. Share what is known, separate facts from assumptions, list open questions, and include discovery where needed.
Should I include a preferred design style?
Yes. Explain what you value in references and what to avoid, but do not prescribe the full interface.
Should budget be included?
Yes, or provide a workable range. It affects research depth, scope, deliverables, team, and timeline.
Is a UX brief the same as a scope of work?
No. The brief gives direction; the scope of work formalizes services, outputs, responsibilities, timing, and commercial terms.
Final recommendation
Understanding how to brief a designer does not require a perfect document. Explain the problem, users, evidence, outcome, scope, constraints, resources, and decision process. Mark uncertainty instead of hiding it.
A strong brief starts collaboration; it does not replace discovery. The designer should still question assumptions, involve users and engineers where useful, and refine requirements as evidence appears.
If your SaaS project needs clearer requirements, user flows, prototypes, scalable UI, or practical developer handoff, explore Imdshakil’s SaaS Application Design service or discuss your project.
