Types of Design Reviews and When to Use Each

Engineering teams use different types of design reviews at different stages of product development, from informal peer and supplier reviews to formal gates such as preliminary design review and critical design review. Each serves a distinct purpose, brings together different participants, and requires a different level of technical detail.

This article explains the major types of engineering design reviews, when to use them, and what each should help the team decide. For a broader guide to planning reviews, preparing technical context, collecting comments, resolving issues, and documenting decisions, see our complete Engineering Design Review Guide.

The types of engineering design review are the checkpoints a design clears at each stage of a program, from defining requirements to releasing parts for production. Seven recur across most hardware teams:

1. Requirements review. Run at program start, it confirms that stakeholder needs are captured as clear, verifiable requirements.
2. System / conceptual design review. Weighs feasibility and system-level tradeoffs across competing concepts before detailed design begins.
3. Preliminary design review (PDR). Checks whether the chosen architecture can meet the requirements, early in detailed design.
4. Critical design review (CDR). The full pass over the finished design, drawings, and analysis at the sign-off gate before build.
5. Test readiness review (TRR). Verifies that test plans, apparatus, and articles are ready before testing begins.
6. Final design review (FDR). Evaluates test results and resolves any anomalies before the design is handed to production.
7. Production readiness review (PRR). Reviews first article inspection results and process capability before full-rate production.

Each review sits where its class of error is still cheap to fix, so a tolerance or interference problem that's a quick redline at CDR doesn't reach the supplier as scrap.

Types of engineering design reviews

There's no universal standard behind these seven review types. Different organizations use different names for them, run some in the same session, and skip others outright. But the full set maps cleanly onto the phases that a product moves through, from first requirements to first article. The table below lays the review types side by side, with more detail on each further below.

What is the purpose of a design review?

A design review is the meeting, or the series of meetings, where the people who understand the product decide whether to commit to it, whether an approach is sound, whether a drawing is ready to release, and whether a design risk is worth carrying into the next phase. Every one of those calls gates the work downstream, which means a program advances only as fast as its reviewers can discuss, approve, or flag the designs in front of them. Read that way, the purpose of a design review is as much about aligning a team on design intent as it is about catching mistakes in the CAD.

Who participates in a design review is often dictated by the decisions ahead of the team, though most reviews draw on the same set of roles. The design engineers who own the parts present their work and defend the design intent behind it. The lead or responsible engineer runs the review and owns the dispositions, ruling on what's approved, what's conditional, and what has to change before release. Subject matter experts in the stressed disciplines like structures, thermal, materials, and tolerancing, judge the design against failure modes they've encountered before. Manufacturing and quality may review for producibility and inspectability, catching the DFM violation or an uninspectable callout before the design reaches the floor. The customer or program office holds the design to the requirements that set the program in motion.

Where design reviews used to involve a lot of coordination to ensure all these SMEs are in the same room or video call at the same time, much of the work can now happen asynchronously. In an async review in CoLab, each reviewer marks up the model and drawings on their own schedule and feedback attaches to the exact geometry it concerns. With fewer collaboration constraints, engineers can make CAD and drawing changes more quickly than ever before.

The seven design review types, and when to use each

Each of the seven answers a specific question at a specific point in the program. The names vary between teams, but the intent behind each holds.

Requirements review

The requirements review comes first, and its job is to confirm the team has captured the product's intended function in language precise enough to design against and verify against later. Everything downstream leans on it, which is why it belongs before anyone commits to a concept, while the requirements are still cheap to change. It's done when every requirement is unambiguous and verifiable, and each one traces back to a documented stakeholder need rather than an assumption nobody checked.

System / conceptual design review

With requirements settled, the system or conceptual design review weighs the competing ways to meet them. This is the stage for feasibility and the major tradeoffs at the system level, before detailed design commits the team to a path. Run it while changing direction still costs a meeting rather than a quarter, and aim to leave with one concept the stakeholders have agreed on and the rationale documented, so the same debate doesn't reopen midway through detailed design.

Preliminary design review (PDR)

A preliminary design review, or PDR, is the first hard check on whether the chosen architecture can meet the requirements. It comes early in detailed design, once the architecture and the major interfaces are defined but while the drawings are still cheap to change. A PDR does its job when it surfaces the weak points early enough to act on them, each one assigned to an owner with a mitigation plan, while the overall approach holds up.

Critical design review (CDR)

