Product design brief template: six lines that reduce rework

I write a product design brief around six decisions: the problem, the user, the measurable outcome, the time budget, the scope boundaries and the risks someone must resolve. Agreeing these before design starts reduces rework caused by conflicting expectations, hidden constraints and untested assumptions.

A six-line product design brief template

I want a brief short enough to read together and specific enough to challenge. Six lines means six decision slots, not six sentences forced into tiny type. Evidence, sketches and technical notes can sit underneath. The agreement belongs at the top.

For a worked example, I'll use a hypothetical business account setup flow. Every number below is illustrative, not a client result. I'd start with this version, then check the assumptions before treating it as an approved brief.

• Problem and evidence: 40% of eligible account setup attempts remain incomplete after seven days; interrupted sessions are a suspected cause.
• User and situation: an account administrator gathering company details across several sessions.
• Outcome and measurement: reduce seven-day non-completion from 40% to 25%, without increasing support contacts per setup attempt.
• Appetite and constraints: two weeks with one designer and two engineers; no changes to the billing service.
• Scope and exclusions: support interrupted setup; exclude identity verification changes and a full onboarding redesign.
• Risks and ownership: the engineer checks safe draft storage, I test recovery comprehension, and the product lead approves any scope trade.

How to define the problem in a product brief

I separate the observed problem from the proposed explanation. In the example, seven-day non-completion is the observation. Interruption is a hypothesis. Writing 'users need autosave' collapses both into a feature request and makes it harder to discover that missing documents, unclear eligibility or a broken verification step is the actual cause.

I attach the smallest useful evidence: the reporting period, the event definition and a few relevant support examples or research notes. If the evidence is thin, I say so. 'Three interview participants described losing progress' supports investigating lost progress; it doesn't establish how common it is. I also record the cost of leaving the problem alone, such as delayed activation or repeated support work. That gives the product lead something concrete to compare with other requests.

How to describe the user and their situation

I name the person doing the work, their task and the condition that makes it difficult. 'Small businesses' is a market segment, not enough direction for a designer. 'An account administrator who must ask a colleague for company details before continuing setup' points towards interruption, handover and a return visit.

This line also prevents conflicting optimisation. A first-time administrator needs different help from an accountant setting up a tenth account. I choose the primary case and record who isn't being prioritised in this slice. I don't add a full persona unless its details change a decision. Age, a stock photograph and a fictional biography won't help me decide whether a draft should survive sign-out. Device access, permissions and shared-account behaviour might.

How to set measurable outcomes for design work

I give the outcome a denominator and an observation window. Here, non-completion means eligible setup attempts that have not reached account activation within seven days. Without that definition, one person may count sessions while another counts accounts. Both can produce a convincing chart, but they won't be measuring the same thing.

The target is a decision threshold, not a promise that design will move the number. I'd compare mature seven-day cohorts before and after release, check for changes in traffic mix and avoid claiming causation from that comparison alone. Support contacts per attempt is the guardrail: completion shouldn't improve by pushing confusion onto support. Before release, I use task testing to check whether people can return and continue. That tests the proposed mechanism; it doesn't prove a future conversion gain.

How to set a time budget without fixing every feature

I use Basecamp's Shape Up distinction between appetite and estimate. An appetite states how much time a problem is worth; an estimate predicts how long a particular solution might take. Setting the appetite first makes scope a deliberate choice rather than an expanding list that engineering eventually has to price.

In the example, two weeks is the team's total delivery budget, not two weeks of design followed by unspecified development. I confirm who is available, which dependencies exist and whether the constraint is negotiable. If safe draft storage needs a major service change, I reduce the slice or return for a different budget. I don't call the same scope 'a first version' and pretend it became smaller. I also skip detailed screen inventories while the basic approach remains uncertain.

What to include and exclude from product design scope

I define the smallest coherent behaviour the work must support. 'Improve onboarding' could absorb months. 'Let an administrator leave setup and return to the last valid saved state' gives design and engineering a shared boundary. It still leaves room to choose how saving, recovery and feedback should work.

Shape Up's pitch structure makes exclusions and known traps explicit. I use that discipline to name adjacent work that isn't included: replacing verification, changing billing or redesigning every setup screen. Exclusions aren't permission to ship a broken experience. If returning to a draft exposes another person's information, access control becomes necessary scope. I make that trade visible immediately. I'd rather remove a secondary convenience than discover during review that the essential behaviour isn't safe to release.

How to record product risks and decision owners

I use Marty Cagan's four product risks as a check: value, usability, feasibility and business viability. For this example, I'd ask whether resuming setup addresses the real obstacle, whether people understand recovery, whether progress can be stored safely and whether retaining those details fits the business's obligations. A polished prototype answers none of those automatically.

I pair each material uncertainty with a person and a next action. The engineer checks storage and expiry rules before I explore detailed recovery states. I test whether administrators recognise where they left off. The product lead confirms that the retention approach has the necessary review. I don't turn this into a long risk register. I record the assumptions that could change the solution, plus who can accept the consequences or send the work back for reconsideration.

How to review a product brief before design starts

I book a 20-minute read-through with the product lead and an engineer. Each person explains the intended outcome, the biggest exclusion and the unresolved assumption in their own words. This exposes disagreement more reliably than asking for approval on a document. If the accounts differ, I edit the brief before opening the design file.

My start condition isn't certainty. It's agreement on what can proceed and what needs investigation first. I date the brief and keep a short decision log beneath it. A new request must replace existing scope, change the time budget or wait. When evidence overturns the original assumption, I revise the brief openly. That's useful learning, not avoidable rework. Quietly changing the problem while keeping the old deadline is the failure I want the brief to prevent.

Questions people ask

What should a product design brief include?

I include the problem and evidence, target user, measurable outcome, time budget, scope boundaries, and risks with owners. I link supporting detail rather than burying those decisions inside background material.

How long should a product design brief be?

I aim for one page of working agreement, with links for evidence and technical detail. Length matters less than whether the people doing the work can spot an unresolved decision.

Who writes the product design brief?

I can draft it, but I won't invent business priorities or engineering constraints alone. I ask the product lead to confirm the outcome and an engineer to check feasibility before detailed design.

How is a product brief different from a requirements document?

I use the brief to agree the problem, investment and boundaries. I use requirements to describe the behaviour and conditions needed for delivery, adding detail as the solution becomes clearer.

Where I checked my thinking

• Marty Cagan: Four big risks
• Basecamp Shape Up: Set boundaries
• Basecamp Shape Up: Write the pitch