How to write a design project brief clients actually answer

A design brief is the shortest document in a project and the one that saves the most time. When it's good, the proposal almost writes itself, feedback has something to be measured against, and nobody is surprised at the end. When it's missing, every later conversation starts from a different idea of what the project is.

This guide covers what a brief is for, who should write it, the sections worth including, and the questions that get useful answers out of a client.

What a design brief is for

A brief is a short, shared description of the project: what is being made, why, for whom, by when and within which limits. It isn't a contract and it isn't a creative concept. Its job is to make sure you and your client mean the same thing before you price or design anything.

A good brief does three things:

• It records decisions. "The audience is first-time buyers, not existing customers" settles an argument before it starts.
• It exposes gaps. If the client can't say who approves the work, you've found a risk before it costs you a revision round.
• It becomes the yardstick. Later, when feedback drifts, you can point to the goals you both agreed on.

Who should write the brief

Clients sometimes arrive with a brief, but it's often a list of wishes rather than a plan. In practice, many freelancers get the best results by writing the brief themselves after a discovery call, then sending it to the client to confirm.

Writing it yourself means the brief uses your structure, asks the questions you need answered, and is phrased in a way you can design against. The client's job is to correct it, not to fill in a blank form.

The sections every brief needs

You don't need a long document. Each section can be a few lines. What matters is that none of these is missing. For a ready-made outline with the questions for each section, use our design brief template.

Goals that can be checked

Avoid goals like "modern" or "clean". They're preferences, not goals. Ask what should change for the business or the user, and write it so you could check it later. "Explain the product clearly within the first screen" is something you can test with real people. "Make it pop" is not.

Scope written as deliverables

Write scope as a list of things the client will receive, not activities you'll do. "Homepage design for desktop, tablet and mobile" is a deliverable. "Design work" is not. A clear deliverables list makes the proposal and the agreement much easier to write later.

References with reasons

A list of links is only half useful. Ask the client what they like about each reference: the typography, the tone, the layout, the way pricing is explained. "Linear, for its calm product storytelling" tells you far more than "Linear".

Questions that get useful answers

Some questions reliably produce better briefs than others. These work well on a first call or as a short questionnaire:

1. What prompted this project now?
2. If this project goes well, what will be different in six months?
3. Who is the main audience, and what do they need to do or understand?
4. Who are your main competitors, and what do you like or dislike about them?
5. What is the single most important action you want people to take?
6. Do you have brand guidelines, copy or imagery I should use?
7. Who will give feedback, and who gives final approval?
8. Is there a date or event the timeline has to work around?

The approval question is easy to forget and expensive to skip. Feedback from someone who wasn't in the room until the final review is one of the most common reasons projects run over.

From call notes to a finished brief

A simple routine works well:

1. Run the call with the questions in front of you. Take notes in the brief's sections rather than as a transcript.
2. Write the brief the same day. Your memory of what the client meant fades quickly.
3. Mark what you assumed. If you guessed the audience or the deadline, say so, so the client knows to check it.
4. Send it for confirmation. Ask the client to correct anything that's wrong and answer the open questions.
5. Treat the confirmed brief as the reference. Link to it from the proposal and come back to it when feedback arrives.

If the client can't answer some questions yet, that's useful too. Unanswered questions about approval, content or deadlines are risks you can mention in your proposal.

Common mistakes

• Writing a creative concept instead of a brief. The brief describes the problem. Your design answers it.
• Leaving out what's not included. If copywriting or development isn't part of the job, say so now. It's much harder to raise later.
• Skipping the audience. Without an audience, every design decision becomes a matter of taste.
• Never sending it back. A brief the client hasn't confirmed is only your interpretation.

What comes after the brief

Once the brief is confirmed, the next document is the proposal. It turns the brief's scope and timeline into an offer with a price. Our guide to what to include in a web design proposal walks through it section by section.

Later in the project, the goals and success criteria in your brief are what you'll measure feedback against. That makes structuring client feedback much easier.