Hardware design review checklist

Variety may be the spice of life, but sometimes engineering can feel pretty repetitive. Most engineers have definitely been hit by hardware issues that they've seen before or seem so obvious in retrospect, like melting LED cases or flipped flat-flex cables as @alexw on the Contextual Electronics Forum notes in his “don’t make that mistake again” list. It’s our belief that designs fail more often because a trivial issue was overlooked rather than a fundamental design flaw in one of the key functional areas.

Written by:
Allspice team
|
Updated on:
November 6, 2026

A hardware design review checklist follows the order a board is built in: schematic, power and decoupling, component derating, PCB layout, BOM and lifecycle, then release. Each line below is one checkable item. Copy the markdown into any design review and delete what doesn't apply.

Schematic review

Every item in this section has turned up as a real finding in an Allspice customer's design review.

  • JTAG and debug pin directions match the datasheet and the connector pinout
  • Net names are unique across sheets, especially after a connector moves
  • Every enable and reset pin is tied, driven or pulled to a defined state
  • Protection diode orientation matches the intended current direction
  • Interface pull-ups are present and within the datasheet range (for example, 1.5 K–2 K on HDMI)
  • I2C SDA and SCL pull-ups are sized for the bus capacitance
  • ADC inputs stay within the pin's rated range (for example, 1.2 V) across the full rail range
  • Amplifiers are checked for stability

Power and decoupling

Decoupling is easy to get wrong by an order of magnitude. In one Allspice customer review, the part's datasheet called for 10 uF on page 3, and the design carried 310 nF of total capacitance.

  • Decoupling matches the datasheet value and the placement count per pin
  • Low dropout regulators (LDOs) have sufficient output capacitance per the datasheet
  • Power-good pull-ups go to a rail that is live at that point in the power-up sequence
  • Rail sequencing is documented on the schematic

Component selection and derating

To catch derating issues in design review, check each capacitor, resistor, inductor and protection part against worst-case stress, then record the margin.

Two findings from Allspice customer reviews show why. One design put 6.3 V rated capacitors on a 5 V rail: fine on the bench, failing in the field at temperature. Another had ESD diodes rated 3.3 V on a level translator running at 4.6 V.

For a reference point, NASA's EEE-INST-002 parts derating guideline sets a 0.60 voltage derating factor for ceramic capacitors. NASA notes the factor "applies to the sum of peak AC ripple and DC polarizing voltage."

NASA uses 0.6 for resistor power on typical film styles. These are space-flight baselines, so set your own margins for commercial parts.

DC bias also shrinks ceramic capacitors. In Electronic Design, a Samsung Electro-Mechanics application engineering manager showed a 1 µF, 6.3 V X5R multilayer ceramic capacitor (MLCC) dropping to 0.36 µF. The applied bias was 3 V DC. That figure is for one part, so check the vendor curve for yours.

  • Capacitor voltage rating covers the rail plus peak ripple, with your derating margin applied (NASA uses 0.60 as a flight baseline)
  • MLCC effective capacitance at operating DC bias comes from the vendor's curve
  • Inductor saturation and RMS current ratings exceed the worst-case load current
  • Resistor power dissipation sits within the derated rating (NASA uses 0.6 as a flight baseline)
  • ESD and TVS working voltage sits above the rail it protects
  • Lifecycle status (active, not recommended for new designs, or end of life) is checked for every part number

If you check lifecycle on every board, you can automate component end-of-life checks on the BOM. For a worked example on capacitors, see how to generate a capacitor derating report with DRCY Chat.

PCB layout review

DRCY reviews schematics only, so these layout checks stay with your reviewers and your ECAD design rule checks.

  • Trace widths carry the expected current at the allowed temperature rise
  • Clearances meet the voltage between adjacent nets
  • Controlled-impedance nets match the fab's stackup
  • Plane connections use thermal relief where soldering or rework needs it
  • High-speed signals have a continuous return path on the adjacent plane
  • Footprints match the datasheet land pattern
  • Layout passes the fab's design for manufacturing (DFM) rules

