How to brief a UX designer.

A brief is how a designer understands your problem before they start. A vague brief leads to vague quotes, misunderstandings and rework. A clear one lets a designer ask better questions, estimate accurately and focus on what matters.

You don’t need to know design terms. You need to explain your business, your users and what success looks like. The designer’s job is to turn that into the right solution.

Start with why the project exists:

• What problem are you solving, and for whom?
• What happens today, and what’s wrong with it?
• What does success look like? Be specific: more sign-ups, fewer support requests, faster bookings, a product ready to show investors.

Avoid jumping to solutions such as “we need a dashboard”. Describe the problem, and let the designer suggest the best way to solve it.

• Who are they: age, job, situation, how comfortable with technology?
• What are they trying to do, and when?
• What devices do they use?
• What do they complain about now?
• Do you have research, analytics, support tickets or reviews to share?

If you don’t have research, say so. A good designer can include it in the plan.

• Is this a new product, a redesign, or an improvement to part of an existing one?
• Which flows or screens are included, such as onboarding, booking or checkout?
• Platforms: web, iPhone, Android, desktop?
• What’s explicitly out of scope for now?

A clear “not now” list prevents scope creep and keeps quotes honest.

• Brand: do you have a logo, colours, fonts or a design system?
• Technology: what is it built with, and are there limits?
• Content: who will write the words?
• Accessibility or legal requirements.
• Competitors or products you admire, and why.
• Stakeholders: who makes decisions and signs off?

• What do you need at the end: research findings, user flows, wireframes, a clickable prototype, high-fidelity designs, a design system, developer hand-off?
• Key dates, such as a launch or investor meeting.
• A budget range.

Sharing a budget range isn’t a weakness. It lets the designer suggest the best approach for what you can spend, instead of guessing.

Copy this into an email or document:

• Project name:
• About the business (2–3 sentences):
• The problem:
• Goal and how we’ll measure it:
• Users and their main tasks:
• Existing research or data:
• Scope (in / out):
• Platforms:
• Brand and design assets:
• Tech constraints:
• Deliverables wanted:
• Deadline:
• Budget range:
• Decision-maker:

Even half-complete, this gives a designer much more to work with than “we need an app”.

A good UX designer will ask follow-up questions, challenge assumptions politely, and propose a process, often discovery, then flows and wireframes, then prototype and testing, then final designs. They should give you a clear quote and timeline.

You can see how I approach projects in my case studies, such as OJO and SoonGuide. To send me a brief, use the project brief form, or see UX/UI design and SaaS & web app design.

• Project: booking app for a group of three dog-grooming salons.
• Problem: clients book by phone; staff spend hours on calls and no-shows are common.
• Goal: 60% of bookings made online within six months; fewer no-shows.
• Users: dog owners, mostly booking on phones in the evening.
• Scope: client booking flow, account, reminders. Staff tools out of scope for now.
• Assets: logo and colours; no design system.
• Deliverables: user flows, wireframes, clickable prototype, final designs.
• Budget: a range, plus the target launch date.

This is a made-up example, but notice how much clearer it is than “we need a booking app”.

• Prescribing the solution instead of describing the problem.
• Listing every feature you can think of without priorities.
• Leaving out who signs off, which leads to late surprises.
• No budget at all, which makes quotes impossible to compare.
• Skipping existing data, such as support emails or reviews that show real problems.

• How would you approach this project, step by step?
• What would you need from us?
• How do you test designs with users?
• What will we receive at the end, and in what format?
• How do you hand over to developers?

Once a designer receives your brief, expect a few steps before work begins:

• A call to go through the brief and ask questions. This is a good moment to judge how well they listen.
• A proposal with the approach, deliverables, timeline and a fixed price or estimate.
• Agreement on how you’ll work together: how often you’ll meet, how feedback is given and who approves each stage.
• A kick-off, often with a short discovery phase to confirm goals and users before design starts.

The clearer your brief, the faster and more accurate these steps will be, and the fewer surprises you’ll have later in the project.

• Describe the problem and goal, not the solution.
• Explain who your users are and what they’re trying to do.
• Be clear about scope, including what’s out of scope for now.
• Share constraints, assets and any data you already have.
• Include a budget range, deadline and who makes decisions.

A brief doesn’t need to be perfect. Send what you have, and a good designer will help you fill the gaps in your first conversation.