PCB Design Review Checklist (2026 Edition)

A good board has a hundred ways to be subtly wrong, and no engineer holds all hundred in their head on a given afternoon. That’s why the checklist survives every change in tools: it turns “did we remember?” into “did we check?” — a repeatable pass instead of a hopeful one.

The catch is that a checklist doesn’t work by existing. It works when it’s applied the same way every time, by people who can actually see the design, with the results written down. Use the list below as a working PCB design review checklist — but read the two sections at the end first, because they’re the difference between ticking boxes and running a review that holds up.

Before you open the schematic

Half of review failures are set before the first net is drawn. Start with context, not components.

• Requirements. A written spec — functions, performance, environment? Does the design’s scope match it?
• Interfaces. Every external interface defined: levels, protocol, connector, pinout, mating part?
• Constraints. Hard constraints captured — size, cost, thermal, regulatory, mandated parts?

Power review

Power problems are the ones that turn up at bring-up, so this section earns its length.

• Rails. Every rail’s voltage, tolerance and worst-case current identified? Each source sized with margin?
• Sequencing. Where parts need it, is the power-up and power-down order enforced with enables and supervisors?
• Derating. Caps, inductors and regulators inside their derating? Is the rating stated in the BOM, not assumed?
• Decoupling. Decoupling per device per datasheet — bulk and local, with a short return path?

Connectivity review

This is where a clean rule check lulls you to sleep. The netlist can be legal and still wrong.

• Pin assignments. Each device pin on the net you intended? Swappable pins assigned deliberately, not for routing convenience?
• Net naming. Nets named consistently and meaningfully? No default auto-names left on anything critical?
• Signal direction. Each net driven once — no dueling drivers, no floating inputs, pull-ups and pull-downs present?

A passing ERC won’t confirm any of this — it checks the rules, not your intent. That gap is worth understanding on its own; we cover it in why ERC and DRC are not enough.

Component review

In 2026, the part you chose is only as good as your ability to buy it for the life of the product.

• Availability. Every part sourceable today? A second source for anything critical or long-lead?
• Ratings. Voltage, current, power and temperature ratings meet the worst case? Right package and temp grade?
• Lifecycle. Anything already NRND or near end-of-life? A plan for the parts likeliest to go obsolete?

Layout review

The schematic says what connects; the layout decides whether it works.

• Return paths. Every high-speed net over a continuous reference plane, with no split crossed?
• Clearances. Creepage and clearance right for the voltages present? Manufacturing spacings and keepouts held?
• Critical nets. Length- and impedance-controlled nets to spec? Diff pairs matched? Sensitive nets clear of noisy ones?

Manufacturing review

A board that can’t be built or tested economically isn’t finished, however elegant the schematic.

• Assembly. Footprints verified to the datasheet? Pin-1 and polarity clear? Fiducials and panelization sane?
• Testability. Test points on rails and key nets? Programming and boundary-scan access? A real production test plan?

Documentation review

The design isn’t done when the layout is; it’s done when someone else could build, test and maintain it from what you hand over.

• Deliverables. Schematic readable and revision-controlled? BOM complete with ratings and sources? Fab package and ODB++ current?
• Decisions. The non-obvious choices and any waivers written down?

What a PCB design review checklist cannot do

Here’s the honest part. A PCB review checklist is a prompt, not a proof — and treating a ticked box as evidence is how good teams still ship bad boards.

• It doesn’t verify anything. “Decoupling — checked” is a claim. Whether the decoupling is actually right lives in the design and the datasheet, not in the tick.
• It can’t tell “checked and fine” from “skipped.” A box that’s ticked because someone looked and a box that’s ticked because someone was in a hurry look identical afterwards.
• It only catches what’s on it. The failure that bit you last spin isn’t on a generic list until you put it there.
• A clean automated check isn’t a passed item. ERC and DRC prove the design is legal, not that it’s right — so “DRC clean” doesn’t tick the connectivity items above.

None of this means drop the checklist. It means the checklist is the start of a review, not the record of one.

How modern teams manage findings

The fix isn’t a better document — it’s turning each item on your PCB design review checklist into a finding you can verify and keep. That means three habits.

• Record findings against the design, not in a doc. A finding attached to the net or component it concerns, carrying its proof, is something you can act on and audit — a ticked box isn’t.
• Give every reviewer access. A checklist is only as good as the people who can actually open the board and work through it — which is hard when review is chained to a CAD seat. (More on that in how to review a PCB design without a CAD license.)
• Keep the findings. When findings persist with the design, your checklist stops being generic and starts carrying what your team actually learned, board after board.

How Probe approaches it

Probe opens the real design to every reviewer without a CAD license. Load ODB++, or a schematic and BOM before any layout exists, then follow a net through connectors and planes to where it lands, see the function a component belongs to, and search the whole board.

It turns each item you check into a finding tied to the design — the netlist line, the layout location, the datasheet value — verifiable, searchable, and inherited by the next board. A finding on U12 pin 14 travels to the next revision; a note on page 7 of a PDF doesn’t.

And for a real part of this list, Probe runs the check itself. The connectivity items — one driver per net, no floating inputs, pull-ups present — along with several of the power and lifecycle items, are rules it evaluates against the board, with the evidence attached. That isn’t a replacement for the reviewer’s judgement; it’s a way to spend that judgement on the items that actually need it.

Most of all, Probe won’t tick a box it can’t stand behind. The hardest problem on this page is that a box ticked after a careful look and a box ticked in a hurry look identical afterwards. Probe’s checks don’t pass silently when they can’t see enough: a rule without the data it needs abstains, on the record, and names what it’s waiting for. “Checked and clean,” “couldn’t check — needs the datasheet’s pin functions,” and “not looked at yet” are three different states, and every item shows which one it’s in. The distinction this whole checklist depends on is built into the tool, not left to memory.

Use the list, but run the review

Call it a PCB review checklist or a hardware design review checklist — the discipline is the same. It’s a decades-old tool that still works, and every serious designer should keep one. Just remember what it is: a way to make sure the right questions get asked, every time. The answers — the actual verification — still need a human looking at the real design, with the findings written down where they last. Keep the list. Run the review properly around it.