A product design brief gives a team a shared starting point before it commits to a direction. It explains who the product is for, what need it addresses, what is known, and what still needs to be learned. A strong brief does not need to predict the final form. It should make the next decision clearer.
Discuss your product design brief
What should a product design brief help decide?
A brief is a decision tool, not a polished pitch or a complete specification. It aligns contributors on the problem, the evidence behind it, the boundaries of the work, and the questions that may change the direction. Start by naming the decision the document should support. That might be whether to explore an opportunity, which user need should lead, what a prototype should test, or what evidence is needed before a larger commitment.
Write that decision in one sentence. For example: âWe need to find out whether a compact countertop product can make this task easier for a specific household.â The sentence gives the reader a way to judge the rest of the document. If a paragraph does not explain the decision, its context, or an important unknown, shorten it or move the detail to an appendix.
A brief can be too prescriptive as well as too vague. A document that dictates every feature and surface detail leaves little room to learn. One that says only âmake it betterâ gives a team nothing concrete to investigate. The useful middle ground describes the intended outcome and relevant boundaries, while distinguishing established facts from assumptions.
For a founder, the decision may be whether a need merits early concept work. For a brand team, it may be whether an item fits an existing range. For a creative agency, it may be how a physical object can carry an idea into a real setting. Those examples lead to different criteria, even when each begins with an exciting product concept.
How do you explain the user and the need?
Describe the people who will use, buy, install, clean, maintain, or be affected by the product. âEveryoneâ is not a useful user definition. Say where someone encounters the product, what they are trying to do, what they use today, and what makes the task difficult. A buyer may care about storage or upkeep, while a daily user may care about reach, comfort, or control.
Keep observation separate from interpretation. âPeople set the device down between usesâ is an observation. âThey need hands-free operationâ is one possible interpretation. If both appear as settled facts, the team may skip the work needed to understand why the behavior happens. A practical design checklist for design initiatives also prompts teams to examine user personas and use cases.
Primary user: Who uses the product most often, and where?
Other stakeholders: Who chooses, pays for, installs, cleans, repairs, or regulates it?
Current behavior: What do people do today, including workarounds?
Need: What task, frustration, or unmet expectation deserves attention?
Evidence: What interviews, observations, support themes, sales information, or tests support the need?
A useful starting sentence is: âPeople who [context] need a better way to [task] because [observed barrier].â Keep the statement focused on the task rather than naming a feature. Add what evidence supports it and how confident the team is. If the sentence rests on a belief that has not been tested, label it as a hypothesis and state what would help confirm or revise it.
For example, âcommuters need a smaller bottleâ assumes that size is the problem. The evidence may instead show that the bottle does not fit a particular bag pocket, leaks when carried sideways, or is awkward to clean. Those causes suggest different design questions. A brief should preserve that distinction instead of turning the first proposed fix into the problem statement.
What context should the brief capture?
A physical product is used in a setting, not in a vacuum. Describe the environment and the moments that shape use. Include conditions such as available space, lighting, moisture, noise, transport, storage, cleaning, setup, charging, and disposal when they matter. Note adjacent products or systems the user already relies on.
Context often reveals questions hidden by a broad concept statement. A product used with wet hands raises different questions about grip and control than one used at a desk. A product carried every day raises questions about weight, attachment, protection, and access. These are prompts for investigation, not instructions about the final solution.
Describe a typical sequence from beginning to end. How does the user obtain the product, unpack it, prepare it, use it, put it away, maintain it, and eventually replace it? Not every stage needs equal space. Focus on moments where there is friction, risk, confusion, or a handoff between people.Consider a small kitchen device. The product may be used near a sink, stored in a cabinet, cleaned after each use, and shared by several people. A brief can note those circumstances and the questions they raise: Is the counter space fixed? Does cleaning require disassembly? Who stores the accessories? The document does not need to answer prematurely. Its job is to show which circumstances could change the design.
Also capture the alternatives people use now. Note what works well, what fails, and why users keep choosing the current option. A workaround can be valuable evidence: it shows how someone already solves part of the problem. Avoid dismissing existing products as âbadâ without saying what users experience or what the team observed.
Which goals and measures belong in the brief?
State success in terms a team can observe. Words such as âinnovative,â âpremium,â and âeasyâ are not useful measures on their own. Explain what they mean in this project. A goal might concern task completion, comfort, setup, durability, cleaning, returns, or a business outcome. Choose measures that fit the product and can be evaluated at the right stage.
Separate user outcomes from business objectives. A team might want a product to be simpler to operate and also support a new market. Both can belong in the brief, but one does not prove the other. Identify who owns each objective and what evidence would count as progress.
Describe the user outcome in plain language.
Name the business or brand objective the project supports.
Choose a small set of indicators that can be tested or reviewed.
Record a baseline if one exists; mark missing information honestly.
Clarify which trade-offs are acceptable and which are not.
Take the phrase âquick to clean.â Before turning it into a requirement, ask which parts need cleaning, what routine matters, and who performs it. A prototype review might ask representative users to complete the same cleaning task and describe where they struggle. The brief need not make up a pass threshold before the team has evidence. It should say how the team will learn whether cleaning has become meaningfully easier.
Do not force a numerical target when no credible baseline exists. A first phase may need to establish what can be measured and how. Make that learning goal visible. A measure is most useful when it connects to a choice: what result would lead the team to continue, revise, or stop?
It also helps to define what is outside the measure. A quick setup test does not automatically establish long-term reliability. A positive reaction to a sketch does not establish that the object will be comfortable in daily use. State what each piece of evidence can and cannot tell the team, so an early signal is not mistaken for a final answer.
How should you describe scope and constraints?
List what the current project includes and what it does not. State expected outputs, known dependencies, decision makers, and dates that are genuine fixed points. A hoped-for launch date and a deadline imposed by an event or contract are not the same. Mark which dates can move and what they depend on.
Record known limits around size, weight, materials, existing systems, safety, accessibility, distribution, upkeep, or production route when they are established. Label each as fixed, preferred, or open. Ask whether a stated constraint is truly mandatory or simply a preference. âMust fit through this openingâ can be tested against a measurement. âShould feel compactâ needs a reference or a user-based definition.
What is fixed, flexible, or still unknown?
Fixed: A requirement that cannot change, with its reason and owner.
Flexible: A preference that can be traded against another goal.
Unknown: A question that needs investigation before a decision.
If stakeholders disagree about whether an element is mandatory, record the disagreement and identify who can resolve it. An unresolved decision should not be hidden in a footnote. A simple scope statement can say that the next phase includes user research, concept exploration, and an early functional model, while excluding final packaging artwork and production validation. These are examples, not a standard package. Name the actual outputs and the decisions each one should support.
A constraint becomes easier to use when the brief identifies its source. âThe enclosure must fit a 120-millimeter spaceâ is more actionable when the document says who supplied the measurement and whether it has been checked. âUse the existing componentâ needs a part number or a reference file. âKeep cost lowâ is not yet a boundary; it needs context, an owner, and a plan to establish what is feasible.
When two requirements conflict, write down the trade-off rather than burying it. A lighter product might need a different material or construction. A smaller package might complicate access or storage. The brief can name the competing priorities and ask who has authority to weigh them. That helps the team avoid discovering late that different stakeholders were optimizing for different outcomes.
How can a brief inform production decisions early?
The brief need not select a factory or settle every component. It should capture what is known about expected volume, price boundaries, geography, materials, assembly, packaging, maintenance, and distribution. If an input is unknown, say so and explain how the project will investigate it.
These topics affect one another. A target price may influence material choice and part count. A compact form may complicate assembly or service. A special finish may add process steps. The point is not to decide everything before exploration; it is to make consequential dependencies visible while there is still room to compare approaches.
Record the source and status of each input. A customer requirement, an early supplier estimate, an internal preference, and a guess should not look identical. If a cost boundary is preliminary, say who supplied it and when it needs confirmation. If expected volume is unknown, flag that uncertainty because it may affect the production routes worth evaluating.
For example, imagine a brand considering a reusable container. The brief might identify a target use setting, cleaning expectations, approximate storage limits, a desired retail context, and the need to compare material options. It should not declare one material best before the team has assessed the relevant requirements. Instead, it can ask what evidence is needed to compare durability, cleaning, appearance, and production implications for this particular product.
Describe the ideaâs current maturity. Is it a user need, a sketch, an existing prototype, an extension to a product range, or a working product with a known issue? Link source material and identify what is reliable. A prototype may reveal fit or interaction questions without proving the design is ready for production. Teams can review Jackson Heddenâs product design approach for context on the broader path from product idea toward a developed physical product.
What evidence and files should you bring?
Include material that helps explain the need, constraints, or prior work. A short, well-labeled evidence folder is more useful than a large unexplained archive. For each item, note its date, source, relevance, and limitations. A reader should be able to understand why a file is included without asking the person who assembled it.
User research notes or a concise summary of observations.
Photos or diagrams of the use context, where appropriate and permitted.
Existing sketches, digital models, prototypes, samples, or product specifications.
Relevant customer feedback, support themes, or sales observations.
Brand guidance and product-range context that must carry through.
Known standards, compliance questions, or safety concerns for later review.
Supplier, component, or process information that has already been confirmed.
Protect private information. Remove personal details that are not needed, and clarify who owns supplied designs or reference material. If a sketch is inspiration only, label it that way; otherwise a team may mistake it for a required direction. A simple file index can list the name, date, source, relevance, and confidence level.
Evidence also needs interpretation. A photograph of one storage location may show an approximate context without representing every userâs home. A summary of support requests may show a recurring complaint without explaining its cause. Include a short note about what the evidence supports and what it cannot establish. That keeps the brief useful without overstating a small sample.
Group files by purpose rather than sending a folder full of unrelated attachments. One group might explain the user and setting; another might show previous concepts; a third might contain constraints or reference specifications. If an important file is missing, name it and say who can provide it. Jackson Heddenâs product development guides provide additional context for teams thinking about how ideas progress into physical products.
How do you compare options without choosing too soon?
A brief can prepare the team to compare alternatives without dictating the winner. Identify the criteria that matter, then state which are essential and which can be traded. For a portable product, the list might include access, protection, ease of carrying, storage, cleaning, and production complexity. The right criteria depend on the user need, not on a generic checklist.
Use a consistent description for each option. If one concept is judged on appearance and another on ease of cleaning, the comparison will be lopsided. A short review can ask the same questions of each approach: What user task does it support? Which constraint does it satisfy? What new risk or unanswered question does it introduce? What evidence would help distinguish it from the alternatives?
Keep a record of why an option is retained or set aside. âThe team liked itâ does not explain whether it serves the need. âIt may be easier to store, but the proposed closure needs testingâ captures both a reason and a follow-up. This is particularly helpful when stakeholders join later or when new information changes the priorities.Do not turn every comparison into a scorecard. A score can make uncertain judgments look precise. If the team uses ratings, define the scale and record the evidence behind each score. When information is too limited, mark a criterion as unknown and decide how to learn more. The aim is a transparent decision, not a false sense of certainty.
How can you tell whether the brief is ready?
A brief is ready for a first conversation when a new reader can explain the intended user, need, desired outcome, known boundaries, and biggest open questions. It does not need to settle every design question. It should show what the team needs to learn next and who will help answer it.
Can a reader summarize the user and situation in two or three sentences?
Is the need supported by evidence or clearly marked as a hypothesis?
Are user outcomes and business objectives distinguished?
Are constraints classified as fixed, flexible, or unknown?
Does the document say what is included and excluded?
Are the decision makers and next decision identified?
Can the attachments be understood without a verbal explanation?
Ask someone outside the project to read it. If they cannot describe the problem without repeating the proposed solution, revise the opening. If they have to guess who can approve a trade-off, clarify ownership. Another useful review is to label each sentence as fact, interpretation, constraint, or open question. If a sentence is treated as both a proven need and a settled design choice, rewrite it.
Check for contradictions as well. A brief may describe a product as portable but specify a form that is difficult to carry. It may call a feature essential while listing it as outside the project scope. A final pass should compare the user need, measures, constraints, and deliverables against each other, not just check that every section has a heading.
What should happen in the first conversation?
Use the meeting to test alignment and find gaps, not to read every page aloud. Start with the user and need. Review what is known, what is assumed, and which constraints could change direction. Close by agreeing on the next decision, the evidence needed, and who will provide it.
Keep a live question list. Sort questions into those that block progress, those that can be explored during early concept work, and those that can wait. An uncertain user group may block concept selection; a final color choice may be premature. This sorting prevents a meeting from spending equal time on questions with very different consequences.
Afterward, send a concise decision record. Capture the agreed problem statement, unresolved assumptions, owners, evidence requests, and the point at which each issue will be revisited. If the brief changes, note what changed and why. This creates a useful trail from the original question to the decisions that shape the work.
For a focused follow-up, teams can book a product design consultation, review product examples, or explore the product development guide library. Each link supports a different next step: discuss a project, see examples, or learn more about the process.
Frequently Asked Questions
How long should a product design brief be?
Long enough to explain the user, need, goals, context, constraints, evidence, and decisions, but concise enough for stakeholders to review. Keep the core brief focused and link to detailed research or specifications in clearly labeled supporting files. Clarity matters more than page count.
Is a product design brief the same as a product specification?
No. A brief describes the problem, intended outcomes, boundaries, and open questions. A specification records defined requirements in greater detail. A brief can point to existing requirements, but it should not present uncertain choices as settled.
Should a brief include sketches or a proposed solution?
Yes, when they help communicate current thinking. Label sketches as concepts or references unless they are approved requirements. Explain the need and intended outcome so the team can assess whether the proposed form is an appropriate response.
What if the target user is not confirmed?
State the likely user as a hypothesis, summarize the evidence, and identify what would validate or change it. That turns uncertainty into a research question instead of presenting a guess as fact.
Can one brief cover several product concepts?
It can if the concepts address the same need and share goals and constraints. If audiences, use settings, or success measures differ, separate briefs or clearly marked concept-specific sections can prevent conflicting assumptions.
Who should approve the brief?
The people who own the user need, business goal, and major constraints should confirm the relevant parts. Name a decision maker for trade-offs and record unresolved disagreements. Approval does not mean every design question is answered; it means the team agrees on the problem and the next learning step.
Start a conversation about your product
A clear brief does not predict every challenge. It gives the team a shared place to begin, a way to separate evidence from assumption, and a practical basis for the next decision.
