What a design review is for
A design review is a planned meeting where people other than the designer examine a design and decide whether it is ready to move on. The purpose is to find problems while they are still cheap to fix, to check the design against its requirements, and to share knowledge. It is not an exam of the designer, and it is not a place to redesign the product from scratch in an hour.
Practice differs between organisations. Some run a handful of formal gates on large projects; others hold short informal reviews every few weeks. The principles below apply to both, and where your employer or industry has a defined review procedure, follow that.
Where reviews sit in a project
Reviews are usually tied to points in the engineering design process. Typical examples are:
- A review of requirements and early concepts, before heavy effort is spent on any one idea.
- A review of the chosen concept and its main risks.
- A detailed design review before drawings are released for manufacture.
- A review of test results before the design is accepted or handed over.
The earlier the review, the more freedom there is to change direction. The later the review, the more it becomes a check that nothing has been missed.
Roles in the room
Most formal reviews have a few distinct roles, although one person may hold more than one.
- Presenter or design owner. Explains the design and answers questions.
- Reviewers. Look for gaps, risks and mismatches with requirements. A good panel mixes people with different experience, for example design, manufacture, test and service.
- Chair or facilitator. Keeps to the agenda and time and makes sure issues are recorded.
- Recorder. Writes down issues, decisions and actions.
Reviewers who did not work on the design are valuable precisely because they do not share its hidden assumptions.
Preparing as a presenter
Good preparation makes the difference between a productive review and a confused one.
- State the purpose. Say what decision the review is meant to support, and what you want from the group.
- Circulate material early. Send documents, drawings or models to reviewers in advance, so the meeting is used for discussion rather than reading.
- Tie the design to requirements. Show which requirements are met, how you know, and which are not yet verified. Gaps in this list are exactly what reviewers want to see.
- Be open about risks and unknowns. Listing assumptions, open questions and weak points builds trust. Hiding them tends to backfire when someone finds them anyway.
- Show the reasoning. Explain why you rejected alternatives. Short decision records are useful here, because they let you point to a written reason rather than relying on memory.
- Keep the presentation focused. A review is not a full tour of the project. Highlight what changed, what is uncertain and what you need decided.
Preparing as a reviewer
Reviewers also have homework. Read the material beforehand, and decide what your role is: perhaps you are checking manufacturability, safety, testability or cost. A focused reviewer finds more than one who skims everything.
Useful questions include:
- What happens if this part fails, and how would we notice?
- Which requirement does this feature satisfy?
- What was assumed about the operating conditions, and has that been checked?
- Where are the interfaces to other sub-systems, and who owns them?
- How will this be tested, assembled and maintained?
Your questions are more helpful if they point at specific evidence, such as a calculation, a drawing or a test result, rather than a general feeling of unease. Where you spot a likely problem, say what you think the consequence would be so the owner can judge its weight.
Behaviour during the meeting
Reviews work when people feel safe to speak. Some habits help.
- Criticise the design, not the designer. Phrase comments as observations or questions.
- Presenters should listen first and avoid defending every point immediately. Note the comment, ask for clarification if needed, and respond once you understand it. The skills involved are close to those in giving constructive feedback.
- Keep to the agenda. If a topic needs a long technical discussion, record it as an action and move on.
- Separate “must fix” from “nice to have”. A long list of undifferentiated comments is hard to act on.
- Be clear at the end about the outcome. Common outcomes are approved, approved with actions, or not approved pending rework.
Where safety is involved, reviewers should raise concerns clearly even if the room is under time pressure. Staying quiet about a worry is a poor trade. The habits described under raising safety concerns apply in design meetings as much as on a shop floor.
Following up
A review that ends without recorded actions has probably achieved little. After the meeting:
- Circulate the notes, decisions and action list promptly, with owners and dates.
- Track each action to closure and record how it was resolved.
- If changes to the design result, check which requirements and tests are affected.
- Keep the review record with the project documents, so that later teams can see what was decided and why.
Common problems
Reviews can fail in familiar ways: too many attendees, material sent too late, a presentation that runs for the whole slot, a design owner who is defensive, or reviewers who have not looked at the documents. A review that is treated as a box to tick will usually find less than one that is treated as a chance to learn.
Small teams can still benefit. A short review with one or two colleagues, using the same questions, catches many errors for very little effort.
This article offers general guidance. Formal review requirements, particularly in safety-related or regulated fields, vary by country and industry, so follow the procedures and standards that apply to your work.