Product discovery and UX design: a buyer's guide / Run the work
How to brief a design partner
A design brief has one job: transfer your context to people who do not have it, so their first week is spent designing instead of guessing. The good ones are short, specific about the problem, and say nothing about the solution. The bad ones come in two types: the empty brief that says 'make it modern and clean', which outsources your strategy to a stranger, and the over-detailed brief that specifies every screen, which pays design rates for drafting services. Both produce the same outcome: work that fails, and a partner who gets blamed for it.
Published August 8, 2026. Editorial.
Key takeaways
- Brief the problem and the evidence, not the solution. If the brief contains screen layouts, you have already done the design, badly.
- Name one metric the work should change. A brief with no measurable target will be judged on taste, and arguments about taste never end.
- State constraints honestly up front: brand rules, technical stack, compliance, budget range, deadlines. Every hidden constraint appears later as rework.
- Write what is out of scope. The sentence 'we are not redesigning the dashboard' saves more money than any other sentence in the brief.
We have received hundreds of briefs across build and design engagements, and the correlation is hard to miss: the quality of the brief predicts the quality of the collaboration better than the budget does. The reason is that writing a good brief forces the buyer to make the decisions only the buyer can make, and to hand over everything else.
That split is the main skill. Some decisions belong to you: what problem matters, who it matters for, what success measures, what constraints are real. Some belong to the designer: how the solution should work. Briefs fail in both directions, by keeping decisions that should be handed over, and by handing over decisions that should be kept.
What the brief must contain
The problem, with evidence. For example: "trial users drop off at the project setup step, here is the funnel, and here are twenty support tickets from the last month asking how to finish setup", where a weak brief would only say "our app feels dated". Evidence does two things: it directs the work, and it lets the partner disagree intelligently. A partner who can read your tickets will find things your summary missed. If your evidence is weak, say so plainly; knowing the assumption is untested is itself critical context, and it may mean the right first purchase is discovery, not design.
The users, specifically. "Busy professionals" is not a user. "Property managers handling forty units, in the field half the day, phone-first, interrupted constantly" is a user, and a designer can make a hundred small decisions correctly from that sentence alone. If different user types conflict, say which one has priority, because that is a strategy decision, and strategy decisions do not belong to your design partner.
The metric. One number the work should change: activation rate, how-do-I ticket volume, time to complete the core task. This single line changes the engagement's character, from taste-driven to outcome-driven, and it guides both sides: the partner scopes toward the metric, and you evaluate against it instead of against your mood in the review meeting.
The real constraints. Brand rules that cannot change and preferences that can, labeled as which is which. The technical stack and what it makes cheap or expensive. Compliance and accessibility requirements, named concretely: if the standard is WCAG 2.2, write that, not "should be accessible". Deadline and what drives it. Budget range, at least with an honest upper limit. Partners do not resent constraints; they resent discovering them in week six, when the work built on the missing fact gets thrown away.
What is out of scope. The highest-value sentence in any brief. "We are not redesigning the dashboard in this engagement" prevents the slow growth of scope that turns a focused project into one with no limits. Scope creep in design behaves exactly as it does in engineering, which we cover in why scope creep happens: each addition makes sense on its own, and the sum is a different, larger project nobody priced.
What exists today. Access, not descriptions: the current product, the analytics, the support queue, past research if any, and the names of the people who can answer questions. A partner working only from screenshots cannot see how the live product behaves.
What to leave out
Leave out the solution. Screen sketches, feature lists phrased as layouts, "we want a dashboard with tabs across the top". The moment the brief specifies the how, the partner's expertise is reduced to drawing your guess attractively, and when the guess turns out wrong, the rework is billed to you, because you specified it.
One version of this feels helpful and causes the same problem: pasting screenshots of competitors with "like this". Reference points are fine as examples. As instructions, they add a solution nobody tested, designed for someone else's users and constraints.
If you find you cannot stop specifying the solution, notice what that means: you do not yet trust the partner with the how. That is a problem with the partner you chose, and it is cheaper to fix before signing, using the tests in how to choose a product design agency.
The brief starts a conversation
Send the brief before the kickoff, and judge the partner by what they do with it. Strong partners come back with questions that make it more precise: which of these two user types has priority, what does the funnel look like segmented by plan, why is the deadline the deadline. Weak partners accept it as it is and quote against it, which means either they did not read it closely or they plan to renegotiate through change orders later.
Expect the brief to be revised after those questions, and treat that as the process working. The founder's version of this discipline is the subject of a founder's real job is to remove ambiguity: the brief is you removing ambiguity for people about to make hundreds of decisions on your behalf. Every ambiguity you leave in is a decision you have delegated by accident.
The one-page template
If it helps to start from an outline, this is the whole thing, six headings with a prompt under each:
Problem. What is failing, and what evidence do we have? Attach the funnel, the tickets, the recordings.
Users. Who exactly is this for, described by their situation and behavior, not demographics? If two user types conflict, which one has priority?
Metric. What single number should this work change, and what is it today?
Constraints. Brand rules (which are fixed, which are preferences), technical stack, compliance and accessibility standards by name, deadline and what drives it, budget range.
Out of scope. What are we explicitly not doing in this engagement?
Access. Links and names: the product, the analytics, the support queue, past research, the people who can answer questions.
One page is usually enough. If it runs past three pages, you are probably specifying solutions, and if it fits in three sentences, you are probably outsourcing strategy. Keeping it to one page forces you to know which decisions are yours.
Common questions
What should a design brief include?
Six things: the problem with evidence behind it, a specific description of the users, one metric the work should change, the honest constraints (brand, stack, compliance, deadline, budget range), an explicit out-of-scope list, and access to what exists today: the product, analytics, and support queue. One page is usually enough if each item is specific.
How detailed should a design brief be?
Detailed about the problem, and saying nothing about the solution. 'Trial users abandon at project setup, here is the funnel' is the right kind of detail. A tab layout sketched in the brief is the wrong kind: it converts your design partner into a drafting service and bills the rework to you when the guess is wrong. If the brief exceeds three pages, it is usually specifying solutions.
Should the brief include a budget?
At least an honest range. Hiding the budget does not produce better prices; it produces proposals scoped by guesswork, which then get renegotiated when the real number appears. The budget is a constraint like the deadline and the stack, and partners design differently, and appropriately, for different budget sizes. Wasting a good partner's proposal effort on an unaffordable scope helps no one.
What does a bad design brief look like?
Two types of failure. The empty brief: 'make it modern and clean', which outsources strategy to someone with no context and guarantees taste arguments later. The over-detailed brief: screens specified, features arranged in layouts, competitors pasted as instructions, which pays design rates for rendering an unvalidated guess. Both share the root cause: the buyer has not separated the decisions that are theirs (problem, users, metric, constraints) from the one that is not (how).
Who inside a company should write the design brief?
Whoever owns the problem the work is meant to fix, usually a founder or product owner, because writing the brief forces that person to make the decisions only they can make: what problem matters, who it matters for, what success measures, and what constraints are real. A brief drafted by someone without authority over those decisions tends to carry unresolved internal disagreement instead of resolving it before the partner starts.
What happens if you skip writing a brief and just talk to the designer?
The context that a brief transfers gets lost or repeated inconsistently across conversations, and the partner spends their first week guessing instead of designing. Without a written problem statement and metric, the engagement moves toward whichever stakeholder spoke last in a meeting, and disagreements about direction appear again late, when changing the plan is expensive rather than a quick edit to a shared document.
How is a design brief different from a contract or statement of work?
A brief transfers context: the problem, the users, the metric, and the real constraints, so the partner can design intelligently. A contract or statement of work defines price, timeline, and deliverables. The brief is meant to be revised after the partner asks questions that make it more precise, while a contract is meant to be fixed once signed. Treating the brief as a rigid contract is a common mistake that discourages the questions that make an engagement succeed.
How do you know if a design brief is finished?
Check it against the six headings that matter: the problem with evidence, the users described specifically, the one metric the work should change, the honest constraints, what is explicitly out of scope, and access to what exists today. If any heading is missing or vague, the brief is not finished. A brief that fits on one page with each item specific is usually complete; one running past three pages is usually specifying solutions instead of context.
Related reading
You cannot measure engineers by how much they produce
Lines of code, tickets closed, and hours logged all measure activity rather than progress. Here is how we think about engineering output without numbers that only look good.
What a good technical spec looks like when a model writes the code
The old advice was to keep specs short and stop where writing the code is faster. That advice assumed a person was reading it. When a model writes the code, the cost of an unanswered question changes, and so does the right length of a spec.
How to write a software development RFP that gets honest bids
Most software RFPs ask for a fixed price on a problem nobody has scoped yet, so the bids come back either set too high on purpose or dishonest. Here is how to write one that gets real answers.