Start with the job the product must do
Early product briefs often mix needs, preferences and proposed solutions. “Easy to carry” describes a user need, while “add a molded handle” specifies a solution. That distinction matters: a handle might work, but a lighter body or a different grip could serve the same need better. Before setting dimensions or choosing materials, describe who will use the product, what they will do with it and where they will use it.
Gather inputs from the people who will design, make, inspect, package and use the product. Note conflicts rather than smoothing them over. A compact object may be easier to store but harder to grip; a rigid package may protect a product but use more space in transit. These observations give requirements a purpose and help the team decide which tradeoffs need testing.
Turn broad goals into testable statements
A measurable requirement identifies an observable result, a condition and a way to judge success. “The lid should be durable” leaves too much open: durable against what? A more useful draft is, “After the agreed opening-and-closing test, the lid must still latch without visible cracking.” The team must then define the test procedure, including how many cycles to run and what counts as a failed latch. The chosen threshold should follow from intended use, not from an arbitrary preference for a larger number.
Write each requirement so that someone can assess it without guessing what the author meant. Terms such as lightweight, intuitive and premium can still appear in a design brief, but they need interpretation before they become acceptance criteria. For example, an accessibility goal might be evaluated through a defined user task and observation method, while a mass limit can be checked on a scale. Not every important quality is captured by a single number; a repeatable inspection or user test can also provide evidence.
Specify conditions, limits and priorities
Requirements should say which product configuration is being assessed and under what conditions. A container’s filled mass is different from its empty mass. A closure may behave differently after cleaning or when operated with wet hands. State relevant conditions so a supplier and an internal tester are checking the same thing. Where variation is expected, define acceptable limits rather than relying on an ideal target alone.
Separate requirements that must be met from goals the team should improve if possible. Safety, fit and compatibility may set firm boundaries; appearance, assembly time and material use may involve tradeoffs. Record why a limit exists and who agreed to it. That context helps when a prototype reveals that two requirements conflict. It also prevents a convenient design choice from being mistaken for a user need.
Keep the list focused. If one sentence asks for low mass, high strength and easy cleaning, split it into separate statements. Each can then have its own acceptance criteria and test. Linked requirements can still be reviewed together when the team weighs the tradeoff.
Plan verification while writing
For each requirement, ask what evidence would show that it has been met. The answer might be a measurement, a functional test, an inspection, a packaging trial or a documented user evaluation. Record the method alongside the requirement rather than leaving it until the design is complete. If a statement cannot be checked in a practical way, it may need clearer wording or a different measure.
Consider production variation as well as the first successful prototype. A part that fits when made carefully once may be difficult to produce consistently. Specify the features that matter to function, identify where tolerances are needed and avoid making every dimension unnecessarily tight. Requirements for packaging and transport deserve the same attention: a product that works on the bench still needs to arrive in usable condition.
A simple requirement record can include an identifier, the statement, its reason, its priority, the verification method and the result. Identifiers make it easier to connect a change in a drawing or test plan to the requirement it affects. They are especially helpful when several teams work on the same product.
Revise requirements as the design becomes real
Requirements are a starting agreement, not a substitute for learning. Prototypes can expose awkward handling, difficult assembly or test conditions that were overlooked. When that happens, update the requirement deliberately: note what changed, why it changed and whether the proposed solution still serves the original user need. Do not quietly lower a limit simply because a prototype missed it.
Before a design moves toward production, review the requirements as a set. Check for contradictions, missing conditions and statements that no one knows how to verify. The goal is not the longest possible specification. It is a shared, testable description of success that leaves room for the team to find a practical way to achieve it.
