Design Review (DR) in Practice — A Systematic Approach from "Going Through the Motions" to "Quality Gate"

1. Why Design Reviews Often End Up as "Going Through the Motions"

When it comes to design review (Design Review, DR), many engineers' first reaction is "here we go again." The project schedule lists review points, a dozen people sit in the meeting room, and the projector flips through slide after slide. The host concludes with, "That's the design explanation for this session. Does anyone have any comments?" The room remains silent for three seconds, then someone says, "No comments," and the review is "passed." After the meeting, the necessary changes are not made, and the required confirmations are not completed. Problems follow the drawings into the pilot production phase.

This "going through the motions" style of review is costly. Identifying and correcting an issue during the design phase costs 1; during the pilot production phase, it becomes 10; and during mass production and after-sales stages, it can balloon to 100 or even higher. Design review is supposed to be the first line of defense against problems, but it often becomes a "rubber stamp" due to poor organization, inadequate preparation, and a lack of closed-loop management—appearing to pass but actually failing to catch anything.

To make design reviews truly effective, they need to be upgraded from "formal meetings" to "quality gates": gates with clear release criteria, complete input and output, serious decision-making mechanisms, and stringent closed-loop requirements. This article focuses on the "gate" positioning and provides a systematic approach to design reviews through four key stages: review types, review preparation, review organization, and issue closure.

2. Review Types and Timing: Four Gates to Safeguard the Entire Design Process

Design review is not a single meeting but a series of quality gates arranged according to the design phase. Different types of reviews focus on different issues, involve different participants, and have different release criteria. According to the general product development process, these can be divided into four gates.

First Gate: Concept Review. This occurs during the feasibility study phase, and the review object is the understanding of requirements and the overall solution. The key points to confirm are: whether customer and regulatory requirements have been fully identified and converted into design objectives; whether the overall solution is feasible in terms of technology, cost, and schedule; and whether the highest-risk new technologies, materials, and structures have been separately listed and a verification plan has been developed. If this gate passes an incorrect direction, all subsequent work will be built on a faulty foundation.

Second Gate: Preliminary Design Review (PDR). This occurs before detailed design is fully developed, and the review object is the system architecture and key component solutions. The key points to confirm are: whether the functional allocation is reasonable, whether the interface definitions are clear, whether the initial DFMEA analysis is complete, and whether key characteristics and special characteristics have been preliminarily identified. The core value of PDR is "early correction"—at this stage, the cost of modifications is still relatively manageable.

Third Gate: Critical Design Review (CDR). This occurs when the drawings and specifications are basically complete, and it is the most critical gate. The review object is the complete set of drawings, specifications, DFMEA, and design verification plans. The key points to confirm are: whether the dimensional chains and tolerances are reasonable, whether the materials and heat treatment meet the operational conditions, whether high-risk failures in the DFMEA have been addressed, and whether special characteristics have been communicated to the drawings and subsequent documents. Passing CDR means that the design is "frozen" on paper, and any subsequent changes will incur higher costs.

Fourth Gate: Production Readiness Review (PRR). This occurs after design verification is complete and before pilot production. The review object is the DV test results, sample review conclusions, initial PFMEA, and control plan. The key points to confirm are: whether all DV tests have been passed, whether there are clear action plans for failed items, whether all design issues have assigned responsible persons, and whether the conditions for small-scale pilot production are met.

These four gates are progressively layered, each with clear inputs and release criteria. Reviews are not intended to "pick faults" but to expose issues at the stage where the cost is lowest. The significance of a gate is that if the criteria are not met, the design is not released, rather than "it's good enough."

3. Pre-Review Preparation: Checklists, Documentation, and Participants

The quality of a review meeting is 70% determined by the preparation before the meeting. The core of preparation involves three elements: checklists, documentation packages, and participant lists.

