— 22 September 2026
The one-page brief we write before every design file
Nine lines that decide whether a design succeeds. The template we use, the questions that actually surface disagreement, and why skipping it costs two rounds of revisions.
Two designers, same skill, same client. One delivers in two rounds, the other in six. The difference is almost never talent. It is whether anyone wrote down what the design was supposed to do before it was made.
We write a one-page brief before opening a design file. Every time, including for a single landing page. It is the cheapest quality control available.
The nine lines
1. Who is this for, specifically
Not “customers”. A procurement manager comparing three vendors under time pressure. A first-time buyer who is not sure the category is legitimate. A returning customer who knows exactly what they want and resents anything in the way.
Design decisions follow directly from this. The procurement manager needs specifications above the fold. The nervous first-timer needs proof. The returning customer needs speed.
2. What is the one job of this page
One. Not five. If a page has five jobs it has none, and the design will show it.
“Convince a serious applicant to start the form.” “Let an existing customer reorder in under thirty seconds.” “Make a specification comparable so an engineer can shortlist us.”
3. What is the one action
The single thing you want the visitor to do. Everything else on the page is subordinate to it — visually, spatially and in the copy.
When a client cannot pick one, that is the most valuable disagreement the brief will surface, and it is far cheaper to have it now than after two rounds of visual design.
4. What proof do we have
Testimonials, numbers, logos, certifications, case studies, guarantees. Listed before design begins, because design that assumes proof which does not exist gets redesigned when the real content arrives.
If the honest answer is “not much yet”, the design has to work harder in other ways — and knowing that in advance changes the approach entirely.
5. What are the constraints
Brand rules, fixed content, technical limits, the CMS the client is stuck with, the fact that the ops team edits it and cannot handle a complex layout.
Constraints stated in advance are design inputs. Constraints discovered late are rework.
6. Three references, with reasons
Not a mood board of things somebody liked. Three specific examples with one sentence each explaining what to take from them.
“This one, for how the specification table reads on mobile.” “This one, for the tone of the headline, not the visuals.” “This one, for how they handle a long product list without it feeling endless.”
Unexplained references are the leading cause of a design that technically matches the reference and completely misses the point.
7. How will we know it worked
A measure, agreed now. Application starts. Enquiry quality. Time to reorder. Bounce on mobile.
This matters because it changes what feedback is admissible. “I do not like the green” is an opinion. “This does not make the specification comparable” is a finding against the brief.
8. Who approves
One named person. Not a committee, not “the team”.
The most common cause of a spiralling revision count is an approver who appears in round four with opinions nobody had heard. Name them at the start and get them to the first review.
9. What is explicitly out of scope
The list of things this design is not solving. The blog redesign. The checkout. The mobile app. Writing them down gives every good-but-unrelated idea a place to go, which is the same mechanism that makes a build spec work — covered in what goes wrong without one.
Why we write it instead of asking for it
Clients rarely write good briefs, and asking them to produces a delay followed by a document that restates the request.
So we draft it after a 45-minute conversation and send it for correction. People are much better at spotting a wrong statement about their own business than at generating a right one from scratch. Corrections come back within a day, and they are specific.
What it prevents
Revision spirals. Feedback gets checked against the brief instead of against taste. Most disagreements resolve in one exchange.
Late approvers. They were named in line eight and invited to review one.
Design that cannot be built. Constraints were inputs, not surprises.
Content that never arrives. The proof list surfaces missing content in week one rather than week five, when it delays launch.
The wrong argument. Without a stated job, teams argue about colour. With one, they argue about whether the page does the job — which is the argument worth having.
The unexpected benefit
Occasionally the brief cannot be written, because nobody can agree on the one job or the one action. That is not a failure of the exercise. It is the exercise working.
A project that cannot be described in nine lines is not ready for design, and finding that out in an hour is a genuinely good outcome. Twice this year it has led to a different, smaller, better project than the one we were asked to quote — which is also how our pricing conversations tend to end up more accurate.
Use it yourself
You do not need a studio to run this. Write the nine lines before your next internal design task, send them to whoever is designing, and see how many rounds you save.
If the answer is “we could not fill in line three”, you have just found the real problem — and that is worth more than any design file. Tell us what you are stuck on.
? COMMON QUESTIONS
Questions people actually ask.
What should a design brief contain?
Nine things: the audience, the single job of the page or screen, the one action you want, the proof available, the constraints, the references with reasons, the success measure, who approves, and what is explicitly out of scope. That fits on one page and prevents most revision cycles.
Why do designs go through so many revision rounds?
Almost always because the brief was verbal. Without a written definition of the job, feedback becomes personal preference, approvers multiply late, and each round moves the target. A written brief converts opinion into a check against agreed criteria.
Who should write the design brief, the client or the studio?
The studio writes it, the client corrects it. Clients rarely have the vocabulary or the time to specify design outcomes, but they immediately recognise a wrong statement of their own business. Drafting it and being corrected is faster than requesting it and waiting.
How long should a brief take to write?
Forty-five minutes of conversation and twenty minutes of writing. If it takes longer, the project is not understood well enough to design yet — which is itself the most useful finding the exercise can produce.
3 RELATED READING
Next to this one.
Accessibility is now a sales requirement
Export clients, enterprise procurement and public tenders all ask for it. The pragmatic path from failing to defensible — what to fix first, what to document, and what it costs.
Read ↗What happens after we ship: handover, docs, ownership
Launch is not the end of the engagement, it is the start of ownership. The exact handover pack every client should demand — credentials, repo, runbook, and who to call at 2am.
Read ↗Shipping one product for India, UAE and Oman
Multi-currency, multi-language, multi-timezone and three sets of expectations. The engineering and design decisions that make a Gulf-plus-India product work without forking the codebase.
Read ↗→ NEXT POST