The critical design review, or CDR, is the full pass over the finished design, its drawings, and its supporting analysis before anything is released to build. By the time you run it, at the sign-off gate between detailed design and manufacturing, the design should be complete. A CDR clears when the design holds up to design for manufacturability checks, the drawings carry complete GD&T callouts, the tolerance stack-ups close, and nothing is left to come back later as scrap, rework, or an engineering change. Much of what used to fill the first hour of a CDR was mechanical, dimensions that disagree between views, callouts that are missing, BOM lines that don't match the drawing, and that checking can now run before the review opens, so the engineers in the review spend their time on the tradeoffs that need them. Teams that run both gates sometimes conflate them, so it's worth being clear on the difference between a PDR and a CDR. The PDR tests whether the approach is right before the team commits to detail; the CDR approves the finished design for release.

Test readiness review (TRR)

The test readiness review is a narrower, more specialized gate. Before testing starts, it confirms the test plans, the apparatus, and the test articles are ready. Run it after the build and before the first test, while there's still time to close an instrumentation gap without losing a slot on the schedule. It's done when every planned test is defined, instrumented, and tied to the requirement it verifies, so the results resolve the question instead of raising new ones.

Final design review (FDR)

Once testing is complete, the final design review evaluates the results and works through whatever the tests surfaced before the design is handed to production. A good one ends with results that meet the requirements and every anomaly resolved or formally dispositioned, so nothing unresolved crosses into manufacturing.

Production readiness review (PRR)

The production readiness review is the last of the seven. After the first parts come off the line, it reviews the first article inspection results and confirms the design and the process are ready to scale before the program commits to full-rate production. It passes when first article inspection checks out, the process demonstrates capability against the drawing tolerances, and the cost estimates are revised to reflect what the part actually takes to make.

Formal vs. informal design reviews

The seven types cut across a second distinction, whether a design review is formal or informal. The two can look nearly identical from the outside, so what separates them is who takes part and why. A formal design review brings in stakeholders from outside the immediate design team, subject matter experts, quality, sometimes the customer, and follows a defined structure with an agenda, a decision record, and rules in the project plan about who has to attend. An informal design review is arranged on short notice or ad hoc, usually to bring two disciplines together on a shared problem, like a mechanical and an electrical team working out a packaging conflict neither owns alone.

Technical vs. project design reviews

The other split is technical versus project, which comes down to the altitude of the discussion. A technical design review goes deep on a specific part of the design with a small group of engineers and subject matter experts, and produces actions at the task level, whether it's run formally or not. A project review pulls in a wider group, sometimes including the customer, and stays higher up, taking the major points from the technical reviews and weighing them against budget, schedule, and resources. Because of who attends, project reviews are almost always formal.

Why the design review process becomes a bottleneck

An outdated design review process is an expensive bottleneck, and it's usually the same one. Most teams run design review as a checkpoint rather than a decision-making process. A design gets approved or sent back, but the reasoning behind the call rarely gets recorded. Why a tolerance was opened up, why a supplier was asked to revise, why a feature was flagged, that lives in one engineer's memory or in an email thread, and the next program starts without it, re-deriving decisions that were already made once.

It stays a bottleneck because the judgment doing the work is concentrated in a few people. The experienced reviewer catches the mistake that would otherwise derail the program because they've seen it before and know where to look, and that group isn't growing. Many of the most experienced reviewers are within a few years of retirement, and generative design and AI-assisted CAD are about to push more design throughput toward the ones who remain than they've had to check before. Running review as a checkpoint spends that judgment twice over, first on the routine drawing checks a tool could clear, and again by not capturing it when it's given.

Where AI fits into design review

Of everywhere AI is entering engineering work, design review is where it's delivering ROI today, ahead of generative design. The reason is workflow fit. AI design review analyzes the models and drawings engineers already produce, applies the standards a team already has, and surfaces the issues a reviewer would find anyway, only earlier and more consistently. It augments the process a team already runs instead of asking them to redesign how they work, which is what capturing value from generative design still requires.

In practice that means running the routine checks before a person opens the file. AutoReview, CoLab's AI peer checker, reads a drawing or 3D model against your own standards, guidelines, and checklists and flags the errors and non-conformances a first-pass review would catch, from GD&T and tolerancing gaps to BOM mismatches and manufacturability problems on machined, sheet metal, and molded parts. The checks that used to fill the first hour of a review run before it starts, so reviewers spend their time on the tradeoffs that need judgment.

The larger shift is what happens to the decisions. When feedback and the reasoning behind it are captured against the design instead of lost to a meeting, each review adds to what the next one starts with, and lessons learned from past programs surface when a similar part comes up again. That record is what turns design review from a checkpoint into a decision-making process, and it's the same foundation that will matter as generative tools start producing more candidate designs than a team can validate by hand.

The results show up in the review loop. AGI cut its design-review cycle time by 63%, from six or more revisions down to one or two, and took three months out of a tech transfer. To see what that looks like in practice, walk through how teams run AI-powered CAD review in CoLab, or watch a review come together below.