Design Reviews: Purpose and Process

A design review is a structured, cross-functional check at a defined stage of a project that asks one question: is this design good enough to move to the next stage? It evaluates whether the design meets requirements, surfaces problems while they are still cheap to fix, and produces a documented decision to proceed, rework, or stop.

Design reviews get a bad name because too many are theater: a slide deck, a room of nodding heads, and a rubber-stamp "looks good." A real design review is a gate with teeth, held at the right moment, staffed by people who can say no, working from a checklist and real evidence. This guide covers why design reviews exist, when to hold them, who should be in the room, and how their findings feed the design FMEA and the rest of your quality system.

What is the purpose of a design review?

The purpose is to catch design problems at the point where they are cheapest to fix, before they are locked into tooling, purchased parts, and production processes. A design flaw found in review costs a meeting and a redraw. The same flaw found after launch costs tooling changes, scrapped inventory, field returns, and sometimes a recall. Design reviews exist because the cost of a change climbs steeply the later you find it, so you build in deliberate stops to look hard before the money is committed.

Design review is one of three related but distinct activities, and confusing them is a common failure. Review assesses whether the design meets requirements and is ready to advance. Verification confirms the output meets the input (did we build the thing right, per calculations, tests, and analysis). Validation confirms the design meets the user's actual need (did we build the right thing, per functional and field testing). ISO 9001 treats all three as design and development controls, and they can be done separately or together, but they answer three different questions.

There is a second, quieter purpose that gets missed: alignment. A design review is often the first time manufacturing, purchasing, quality, and engineering look at the same design together, out loud, in one room. Problems that no single function would catch alone, a tolerance the process cannot hold, a part with a sixteen-week lead time, a feature that is impossible to inspect, surface only when those perspectives collide. The review is not just a pass/fail gate on the design; it is the forcing function that makes the whole team own the design's risks before anyone is committed to them.

When should design reviews be held?

At defined stage gates, not whenever someone remembers. A typical product development flow holds reviews at the end of each major phase, and the classic sequence in engineering is a preliminary (or conceptual) design review, a detailed design review once the design is fleshed out, and a critical design review before release to production. Each gate has an entry (what must be done to hold the review) and an exit (what the design must demonstrate to pass).

The number and names vary by industry, and in the automotive world they map onto the phases of APQP where design reviews are built into the product design and development phase. What does not vary is the principle: reviews sit at the transitions where the cost of change jumps, so you look hardest right before you commit tooling, right before you commit suppliers, right before you release to production. A review held after the tooling PO is not a gate, it is a status update.

Who should attend a design review?

A design review is cross-functional by definition; if only the designers show up, it is a peer chat, not a review. The point is to put people in the room who see the design from different angles and who carry the consequences of its flaws. That means someone independent of the design work itself, so the review is not the author grading their own homework.

How do you run a design review that is not theater?

The difference between a real gate and a rubber stamp is preparation, evidence, and the willingness to say "not yet." Run it like this.

1. Set entry criteria and circulate the package early. Define what must be complete to even hold the review (drawings, DFMEA, analysis, test data) and send it days ahead. A review where people read the material for the first time in the room is worthless.
2. Review against a checklist tied to requirements. Walk the design against the requirement specification, the design FMEA and a standing checklist, not against opinions. Every requirement should trace to evidence that it is met.
3. Bring the FMEA and the risks, not just the drawings. The high-severity failure modes from the DFMEA are the agenda. If a top risk has no mitigation, that is a finding, not a footnote.
4. Log every finding with an owner and a due date. A finding without a name and a date is a wish. Capture action items so they survive the meeting.
5. Make an explicit gate decision. End with one of three verdicts: proceed, proceed with conditions (specific actions before advancing), or do not proceed. "We'll figure it out later" is not a decision.
6. Retain the record. Document who attended, what was reviewed, the findings, and the decision. This is the documented information the standard asks you to keep, and the trail an auditor follows.
7. Close the loop before the next gate. Verify that the findings from this review were actually resolved before the next review opens. Open actions that roll forward unresolved are how flaws reach production.

How do design reviews feed the DFMEA and design controls?

Design review and design FMEA are partners, running on the same clock. The design FMEA is the living risk analysis, the systematic list of how the design can fail, rated by severity, occurrence, and detection. The design review is where that analysis gets challenged in front of a cross-functional group, and where new failure modes surfaced by manufacturing or the field get added back into it. Reviews feed the FMEA; the FMEA feeds the reviews; neither is a one-time document.

The findings flow downstream from there. A design review or DFMEA that flags a special characteristic hands that characteristic to the process side, where it becomes a controlled row on the control plan and process FMEA and eventually a capability requirement measured in Cp, Cpk, Pp, and Ppk. Reviews also validate that the voice of the customer captured through quality function deployment actually survived into the design. In an APQP program these connections are formalized across the APQP phases so a design review is not a standalone meeting, it is a junction where design intent, risk analysis, and process control all get reconciled.

Where design reviews break down, and how to fix it

The failures are predictable. Reviews get scheduled after the money is already committed, so they cannot change anything. The package arrives the morning of, so nobody has read it. Findings get logged and then evaporate because no one owns them or checks them before the next gate. And the same manufacturability problem gets discovered at launch, review after review, because the people who build the thing were never in the room. Every one of these turns a gate into a ceremony.

The fix is discipline plus visibility: real entry criteria, an independent chair, findings with owners, and a way to see that last review's actions are actually closed before this review opens. When design records, FMEA updates, review findings, and their closure status live in one connected system instead of scattered slide decks and email threads, the gate stays honest and nothing rolls forward unresolved by accident. That connected view across engineering, quality, and production, on top of your existing process with no rip-and-replace, is what Harmony's platform is built to provide. It matters on every program, whether you launch one high-volume part or a short batch production run, because a design flaw that reaches the floor costs the same to fix either way, and a design review is your cheapest chance to stop it.