The design brief template: every field, and why it's there

A design brief template is only useful if every field closes a decision. Eight fields do that: user, moment and task; one binding constraint; the decision you are betting on; the strongest alternative; the smallest proof; the next check; the evidence that would change your mind; and what you must measure after launch. Anything that does not change what you build is context, and belongs under assumptions.

Why a template needs fewer fields, not more

Most templates you will find are forms: background, goals, audience, deliverables, timeline, stakeholders. They collect context, and context is rarely what a team lacks. When a review stalls, it is almost never because nobody knew the audience. It stalls because nobody wrote down the choice the work was supposed to settle, so every screen is judged against a different imagined goal.

That problem has got more expensive. Generating a plausible screen now takes minutes, so volume stops being evidence of progress. A brief that only describes the situation lets anyone, or any model, fill the gap with safe, busy output. A brief that names a decision gives the work something to be right or wrong about. The test for each field is simple: if you deleted it, would a different thing get built?

The eight fields, and what breaks without each one

1. User, moment, task. Who hits the friction, when, and what they are trying to get done, in one sentence you could observe tomorrow. Without it, the team designs for everyone and reviews turn into a contest of preferences. Mark it as a suspicion until you have seen it happen.
2. Binding constraint. One hard limit that forces a trade-off: a device, a policy, a dependency or a timebox. Without it, the work grows to fit the appetite. «Mobile only, no login» pinches; «some users are on mobile» does not.
3. Decision claim. The one choice you are making, written as a bet a peer could reject on principle. Without it, everything stays an option and nothing is accountable.
4. Strong alternative. The best competing choice you are not taking, on a different axis, not a cosmetic variant. Without it, you cannot tell whether the idea worked or the context was kind.
5. Smallest proof. At most three states that would show the claim holds, including one difficult or edge state. Without it, you sketch until the time runs out and still have no evidence.
6. Next check. The narrow observation you can make before shipping: whether people understand the next step, finish a micro-task, read a warning correctly. Without it, reviews reward the best storyteller.
7. Evidence that flips you. What you would have to see to abandon the claim, written before you sketch. Without it, you read every signal as confirmation.
8. Dependencies after launch. The traffic, access, flags and events you need in order to learn anything. Without them, the postmortem is made of numbers nobody could collect.

One brief, filled in

Take a fictional marketplace where first-time sellers abandon the listing flow at the shipping step. The user is a first-time seller with no shipping history; the moment is the first shipping question after the item details; the task is choosing how to send the item. The binding constraint is that only three carriers are available and new sellers get no negotiated rates.

The decision claim is «show two shipping presets before asking for parcel dimensions». The strong alternative is «ask for dimensions first, then show exact rates», which bets on accuracy over speed. The smallest proof is three states: the preset picker, the error for an item too large for either preset, and the fallback to manual entry. The next check is whether first-time sellers finish setup without the estimate drifting from the real cost.

Notice what the flip evidence and the dependencies force you to say. You decide in advance how far completion must move, and how much estimate error you will tolerate, before you look at a single session. And you admit that you need the listing funnel instrumented by seller type, or the check cannot be run at all. Compare that with a brief that says «improve the shipping experience»: it is not wrong, it is just impossible to fail.

Why the design brief template is also a prompt template

A model is a fast, literal collaborator, which is exactly the reader a brief is written for. The fields map one to one: user, moment and task set the scene; the constraint sets scope; the claim is the thesis; the alternative is what you ask the model to argue for; the smallest proof is the deliverable; the check and the flip evidence are how you judge what comes back. Give it context without a decision and you get decorative certainty.

So use the same eight fields when you prompt. Ask for two directions that sit on opposite sides of the trade-off, ask for the edge cases the draft ignores, and keep a short log of what you accepted, changed and rejected, with the reason tied to the claim. The walkthrough in How to brief an AI goes further, and the product designer AI workflow shows where it sits in a week of real work. The underlying habit is the Explicit prompt skill: saying what would change your mind, not only what you prefer.

The same fields, one hour or one quarter

The template does not grow with the project; the answers do. In a 60-minute exercise the constraint is the timebox, the claim is one bet, the smallest proof is two screens and an error, and the check is whether a stranger understands the next step. The cadence in How to run a 60-minute design challenge is built to stop at proof rather than polish.

Over a quarter, the claim and the alternative stay live across milestones and the checks stack: prototype, beta, release. The roadmap becomes a sequence of bet-then-check loops instead of a list of tasks. If you want to see what a complete brief looks like on the page, the sample brief has every field filled in and can be read without an account.

This is also why practising on redesigns you invent teaches so little. Without a constraint, a claim or a check, there is nothing to be wrong about, which is the argument in Unsolicited redesigns teach nothing. The fields are what turn an exercise into a decision you can defend or lose.

DiagramCopy

Test the brief before you design anything

You can check a brief the day you write it. Give only the text to a colleague and ask them to restate the claim and sketch the smallest proof without seeing any screens. If they cannot, the fields are muddy. Ask a second person to argue for the alternative; if they shrug, the trade-off is trivial or the check is vague. Tighten the constraint and sharpen the flip evidence, then try again.

Models will keep getting faster at producing screens; they will not decide which screen is worth testing. Writing eight fields that close decisions is how you keep that part. Pick a brief with real constraints from the realistic design briefs to practise with, fill in all eight fields before you open a design tool, and see which one you cannot answer.

You are a senior product design sparring partner.
Goal: produce an eight-field design brief that closes decisions and ties them to tests for [describe the design decision and context]. Inputs: [suspected user], [suspected moment], [suspected task], [binding constraint], [current decision bet], [best strong alternative], [available traffic/access/instrumentation].
Output exactly these fields:
1) User, moment, task — one sentence you could test tomorrow; flag as a suspicion if unobserved.
2) Binding constraint — one hard limit that pinches scope (e.g., “mobile-only, no auth”).
3) Decision claim — one-sentence bet under uncertainty that a peer could reject on principle.
4) Strong alternative — a competing choice on a different axis, not cosmetic.
5) Smallest proof — max three items, include one difficult/edge state.
6) Next measurable check — an immediate, narrow observation.
7) Evidence that flips you — explicit thresholds that would change your mind.
8) Dependencies to measure after launch — traffic, access, flags, and events.
End with a one-line risk from vagueness and a one-line note of what you cut or moved to assumptions.