The quality of a design brief determines the quality of the work it produces. Not because designers can't work with ambiguity — they can — but because ambiguity resolved at the brief stage costs nothing, while ambiguity resolved after three weeks of work costs considerably more.
Why most briefs fail before the work begins
The most common briefing failure isn't vagueness — it's precision applied to the wrong things. Clients who are new to working with product designers often arrive with a detailed description of what they want the design to look like, and very little information about what it needs to do, who it's for, how it will be made, and what constraints it must work within. That combination produces a designer who knows exactly what shape they're being asked to produce and almost nothing about whether that shape will solve the problem it's meant to solve.
A useful brief describes the problem, the context, and the constraints. It leaves the solution — at least initially — to the person being hired to find it. This isn't an abdication of client responsibility; it's the correct division of labour. You know your business, your users, your supply chain, and your budget. The designer knows how to translate those inputs into manufacturable geometry. A brief that skips the inputs and jumps straight to the solution bypasses the part of the engagement where the designer's expertise is most valuable.
Start with the problem, not the product
Before describing any physical form, articulate what problem the part or product needs to solve and for whom. This sounds obvious and is routinely skipped. A brief that opens with "we need a housing for our electronics module" is less useful than one that opens with "we need to protect a 60 × 40 mm PCB from ingress in an outdoor environment, accessed by service technicians roughly twice a year, mounted to a standard DIN rail." The second brief contains the same core request but also tells the designer about the environmental requirement, the access frequency, the user, and the mounting constraint — all of which will influence the design before a single sketch is made.
The problem statement should also distinguish between what is fixed and what is open. If the PCB dimensions are fixed, say so. If the DIN rail mounting is a preference rather than a requirement, say that too. Designers working with unclear fixity spend time exploring options that aren't actually available or, worse, constrain themselves unnecessarily because they assumed something was fixed when it wasn't.
A useful brief describes the problem, the context, and the constraints. It leaves the solution — at least initially — to the person being hired to find it. That's not an abdication of responsibility; it's the correct division of labour.
Define the manufacturing context early
Manufacturing process is not a detail to be worked out after the design is done — it shapes every decision the designer makes from the first sketch. A part destined for injection moulding needs draft angles, uniform wall thickness, and gate locations considered from the outset. A part that will be machined from billet needs to be designed around tool access and minimum feature sizes. A part intended for 3D printing has a completely different set of freedoms and constraints. Telling a designer the manufacturing process at the end of the project, or leaving it unspecified, produces a design that may be geometrically interesting and functionally sound but expensive or impossible to make.
If you don't know the manufacturing process yet, say that explicitly and give the designer the information that will determine it: expected volume, target unit cost, lead time requirements, and any material specifications. A designer who understands those parameters can help select the appropriate process — which is genuinely useful input — rather than making an assumption that locks in expensive consequences downstream.
Quantities and tolerances: information most clients don't think to include
Production volume changes design decisions dramatically. A single prototype, a batch of fifty, and a production run of five thousand are not the same design problem even if the part geometry is identical. The first justifies 3D printing and little concern for tooling cost. The second might warrant machined or cast components. The third opens up injection moulding or stamping, which introduce design requirements — and cost savings — that are irrelevant at lower volumes. Without knowing the intended volume, a designer is guessing at which optimisations are worth making.
Tolerances are similarly overlooked. Most clients don't specify them because they don't know what tolerances their design requires — and that's a legitimate position, since establishing appropriate tolerances is often part of the designer's work. But where tolerances are known — mating parts from an existing assembly, regulatory requirements, customer-specified interface dimensions — those need to be in the brief. A designer who discovers late that a specific bore must meet a particular fit class has to revisit completed work. A designer who knows this from the start designs the feature correctly from the beginning.
Reference material: what helps and what doesn't
Good reference material in a brief is specific and contextual. Photographs of existing parts — including the ones that don't work and why — are useful. Dimensional sketches, even rough ones, are useful. Samples of products with finishes or textures you want to achieve or avoid are useful. The context in which the part will be used, photographed if possible, is useful.
What is less useful is a folder of Pinterest images with a note that says "something like this." Visual inspiration without context leaves the designer to infer what specifically you're responding to — the form, the colour, the material, the perceived quality level — which produces a high probability of divergence between what you found inspiring and what the designer produces. If you're sharing visual references, annotate them. Note what you're drawing from each one and, equally important, what you're not asking for.
Competitor products warrant particular attention. If there are existing solutions to the problem you're trying to solve, the designer should know about them — both to avoid reproducing them unnecessarily and to understand what the market has already established as the baseline. If you have concerns about IP or disclosure, raise them explicitly. A professional designer will work within those constraints; they can't do so if they don't know the constraints exist.
What a complete brief contains
- The problem: What needs to be solved, for whom, and in what context. Include the use environment, the user profile, and any regulatory or certification requirements.
- Fixed constraints: Dimensions, interfaces, or specifications that cannot change. Mating components, existing tooling, mounting standards, material requirements.
- Open parameters: Areas where the designer has genuine freedom to explore. Being explicit about where latitude exists is as useful as specifying what is fixed.
- Manufacturing intent: Process, volume, and target cost per unit. If these are unknown, provide the inputs that will determine them.
- Deliverables and format: What you expect to receive at the end of the engagement. Native CAD files, STEP exports, 2D drawings, rendered images, physical prototypes — and in what format, to what standard.
- Timeline and review points: When you need the work completed and how many review cycles the project includes. Undefined review scope is one of the most reliable sources of project cost overrun.
Deliverables: be specific about what you're actually buying
A surprisingly large number of client-designer disputes trace back to misaligned expectations about deliverables. The client believed they were receiving native CAD files with a full feature tree; the designer quoted for STEP exports only. The client expected manufacturing drawings to a BS 8888 standard; the designer produced conceptual sketches. These aren't failures of goodwill — they're failures of specification, and they're entirely preventable.
Specify the file formats you need, the software you or your manufacturer will use to open them, and any drawing standards the documentation must meet. If you intend to modify the CAD model after delivery — to adapt it for a variant, or to continue development in-house — say so, because a model built for hand-off looks different from one built for internal use. A design optimised for visual presentation renders beautifully and may be parametrically fragile. A design built for continued development has a clean feature tree, named bodies, and documented design intent. Both are valid outputs; they're not interchangeable.
Budget: say the number
Clients routinely withhold budget information from designers on the theory that disclosing it will result in the designer filling it entirely regardless of what the work actually warrants. This theory has some basis in human behaviour generally, but it misunderstands what budget information does for a designer. Knowing the budget tells the designer how much development time is appropriate, what level of prototyping iteration is realistic, and whether the manufacturing process options under consideration are actually viable for this client at this stage.
A designer working without budget information will either propose a scope that exceeds what the client can afford — wasting both parties' time on a negotiation that should have happened before the proposal — or will under-scope conservatively and miss the opportunity to suggest work that would genuinely add value. Neither outcome serves the client. The number anchors the conversation in reality and allows both parties to make informed decisions about what the engagement should include.
A well-written brief is an act of respect for the designer's time and your own. It communicates that you understand the engagement well enough to define its parameters clearly, and it creates the conditions in which good design work actually happens. The hour or two it takes to write one properly is returned many times over in fewer revisions, less rework, and a result that solves the right problem.
Add comment
Comments