BOM and lifecycle

  • Every designator has a manufacturer part number (MPN)
  • Do not populate (DNP) status is set in component attributes rather than color coding or notes
  • Single-source parts have an approved second source
  • Lifecycle status and open product change or discontinuance notices are checked for every MPN
  • The BOM matches the schematic variant being built

Release and documentation

A release only works as a record if the review points at the same version. Our post on hardware releases tied to versions says releases "give the ability to point to a specific moment in the change history without ambiguity."

  • The review is tied to the exact design version being released
  • Every section is signed off by its owner
  • Open comments are resolved or recorded with a reason
  • Fabrication and assembly outputs are generated from the released version
  • Release notes list the changes since the last release

‍

How to run a hardware design review with this checklist

A thorough hardware design review gives every checklist section a named owner and closes only when each owner signs off on a specific design version.

  1. Run the checklist after schematic capture, again after layout, and before release.
  2. Assign an owner to each section by tagging colleagues on the lines they own.
  3. Mark status as you go with [WIP], [No change] or a strikethrough for items that don't apply.
  4. Optionally, run an AI design review with DRCY as a first pass on the schematic. It does not review layout or sign off.
  5. Resolve or reply to every comment before release.
  6. Sign off each section, so the checklist tied to that design version becomes the approval record.

The audit trail for a design review approval is the checklist itself: each section's sign-off and every resolved comment, tied to the approved design version.

‍

How to use Allspice's design review checklist

If you use Allspice Hub, set up your checklist as a Design Review template, and it will populate automatically for any new Design Review. You can customize the template for your company and even for each repository. Add screenshots and reference files, then you're good to go.

If DRCY is part of your process, see how teams evaluate DRCY.

‍

Why is this better than a list on a doc?

The nemesis of process is adherence. The less friction documentation has, the more likely you are to complete it. Here is how a design review template improves on traditional checklists, like Word documents or printed paper:

  • It doesn't require copy-paste, and one less step is one less roadblock.
  • It's customized for your design, so you can delete or mark items, as in - [ ] Amplifiers checked for stability [No change].
  • It's a simplified text doc, and markdown gives some styling control without becoming distracting.
  • It automatically associates with the right design version, so it stays linked to that review in the same format.
  • It prevents double work, because you can mark an item [WIP] to show what you're currently working on.
  • It distributes effort, because you can tag colleagues or experts, as in [@jason does C143 meet our spec?].

We hope it makes your design process a little easier.

Curious about some of the other ways Allspice can improve your hardware development? Let us know below so we can tackle them in a future post, or send us an email at info@allspice.io.

‍

Hardware design review checklist FAQ

What should a hardware design review checklist include?

A hardware design review checklist should cover schematic connectivity, power and decoupling, component derating, PCB layout, BOM lifecycle status and release documentation. Write one checkable line per item, such as "Net names are unique across sheets", and give each section a named owner who signs it off.

How do you catch component derating issues in a design review?

Check every capacitor, resistor, inductor and protection part against its worst-case operating stress, using effective capacitance from the vendor's DC-bias curve. NASA's EEE-INST-002 uses a 0.60 voltage derating factor for ceramic capacitors as a flight baseline. In one Allspice customer review, 6.3 V capacitors on a 5 V rail worked on the bench and failed in the field at temperature.

What checklist format works best?

Markdown checkboxes work best because they render in GitHub, Allspice and most text editors without reformatting. Keep one specific item per line and group lines by review stage. Status markers such as [WIP] or [No change] show reviewers progress without asking.

How do you keep a record of design review approvals?

Keep the checklist attached to the exact design version under review, and record each section owner's sign-off on it. Resolved comments and section sign-offs together become the audit trail. It shows who approved each section on which version, and which open items were accepted.

‍

More from Allspice

Valentina Ratner, Co-Founder & CEO of AllSpice
Allspice
The platform hardware engineers build on

Allspice is the platform for hardware engineering teams to collaborate, automate, and supercharge their workflows. Founded by engineers and trusted by Fortune 500 teams across aerospace, robotics, semiconductors, and defense, we help teams ship better hardware, faster.