Engineering design review: a prototype checklist, and where AI helps
An engineering design review is the checkpoint where a team stops, shows its work, and decides whether a design is ready for the next prototype, the next spend, or the next gate. Here is how to prepare one, a checklist you can reuse, and an honest look at where AI can speed up the review and where an engineer still has to sign off.
October 22, 20268 min read
Written by Konstantin Dolgan, Ph.D., NPDP
Founder & CEO, Product Development Engineer
Published October 22, 2026
What is an engineering design review?
An engineering design review is a scheduled, structured evaluation of a design by people with the right expertise, held to decide whether the design is mature enough to move to its next stage. It looks at requirements, analyses, drawings, schematics, code, test results, risks, cost, and schedule, and it ends with a recorded decision and a list of actions.
NASA's systems engineering handbook draws a useful line between two kinds of review (NASA Systems Engineering Handbook, Appendix):
- A peer review is an independent evaluation by subject matter experts who do not have a vested interest in the work, often held on a selected work product to find defects before it moves into a milestone review.
- A milestone review, such as a Preliminary Design Review (PDR) or Critical Design Review (CDR), decides whether the whole design can move forward. NASA defines PDR as the review that shows the preliminary design meets requirements with acceptable risk and establishes the basis for detailed design, and CDR as the review that shows the design is mature enough to proceed with full-scale fabrication, assembly, integration, and test.
A startup building its first product does not need NASA's paperwork. It does need the same two habits: expert eyes on the work before money is committed, and a clear decision at each gate. That is what a hardware design review is for.
Design reviews along the prototype path
The names vary between companies. What matters is that each review asks the question that fits the stage. This is how we map common review gates to a typical idea-to-product path.
Gate | Main question | Typical inputs | Next step it unlocks |
|---|---|---|---|
Concept review | Does this concept meet the core user need, and is it feasible? | Requirements draft, sketches, competing concepts, early risk list | CAD and first proof-of-concept prototypes |
Preliminary design review (PDR-style) | Does the chosen architecture meet the requirements with acceptable risk? | Architecture, key part choices, early CAD and schematics, trade studies, test plan outline | Detailed design |
Pre-build design review (CDR-style) | Is the detailed design ready to build and test? | Full CAD, drawings, schematics, PCB layout, BOM, firmware plan, verification plan | Prototype fabrication and assembly |
Prototype test review | What did the prototype prove, and what has to change? | Test results, bring-up log, user feedback, open issues | Next prototype revision or engineering changes |
DFM review | Can the chosen supplier make this reliably at the target cost? | Production drawings, tolerances, materials, supplier feedback | Quotes, tooling, pilot build |
Pre-freeze review | Is the design stable enough to lock before tooling? | Closed actions, final test evidence, change history | Design freeze and release |
Related guides: what a design for manufacturing review checks, design freeze, and stages of product testing. For the full path from requirements to verification, see the engineering design lifecycle.
Before the review: what to send, and when
Most weak reviews fail before the meeting starts. Reviewers see the files for the first time on the screen, nobody agreed what "pass" means, and the discussion drifts.
NASA's systems engineering requirements (NPR 7123.1D, Appendix G) list, for its technical reviews, that the agenda, success criteria, and instructions to the review board are agreed before the review, and that the technical products are made available to participants beforehand (NASA NPR 7123.1D, Appendix G). Scaled down for a product team, that becomes a simple review pack:
- Purpose and gate: which review this is, what decision it must make, and the pass criteria.
- Requirements: the current requirements list, with changes since the last review highlighted.
- Design data: CAD (native files and a neutral format), drawings, schematics, PCB layout, BOM, firmware architecture.
- Evidence: calculations, simulations, test results, and prototype findings, each tied to the requirement it supports.
- Risks: the current risk list or design FMEA, with what changed. See design failure mode analysis.
- Open issues and past actions: what is still open from the previous review and why.
- Cost and schedule: BOM cost estimate, long-lead parts, and what the next step will cost.
Send it early enough for reviewers to actually read it. A few days is common; the right lead time depends on the size of the pack.
Design review checklist for a hardware prototype
Use this design review checklist as a starting point and scale it to the gate. A concept review touches each line lightly. A pre-build review should answer every line with evidence.
Requirements and use
- Every requirement is testable and has an owner
- Each requirement traces to a design feature and a planned verification test
- Use cases, misuse cases, and the operating environment (temperature, moisture, drops, vibration) are stated
Mechanical
- Wall thickness, draft, ribs, and bosses suit the intended process (3D printing now, molding or machining later)
- Tolerance stack-ups done for critical fits and mating parts
- Fasteners, snaps, seals, and assembly order make sense to the person who will build it
- Thermal paths and venting checked where electronics or batteries sit
- Enclosure clears the board, connectors, cables, and battery with service access
Electronics and firmware
- Schematic reviewed against datasheets, with power budget and margins
- Test points, debug and programming access, and current-measurement points are in the layout (see board bring-up)
- Firmware architecture, update path, and failure behavior are defined
- Radio, antenna, and EMC risks are noted early when the product is wireless
Manufacturability and supply
- Parts are available, not end-of-life, with second sources where practical
- The design matches the processes of the shop or supplier that will build it
- Assembly steps and special tools are listed
Testing, risk, and compliance
- Verification plan covers every requirement
- Top risks have mitigations and owners
- Applicable standards and certifications are listed, with when testing must happen
Cost, schedule, and decision
- BOM cost estimate and the cost of the next build are known
- Long-lead items are ordered or flagged
- Decision recorded: go, go with actions, or no-go
AI design review: where AI helps, and where it does not
AI assistants are now part of many engineering workflows, and a design review is a natural place to use them. The useful question is not "can AI review my design?" but "which parts of the review are easy to verify if the AI is wrong?"
NIST's Generative AI Profile names the core risk plainly. It calls it confabulation: generative AI producing confidently stated but erroneous or false content, including false reasoning or citations that can mislead people into trusting the output.
The same document warns about automation bias, meaning excessive deference to automated systems, and lists eased exposure of trade secrets among its intellectual property risks (NIST AI 600-1). All three matter in a design review.
Review task | Where AI can help | What an engineer must own |
|---|---|---|
Preparing the pack | Summarize what changed since the last revision; turn meeting notes into an action list; draft the agenda | Deciding what the review must decide and the pass criteria |
Requirements check | Flag vague, duplicate, or untestable requirement wording; draft a traceability table from documents you provide | Whether the requirements are the right ones for the user and the market |
Document cross-checks | Compare BOM part numbers against the schematic or drawings; spot mismatched revisions and missing callouts | Confirming every flagged item against the source files |
Datasheet and standards lookup | Pull candidate limits and notes from datasheets you supply | Verifying values in the original document; interpreting standards |
Question generation | Draft "what could go wrong" questions and misuse cases to seed the discussion | Judging which risks are real and how severe they are |
Firmware review | Explain unfamiliar code, suggest test cases, flag suspicious patterns | Code review, testing on real hardware, safety and security decisions |
The decision | None | Go, go with actions, or no-go, signed by accountable people |
For a tool-by-tool view of where AI saves time in CAD, PCB layout, firmware, and simulation, see AI tools for hardware prototyping in 2026. If your concept started as an AI image, read can your AI-generated product actually be built? before the first review.
How to run an AI-assisted design review without losing control
- Check data terms first. Before uploading CAD, schematics, or code, confirm the tool's data and confidentiality terms are acceptable for your IP. When in doubt, use excerpts or an approved internal tool.
- Give the AI the source files, not your memory. Ask it to work only from the documents in the pack and to cite the file and page for every finding.
- Run the AI pre-pass before the meeting. Treat its output as a list of candidate issues, and have an engineer triage them: confirmed, false alarm, or needs data.
- Keep the meeting human. Reviewers discuss confirmed issues, risks, and trade-offs. Nobody accepts a finding just because the AI produced it.
- Record what AI was used for. Note in the review record which checks were AI-assisted and who verified them. This helps later reviews, audits, and anyone inheriting the design.
- Close the loop. Actions go into the tracker with owners and dates, and any design change follows your engineering change order process.
Who should be in the room
Invite the people who designed the work, the people who will build, test, and buy it, and at least one reviewer who did not do the work being reviewed. That last seat is the one founders skip most often, and it is the one most likely to catch a blind spot.
For medical devices, the rules changed in 2026.
FDA's Quality Management System Regulation (QMSR) took effect on February 2, 2026 and incorporates ISO 13485:2016 by reference (FDA QMSR).
In the final rule, FDA acknowledged that the QMSR no longer states the old explicit requirement for a reviewer without direct responsibility for the stage under review.
It noted that ISO 13485 clause 7.3.5 requires design reviews to include representatives of functions concerned with the stage being reviewed, as well as other specialist personnel, and that it expects a similar approach to design review as under the previous regulation (Federal Register, QMSR final rule).
In practice, keep an independent reviewer. For what else changed, see FDA QMSR 2026 for medical device founders.
After the review: actions, decisions, and the next gate
- Record the decision and the reasons, including what evidence it relied on.
- Give every action an owner and a due date, and review open actions at the start of the next review.
- Route changes through change control once a design is released to a supplier. See the engineering change order process.
- Feed the next gate: a pre-build review leads to fabrication and, for electronics, board bring-up; a passed test review can lead to a hardware beta test; a pre-freeze review leads to design freeze; the first production parts get a first article inspection.
How LA NPDT approaches design reviews
LA NPDT does design, engineering, and prototyping in-house at our facility in Ruston, Louisiana. Parts and components may be sourced globally; the development work stays under one roof. For a design review, that means the people who model the parts, lay out the boards, write the firmware, and build the prototypes can look at the same design together, next to the physical prototype.
Our view on AI in reviews is simple: use it where its output is easy to check, and keep an accountable engineer on every decision.
If you have a design heading into its next prototype and want an engineer's view before you spend on the build, see our product development services or book a free initial consultation. Phone: +1 318-200-0526.
Design heading into its next prototype?
Talk with an engineer about your design review, open risks, and what to check before you spend on the build. Phone: +1 318-200-0526.
Sources
Frequently asked questions
What is an engineering design review?
An engineering design review is a planned, documented evaluation of a design by qualified people to decide whether it is ready for its next stage. It checks requirements, design data, test evidence, risks, cost, and schedule, and ends with a recorded decision and owned actions.
What should an engineering design review checklist include?
Requirements and traceability, mechanical design and tolerances, electronics and firmware, manufacturability and part supply, the verification plan, top risks, standards and certifications, cost and schedule, and a recorded go, go with actions, or no-go decision.
Can AI do a design review?
AI can support a design review by summarizing changes, cross-checking documents, and drafting questions, but it should not make the decision. Generative AI can produce confident, wrong answers, so an engineer must verify every AI finding against the source files.
What is the difference between PDR and CDR?
A Preliminary Design Review (PDR) confirms the chosen design approach meets requirements with acceptable risk before detailed design starts. A Critical Design Review (CDR) confirms the detailed design is mature enough to build, assemble, and test.
Who should attend a hardware design review?
The engineers who did the work, people from manufacturing, testing, and purchasing, the product owner, and at least one qualified reviewer who did not work on the design being reviewed.
How often should you hold design reviews during prototyping?
Hold one at each major gate: concept, preliminary design, before each prototype build, after prototype testing, before tooling or DFM sign-off, and before design freeze. Smaller peer reviews can happen in between on individual parts or boards.
Services related to this guide
- Product design servicesIndustrial design and CAD taken all the way to manufacturable files.
- Best industrial design firmsWhich studios take an idea from form to manufacturable hardware, and what they charge.
- Prototype designLooks-like, works-like or pre-production: what each proves and what it costs.
- Product development examplesReal projects we designed, prototyped and shipped.