Checklists are the "script" for the review. Without a checklist, the review can easily turn into a "free-for-all" discussion, where participants talk about whatever comes to mind. With a checklist, the review has a unified agenda and standard. Checklists should be compiled according to the type of review: the concept review checklist focuses on the completeness of requirements and the feasibility of the solution; the CDR checklist focuses on the completeness of drawings and specifications, the coverage of DFMEA, the communication of special characteristics, manufacturability, and inspectability. Checklist items should be "verifiable facts" rather than "how it feels"—for example, "Are critical dimensions annotated with tolerances and have they undergone dimensional chain calculations?" rather than "Is the drawing aesthetically pleasing?"

Documentation packages should be distributed in advance. Review materials should be sent to all participants at least two to three working days before the meeting, including drawings, specifications, DFMEA, calculation reports, and test plans. The purpose of early distribution is to allow reviewers to come to the meeting with questions, rather than seeing the materials for the first time. Distributing materials on-site and requiring immediate decisions is essentially forcing everyone to sign a "blank check."

Participant lists should be cross-functional. Design reviews should not be conducted solely by design personnel. At a minimum, they should include: design engineers (to explain the solution), process engineers (for manufacturability), quality engineers (for risk and verification), procurement and supplier engineers (for procurement feasibility), and test engineers (for verifiability). Customer or supplier representatives should be invited if necessary. The value of cross-functional participants lies in providing "designer blind spots"—designers may become accustomed to their own assumptions, while process, quality, and test perspectives can identify issues such as "well-designed but unmanufacturable, uninspectable, or unverifiable."

Additionally, review participants must have the authority to speak. If review comments are ignored or not followed up, participants will quickly become mere "observers." The review organizer should clearly state before the meeting that all comments will be recorded, tracked, and responded to, which is a basic respect for the reviewers.

4. Review Organization: How to Conduct an Effective Review Meeting

After thorough preparation, the quality of the meeting itself is equally critical. An effective design review meeting should follow four principles.

First, the host controls the meeting, and the designer explains "changes" rather than "everything." The worst thing a designer can do in a review meeting is to read through the entire PPT, turning the review into a "report session." The correct approach is for the designer to focus on the key points, changes, and risks of the current design—what structures have been modified, what new materials have been used, and what areas are uncertain. Reviewers should ask questions based on the checklist and documentation package. Time should be spent on "worthwhile discussions" rather than reiterating materials everyone has already seen, which can waste two hours.

Second, review comments should be categorized to avoid a "one-size-fits-all" approach. Review comments should be clearly categorized: A-class comments are issues that must be resolved before release (such as safety risks, functional non-compliance, regulatory non-conformities); B-class comments are issues that should be resolved but can be conditionally released (such as poor manufacturability, high costs); C-class comments are suggestions (such as document formatting, expression optimization). Categorizing comments ensures clear decision-making: A-class issues must be closed before release, B-class issues are conditionally released with a deadline for closure, and C-class issues are recorded for future consideration. Without categorization, review comments often end up being ignored.

Third, conclusions should be formed on-site, with clear responsible persons and deadlines. Each review comment should be confirmed during the meeting: who is responsible, when it will be closed, and what evidence will be provided for closure. The host should summarize the to-do items at the end of the meeting to avoid "forgetting what was said." Review conclusions should be clearly stated as "passed," "conditionally passed," or "not passed," rather than vague statements like "basically fine."

Fourth, control the meeting duration and pace. A review meeting typically does not exceed two hours. If the content is too extensive, it should be split into specialized reviews rather than extended indefinitely. If significant issues are identified during the review, they should be recorded and discussed in a specialized session rather than forcing an immediate solution. The output of the meeting should be "decisions and to-do items" rather than "completing the design on the spot."

5. Post-Review Closure: Issue List and Re-Review

The work at the gate is only half complete when the review meeting ends. Without closure, the review will merely bring problems back to the workstations and gradually be forgotten.

