Two questions, not two names for the same test
Verification asks, “Did we make the product according to its specification?” A workshop might check a component’s dimensions against a drawing, confirm that a joint fits within an agreed tolerance, or inspect whether a finish matches an approved sample. The result can usually be judged against a defined requirement: the part either passes, fails, or needs further investigation.
Validation asks, “Does this product serve its intended purpose?” A cabinet handle might meet every dimensional requirement yet feel awkward to grip with wet hands. A storage box might be strong enough in a load test but inconvenient to carry through a narrow doorway. Validation looks at the product in the conditions and tasks it was designed for, including needs that the original specification may have missed.
Start with requirements that can be checked
Verification becomes difficult when requirements rely on words such as “comfortable,” “durable,” or “easy to assemble” without explaining what they mean. A useful specification separates observable details from broader goals. For example, a stool specification may state its dimensions, materials, allowable movement at a joint, and finish appearance. It can also record the intended users, setting, and typical tasks so those details are not treated as ends in themselves.
Not every requirement needs a laboratory test. A maker can use a drawing review, a template, a trial assembly, or a comparison with an approved sample, depending on what is being checked. What matters is deciding in advance what evidence would count as a pass. Keeping that decision alongside the requirement makes it easier to see whether a later change calls for a new check.
Validate through realistic use
Validation works best when the test resembles ordinary use rather than a polished demonstration. If a product is meant to be opened, moved, cleaned, or repaired, give people a chance to perform those tasks with a prototype. Watch where they hesitate, what they adjust without prompting, and whether the product fits the space and tools they actually have. Ask what worked as well as what did not.
Choose participants and conditions that reflect the intended use where practical. A person familiar with the design may overlook a confusing feature that a first-time user notices immediately. Likewise, testing a carrying case while it is empty will not reveal everything about carrying it when packed. These observations do not automatically prove a design is right for everyone, but they can reveal whether its stated purpose needs a clearer definition.
When the checks disagree
A verified product can fail validation. Suppose a wall-mounted shelf meets its drawing, supports its specified load, and has an even finish. If users cannot reach stored items easily in the intended room, the issue may be the design brief rather than the workshop’s execution. Tightening the dimensional tolerance will not solve a placement or access problem.
The reverse is also possible: people may like a prototype that does not yet meet its specification. Perhaps a sample lamp is pleasant to adjust, but its pivot loosens after repeated movement. Positive feedback about its use does not remove the need to resolve that defect. Treat each finding according to the question it answers. Change the design or its requirements when the purpose is wrong; change the process or construction when the product fails an appropriate requirement.
Make both checks part of the development loop
Verification and validation are more useful as repeated activities than as final gates. Early models can test reach, balance, and layout before materials and tooling are settled. Later prototypes can check fit, assembly order, finish, and behavior under expected use. A small change to a component may require a fresh dimensional check; a larger change to how the product is used may call for another trial with users.
Record the requirement, the method of checking it, the result, and any decision that followed. Keep observations about use separate from measurements, while allowing each to inform the other. This creates a practical trail from purpose to design to finished object. The aim is not to produce paperwork for its own sake, but to avoid the costly surprise of making exactly what was specified and discovering it was not what was needed.
