How to Write a Design Brief That Clients Can Actually Answer

Most design briefs fail in one of two ways. Either the client writes three lines ("we need a modern website, make it clean"), or the designer sends a twelve-page questionnaire that the client abandons on page two. Both produce the same result: a project that starts on guesses.

A brief works when the client can answer it in one sitting, in their own words, without knowing design vocabulary. This post gives you ten questions that do that job, the reason each one is there, what a weak answer looks like, and a template at the end.

What a brief is for

A design brief is a shared agreement about three things: what problem the work solves, who it is for, and how everyone will know it worked. Everything else (colors, layout, features) comes after those three.

It is also a protection for both sides. When the client later says "I expected a booking system", you can point to question 6 and the scope line you both agreed.

The ten questions

1. What is the business, in two sentences?

Why: You need the plain version before the pitch-deck version. Weak answer: a mission statement. Better prompt: "Explain it as if to a friend at dinner." If the client cannot do this in two sentences, you have found the first problem the design must solve.

2. What problem are we solving, and for whom?

Why: This is the anchor. Every later decision gets checked against it. Weak answer: "We want a new website." That is a solution, not a problem. Ask: "What is not working today?" A good answer sounds like "Clinics find us but cannot tell if we take their insurance, so they call, and our front desk is overloaded."

3. Who is the main user?

Why: Design for "everyone" gets you nobody. Ask for one primary user and at most one secondary. Request specifics: role, device, where they are when they use it, what they know already. If the client has no data, a described real person is fine. Mark it as an assumption so you can test it later.

4. What should the user be able to do when this is finished?

Why: It turns a vague wish into a testable task. Write it as "A [user] can [action] in [rough effort]." Example: "A new customer can place a first order without calling us." If there are more than three such sentences, the project is probably two projects.

5. How will we know it worked?

Why: Without this, "done" becomes a matter of opinion. Ask for one or two measures the client already tracks: sign-ups, completed orders, support tickets, time to complete a task. If nothing is tracked today, say so in the brief and agree on what you will observe instead. Do not invent targets to fill the box.

6. What is in scope, and what is explicitly out?

Why: Scope arguments are mostly memory arguments. Write both lists. Out-of-scope items are as useful as in-scope ones: "No native mobile app. No admin dashboard. No content migration." Ask: "What would you be disappointed not to get?" and "What are you assuming is included that we have not mentioned?"

7. What exists already?

Why: Existing brand assets, a current site, analytics, past research, competitors the client dislikes. Ask for links and files, not descriptions. Also ask what the client likes and dislikes about the current product, with reasons. "I hate the blue" is less useful than "the blue makes us look like a bank."

8. What are the fixed constraints?

Why: Budget range, launch date, technology the developers must use, legal or compliance rules, languages, accessibility requirements. Constraints are not obstacles to hide; they shape the whole solution. A client who will not give a budget range is asking you to guess, and you will guess wrong.

9. Who decides, and who needs to be consulted?

Why: Projects stall when a fifth stakeholder appears at review. Name the one final decision-maker, the people who give input, and the turnaround time on feedback ("within three working days"). Late approval is a schedule risk, so write it down like one.

10. What are the risks and unknowns?

Why: Ask the client what keeps them worried about this project. Also list your own: "We do not yet know whether payment will be card-only or include local wallets." Naming unknowns early lets you plan a spike or a question to answer, instead of discovering the gap in week five.

How to make the brief answerable

Having the right questions is half the job. The other half is how you ask.

• Send it as a short call agenda or a form, not a PDF to fill alone. Many clients answer better out loud. Take notes and write the brief yourself, then send it back for correction.
• Use their words. If they say "members" and you say "users", write "members".
• Give an example answer for each question. Two lines of sample text lower the effort a lot.
• Allow "I don't know". Mark those items as open and assign an owner. A brief with honest gaps is more useful than one with confident invented answers.
• Cap it at one page of answers. If it grows past that, you are writing a spec, which comes later.

A fill-in template

Copy this into a doc and complete it with your client.

PROJECT BRIEF

Project name:
Date:
Prepared by:
Final decision-maker:

1. The business in two sentences:

2. The problem we are solving, and for whom:

3. Primary user (role, device, context, what they already know):
   Secondary user (optional):

4. When this is finished, a [user] can:
   a.
   b.
   c.

5. How we will know it worked (measure, current value if known):

6. In scope:
   Out of scope:

7. What exists already (links, files, likes and dislikes with reasons):

8. Constraints
   Budget range:
   Launch date:
   Required technology:
   Legal / compliance:
   Languages and accessibility needs:

9. Who gives input, and feedback turnaround:

10. Risks and open questions (owner for each):

Signed off by (client):                Date:

Common mistakes

• Writing the brief for design, not for the client. If the client cannot read it without a glossary, they cannot correct it.
• Treating the brief as a one-time document. Revise it when scope changes, and note the date.
• Skipping question 5. Without a success measure, the final review becomes a taste debate.
• Accepting solutions as problems. "We need an app" is a request. Keep asking "so that what can happen?" until you reach an outcome.

Using the brief after kickoff

A brief earns its keep during the project. Put it at the top of the shared folder. At each review, open it and ask whether the work answers question 4. When a new request arrives, check it against question 6: if it is out of scope, discuss it as a change with its own time and cost, calmly and early.

FAQ

How long should a design brief be?

One to two pages. If the answers need more space, put the extra material in an appendix and keep the brief itself short enough that everyone rereads it.

Who should write the brief, the client or the designer?

The designer should hold the pen and the client should supply the answers. That way the format stays consistent and the client only has to react, not compose.

What if the client does not know their users?

Say so in the brief, write down your best assumption, and add a research step early in the plan. An honest assumption is easier to fix than a hidden one.

Talk to us

If you are planning a product and want help shaping the brief before design starts, the Rising Station team is happy to talk it through. Email hello@risingstation.com or visit risingstation.com/contact-us.