The issue list is the vehicle for closure. Each review should produce a numbered issue list, recording each item: problem description, source (which checklist item or which reviewer), level (A/B/C), responsible person, planned closure date, and closure evidence. The issue list should be incorporated into project document management and updated weekly during project meetings, rather than being scattered in meeting minutes.

Closure must be evidence-based. The standard for closing a review issue is that the responsible person submits verifiable evidence—updated drawings, additional calculation reports, completed verification test reports—rather than a simple "it has been fixed." Quality engineers or review leaders should verify closure applications, and those with insufficient evidence should be returned for rework. For A-class issues, a small-scale re-review should be organized to confirm, and a specialized review should be reconvened if necessary.

No closure, no release. This is the hard constraint of the "quality gate" positioning: A-class issues from the previous gate must be closed before moving to the next stage; B-class issues that are not closed by the committed deadline should cause the project to be "held" or explicitly escalated. Companies can set hard rules in their project management processes—such as "all A-class issues from CDR must be closed before PRR is convened"—to ensure that review conclusions have real enforceability.

Changes trigger re-reviews. The conclusions of design reviews are specific to a particular version of the design. If changes occur after the review—such as structural modifications, material replacements, or parameter adjustments—the impact on the review conclusions must be assessed. If the impact is significant, a change review or re-review should be organized, rather than assuming "a small change, no need to review." Linking design reviews with change management ensures that the gate remains effective for the "current version of the design."

6. Making Design Reviews a True Quality Gate

By connecting these stages, design reviews transform from "a meeting" into "a mechanism." To make this mechanism truly effective, it requires three supports.

Support One: Integration with DFMEA and DVP. Design review is not an isolated activity; it is a part of the design quality system. High-risk failures identified by DFMEA must be confirmed item by item during the review; design requirements and verification needs confirmed in the review are inputs for developing the DVP (Design Verification Plan); and DV test results are inputs for the next round of reviews. The review, risk analysis, and verification form a closed loop, ensuring design quality. Specifically, the review should verify that each high-risk item in the DFMEA (such as RPN or AP value overlimits) has corresponding design and verification measures, and that special characteristics have been communicated from the DFMEA to the drawings, DVP, and control plan.

Support Two: Data and Facts Drive the Discussion. The most common ineffective discussions in reviews are "I think" or "I believe" debates. To make reviews effective, all key conclusions should be data-driven: results of tolerance analysis, CAE simulation reports, historical failure data of similar products, and test data. Debates can occur during the review, but the focus should be on "whether the data is sufficient and the analysis is reasonable" rather than "whether it feels right."

Support Three: Build a Review Culture. The effectiveness of design reviews ultimately depends on organizational culture. If review comments are seen as "nitpicking," those who raise issues will be resented, and the review will revert to "going through the motions." If managers treat reviews as "blame sessions," members will avoid risks and report only good news. A healthy review culture should be: reviews are mechanisms to help designs be correct, and the earlier issues are exposed, the more valuable they are; review conclusions should be objective and not personal. The quality department and project managers should jointly maintain this culture—affirming design teams that proactively expose and resolve issues rather than penalizing them.

The investment in design reviews is worthwhile. A solid CDR may take an extra two days, but it can save weeks of rework during the pilot production phase. A well-prepared checklist can prevent a defect that could lead to a recall in the after-sales market. Transforming design reviews from "going through the motions" to "quality gates" essentially shifts the focus of quality management forward—spending more effort on the drawing stage to reduce costs in the manufacturing and after-sales stages. Gates that are well-established, strictly enforced, and effectively closed ensure that design quality is truly upheld.

The value of design reviews lies not in the meeting itself but in the gate mechanism—thorough preparation, serious decision-making, and stringent closure, ensuring issues are intercepted at the lowest cost stage.

Knowledge code: 8.2.3

Version: v20260802

Author: Quality Think Tank Quality Think Tank is dedicated to providing systematic professional knowledge, methodologies, and practical tools for quality management practitioners, helping companies continuously improve their quality capabilities.