A design review is a scheduled, structured evaluation of a design by knowledgeable reviewers, at a defined point in development, meant to confirm the design actually meets requirements before more time and money get invested in it. It matters because catching a design flaw early is dramatically cheaper than catching it after tooling, production, or launch; a review that surfaces a weak point as a quick redline is far less costly than the same flaw reaching a customer as a field failure.
In practice, reviews happen at several standard points: a Requirements Review confirms the problem is well understood before design starts, a Preliminary Design Review (PDR) checks whether the chosen concept can meet requirements, and a Critical Design Review (CDR) is the final, detailed pass before committing to build. There is no single universal standard for these names or stages; organizations combine, rename, or skip some of them depending on the project’s scale and risk.
Quick Reference Table
| Review Type | When It Happens | What It Checks |
| Requirements Review (RR) | Before any design work begins | Are requirements fully and clearly understood? |
| Preliminary Design Review (PDR) | Early in detailed design | Can the chosen architecture or concept meet requirements? |
| Critical Design Review (CDR) | Before build or production commitment | Is the finished, detailed design complete and ready to build? |
| Test Readiness Review (TRR) | Before formal testing begins | Are test plans, equipment, and test articles actually ready? |
| Production Readiness Review (PRR) | Before full-rate production | Do first-article results and process capability support scaling up? |
Table of contents
Key Takeaways
- A design review is a scheduled evaluation, not an informal conversation. It has defined participants, a defined scope, and a specific go/no-go decision attached to it.
- Each review sits at a point where its class of error is still cheap to fix. A tolerance issue caught at CDR is a quick redline; the same issue reaching a supplier as scrap costs far more.
- There is no single universal standard for design review names or stages. Different organizations use different names, combine some reviews into one session, and skip others outright depending on project risk and scale.
- A Preliminary Design Review (PDR) and a Critical Design Review (CDR) are not interchangeable. A PDR checks whether the chosen approach can work; a CDR checks whether the finished, detailed design actually does work, and is ready to build.
- Reviewers must be independent from the design team to be effective. A review conducted entirely by the people who built the design tends to miss the same blind spots the design itself has.
- In a DFSS or DMADV project, design reviews are the tollgates. The Design phase typically closes with something functioning like a CDR; the Verify phase closes with something functioning like a TRR or Final Design Review.
- FMEA and design review are complementary, not the same thing. FMEA proactively identifies potential failure modes before the review; the review is the forum where those risks, and everything else about the design, get formally evaluated and challenged.
What Is a Design Review?
A design review is a scheduled, systematic evaluation of a design by knowledgeable people, typically fellow designers, subject matter experts, and sometimes the client or end customer, conducted at a defined point in a development process. Its core purpose is to confirm that a design actually meets requirements before the organization commits further resources to it, whether that’s moving from concept to detailed design, or from a finished design to full production.
A typical review follows a consistent structure: the team briefly restates the requirements the design needs to satisfy, presents the design (or, earlier in the process, competing design alternatives), and then opens the floor to reviewers, whose job is to critically evaluate the work: asking pointed questions, identifying problems, and proposing specific changes rather than offering vague praise or vague concern.
Public, Onsite, Virtual, and Online Six Sigma Certification Training!
- We are accredited by the IASSC.
- Live Public Training at 52 Sites.
- Live Virtual Training.
- Onsite Training (at your organization).
- Interactive Online (self-paced) training,
Why Does Design Review Matter?
The core financial logic behind formal design review is straightforward: each review is positioned at a point where its class of error is still cheap to fix. A tolerance or interference problem caught and corrected at a Critical Design Review is a quick, low-cost redline on a drawing. The same problem, left uncaught until it reaches a supplier or a production line, becomes expensive scrap, or worse, a field failure discovered by the customer.
This is the same underlying logic behind the widely cited 1-10-100 rule of quality: catching an issue early costs a fraction of what catching it late costs. Design review is the mechanism that applies that logic specifically to the design phase of a product or process, before physical production ever begins.
Also Read: PERT: Program Evaluation Review Technique Explained
The Standard Types of Design Reviews
This is the area where most generic content skips real detail, and it’s worth being specific, since these terms are frequently used loosely or interchangeably even though they check for different things.
Requirements Review (RR)
Conducted before any design work begins, a Requirements Review confirms that the team and the customer share the same understanding of what the design actually needs to accomplish. Skipping this step is a well-documented source of costly errors and omissions later in a project, since disagreements about requirements are far cheaper to resolve before any design work has started.
Preliminary Design Review (PDR)
A PDR checks whether the chosen architecture or concept can realistically meet the stated requirements. It happens early in detailed design, once the major approach and interfaces are defined but while changes are still relatively cheap to make. A PDR does its job well when it surfaces weak points early enough to assign a specific owner and mitigation plan to each one, while confirming the overall chosen approach still holds up.
Critical Design Review (CDR)
A CDR is the full, detailed pass over the finished design, its drawings, and its supporting analysis, conducted before anything is released to build. The design at this stage should be essentially complete; a CDR is meant to be the sign-off gate that establishes the design as the baseline moving into production or implementation.
Test Readiness Review (TRR)
A TRR verifies that test plans, equipment, and test articles are genuinely ready before formal testing begins, confirming the organization isn’t about to waste testing time and resources on preparation gaps that should have been caught beforehand.
Final Design Review (FDR) and Production Readiness Review (PRR)
An FDR evaluates actual test results and resolves any anomalies before the design is formally handed off to production. A PRR reviews first-article inspection results and process capability data before committing to full-rate production, confirming the process, not just the design, is actually ready to scale.
An important caveat worth stating directly: there is no single universal standard governing these names or their exact sequence. Different organizations use different terminology, combine several of these reviews into a single session, or skip some entirely depending on the project’s scale and risk.
A small internal process improvement project might combine PDR and CDR into one working session; a large, safety-critical system might run all five stages formally, with additional sub-reviews at the component level.
Who Should Attend a Design Review?
A well-run review typically includes:
- A chairperson, responsible for keeping the review structured and ensuring it reaches a clear decision.
- The design team, who present the design and respond to reviewer questions.
- Subject matter experts (SMEs), ideally from outside the immediate design team, to evaluate technical soundness with less inherent bias toward the current approach.
- The customer or client, where appropriate, to confirm the design genuinely addresses their actual requirements.
A specific, often-overlooked point worth calling out directly: whoever conducts the review needs to be genuinely independent from the design team to be effective. A review run entirely by the people who built the design tends to share the same blind spots the design itself has, and is less likely to catch the kind of fundamental issue an outside, more skeptical set of eyes would flag immediately.
How Does Design Review Fit Into DFSS?
This is the connection no generic engineering source makes, and it’s the most directly useful application for SSDSI’s audience. In a Design for Six Sigma (DFSS) project following the DMADV roadmap (Define, Measure, Analyze, Design, Verify), formal design reviews function as the tollgates between phases, giving structure to what would otherwise be a purely engineering-driven review process.
| DMADV Phase | Corresponding Design Review Function |
| Design | A review functioning like a PDR (early concept viability) and later a CDR (finished, detailed design ready for validation) |
| Verify | A review functioning like a TRR (is validation testing ready) and an FDR (do test results support moving to full implementation) |
Framed this way, a design review isn’t a separate activity layered on top of a DFSS project; it’s the structured decision point that determines whether a DMADV project is actually ready to move from one phase to the next, the same governing function a tollgate review serves in DMADV and DMEDI more broadly.
Also Read: Top 8 Business Process Mapping Tools – Ranked & Reviewed
Design Review vs. FMEA: How Do They Work Together?
This is a genuinely common point of confusion: design review and FMEA (Failure Mode and Effects Analysis) are related, complementary tools, not the same activity.
| Factor | Design Review | FMEA |
| What it is | A scheduled evaluation meeting or session | A structured, ongoing analysis document |
| When it happens | At specific, defined gate points | Developed and updated continuously throughout design |
| What it produces | A go/no-go decision, action items | A prioritized list of potential failure modes and effects with risk scores |
How do they connect in practice?
A well-run design review typically uses the FMEA as a direct input: reviewers examine the highest-risk failure modes and their associated effects identified in the FMEA, and specifically challenge whether the current design adequately addresses them. The FMEA does the ongoing, detailed risk identification work; the design review is the forum where that risk analysis gets formally scrutinized by people who didn’t necessarily build the design themselves.
How Do You Prepare for a Design Review?
1. Confirm Requirements Are Clearly Documented
Before presenting anything, make sure the requirements the design is meant to satisfy are written down clearly enough that reviewers can actually check the design against them, not just described verbally in the room.
2. Assemble the Right Reviewers
Include subject matter experts genuinely independent from the design team, along with the customer or client where their input is relevant to confirming the design meets real requirements.
3. Prepare a Clear, Honest Presentation of the Design
Present the actual design, including known open issues and risks, rather than a polished version that omits weak points reviewers are likely to find anyway. A review that surfaces problems the team already knew about, later, in a worse context, is far less useful than one that surfaces them now.
4. Bring Supporting Analysis, Including the FMEA
Come prepared with the relevant supporting data: test results, analysis, and the current FMEA, so reviewers can evaluate the design against real evidence rather than assertions.
5. Leave With Clear, Owned Action Items
A design review should end with specific, assigned action items, each with an owner and a deadline, not a vague sense that “some things need follow-up.” Reviewers should also be told when and how follow-up will actually be confirmed.
Real-World Example (Hypothetical)
Problem: A team executing a DMADV project to design a new medical device housing reaches its Design phase with a completed detailed design, but has never formally engaged reviewers outside the immediate design team.
Analysis: Internal team members have grown used to a specific interference risk between two components and have unconsciously stopped flagging it as a concern, treating it as an accepted, known limitation rather than an open risk.
Six Sigma approach: The project runs a formal Critical Design Review with independent subject matter experts and a representative from the customer’s engineering team, using the project’s FMEA as a direct reference point for the review discussion.
Action: An independent reviewer, without the same familiarity blind spot, flags the interference risk as a genuine concern requiring resolution before the design moves into the Verify phase.
Result (hypothetical): The issue is corrected at the CDR stage, a straightforward design change, rather than being discovered during formal validation testing, which would have required a far more costly design change under schedule pressure. This is a hypothetical illustration of independent design review catching a real risk, not a documented case study.
Common Mistakes When Running a Design Review
- Using only the design team as reviewers. A review without genuinely independent participants tends to share the same blind spots as the design itself.
- Treating a design review as a status update instead of a critical evaluation. The reviewers’ job is to ask hard questions and identify problems, not simply receive information.
- Skipping the Requirements Review at the start of a project. Disagreements about requirements are far more expensive to resolve once detailed design work is already underway.
- Presenting only the finished design without the FMEA or known open risks. Withholding known weak points doesn’t make them disappear; it just moves their discovery to a later, more expensive stage.
- Ending a review without assigned action items and owners. A review that surfaces real issues but assigns no clear follow-up ownership often fails to actually resolve them before the next gate.
Frequently Asked Questions (FAQs) on Design Review
Q: What is a design review?
A: A design review is a scheduled, structured evaluation of a design by knowledgeable reviewers, conducted at a defined point in development to confirm the design meets requirements before further resources are committed to it.
Q: What are the types of design reviews?
A: Common types include a Requirements Review (before design begins), a Preliminary Design Review (early concept check), a Critical Design Review (final detailed design sign-off), a Test Readiness Review, and a Production Readiness Review.
Q: What is a preliminary design review (PDR)?
A: A PDR checks whether a chosen design architecture or concept can realistically meet stated requirements, conducted early in detailed design while changes are still relatively inexpensive to make.
Q: What is a critical design review (CDR)?
A: A CDR is the full, detailed evaluation of a finished design, its drawings, and supporting analysis, conducted before the design is released to build. It’s meant to establish the design as the baseline moving into production.
Q: Who should attend a design review?
A: A chairperson to keep the review structured, the design team to present and respond to questions, independent subject matter experts to evaluate the design critically, and the customer or client where relevant.
Q: How does a design review fit into DFSS or DMADV?
A: Design reviews function as the tollgates in a DMADV project. The Design phase typically closes with something functioning like a PDR and CDR; the Verify phase closes with something functioning like a TRR or Final Design Review.
Final Words
A design review earns its place in a development process by sitting exactly where a specific class of error is still cheap to fix. Structured well, with genuinely independent reviewers, a clear FMEA as supporting input, and specific, owned action items at the end, a design review catches the kind of issue that’s a quick redline today and an expensive field failure tomorrow.
In a DFSS project, these reviews aren’t a separate activity; they’re the same tollgate logic that governs the rest of DMADV, applied specifically to the design itself.
Running a design review that actually catches problems, rather than one that just confirms what the design team already believed, is a core DFSS skill that pays for itself the first time it prevents a costly, late-stage redesign.
Six Sigma Development Solutions, Inc. (SSDSI) is IASSC-accredited and 5-star rated on Google Reviews, having certified 5,322+ professionals across 600+ organizations in 52 cities. Our onsite, live virtual, public, and online Black Belt training covers DFSS, FMEA, and tollgate reviews in the depth needed to run a design review that genuinely holds up under scrutiny. Explore SSDSI’s Black Belt certification to build that capability.
About Six Sigma Development Solutions, Inc.
Six Sigma Development Solutions, Inc. offers onsite, public, and virtual Lean Six Sigma certification training. We are an Accredited Training Organization by the IASSC (International Association of Six Sigma Certification). We offer Lean Six Sigma Green Belt, Black Belt, and Yellow Belt, as well as LEAN certifications.
Book a Call and Let us know how we can help meet your training needs.
