What I look for in a hardware design review

A design review is the cheapest point in a hardware project to find a problem. Before boards are ordered, a fix is an edit. After boards are built, the same fix is a rework, a respin, or a schedule slip. After production starts, it can be a recall.

The later a problem is found, the more it costs to fix. Illustrative, not to scale.

Most teams know this and hold reviews. The trouble is that many reviews turn into a scan of the schematic for typos while the expensive problems sit somewhere else. Here is what I look for, roughly in the order I look for it.

Start with the requirements, not the schematic

A review checks a design against something. If no one has written down what the product must do, the review can only check that the circuit is internally consistent, which is the least useful thing to check.

Before opening the schematic, I want to know:

What the product does, in a paragraph.
The environment: temperature range, enclosure, moisture, vibration, how it gets dropped.
How it is powered, and how long it has to run.
Where it will be sold, which decides the compliance path.
Target cost and expected volume.
What has already been decided and is not up for debate.

A surprising number of findings come from this step alone. The battery cannot deliver the peak current. The enclosure leaves no room for the antenna. The part chosen for cost is not rated for the temperature range.

Light is part of the environment too, and it is rarely on the list. Every PN junction is a photodiode whether you meant it to be or not: photons with enough energy create electron-hole pairs, and the junction turns them into current. In a standard molded package the mold compound blocks the light. Tiny packages and chip-scale parts, chosen to save board space, give the silicon much less cover, and some leave it exposed. A product built with them can be solid on the bench and in the lab, then act up outside, and only in direct sunlight. That makes it hard to diagnose: the symptom comes and goes with the sun angle, the clouds, and how the unit is held, and nothing in the schematic or the firmware points to light.

I have tracked this down several times. Dark plastic helps most, though not always completely, and white plastic passes more light than it looks like it should. The decisive test costs nothing: shade the board with a piece of cardboard during the test and watch the problem go away. If the product will be used outdoors, I check the package choices against that, and ask what the enclosure material does to light. It only fails in sunlight covers the physics, the test, and the fixes.

Architecture and the block diagram

Next is the block diagram, because architecture problems are the most expensive to fix later. I look at:

Partitioning. Which jobs belong in hardware, which in firmware, and which in an FPGA or a second processor. Is anything doing a job it is poorly suited for?
Margins. Processor headroom, memory, power, thermal, and timing. A design that only works at nominal values will not survive production tolerances.
Interfaces between subsystems. Voltage levels, timing, who drives what during power-up and reset, and what happens when one side is unpowered.
Single points of failure. Sole-source parts, a single clock source, a connector that carries everything.

Power

Many bring-up problems turn out to be power problems. For battery products, Battery-powered design covers the budget in more depth. I check:

The power tree: every rail, its source, its load, and its sequencing.
Worst-case current, including startup, radio transmit bursts, and motor stall.
Regulator stability, input and output capacitance, and layout notes from the datasheet.
Component stress: voltage, current, power, and temperature on each part at worst case, including the capacitance ceramic capacitors lose under DC bias.
Brown-out and reset behavior. What happens when the battery sags or the cable is pulled mid-write.
Protection: reverse polarity, overvoltage, ESD, and inrush.

Signals, clocks, and interfaces

Pull-ups, pull-downs, and default states for every pin that matters during reset.
Clock sources, load capacitance, and placement.
High-speed interfaces: impedance, length matching, and reference planes.
Analog paths: grounding, filtering, and how far noisy circuits sit from sensitive ones.
Connectors: pinout, keying, current rating, and what happens if a cable is plugged in backwards or hot.

Firmware hooks in the hardware

Firmware teams live with hardware decisions for the life of the product. I look for:

Debug and programming access that survives into the enclosure, and a way to lock it on production units.
A way to update firmware in the field, and to recover from a failed update.
Spare pins, test points, and a status LED or log output.
Board revision identification that firmware can read.
Secure storage for keys and a way to verify firmware before it runs, if the product connects to a network. Designing connected products for EU and UK cybersecurity rules covers what to build in.

Layout

When layout is ready, the review shifts to the board itself:

Placement against the mechanical drawing, including keep-outs, connectors, and mounting.
Stackup, impedance notes for the fab, and decoupling placed close to the pins it serves.
Return paths and plane splits under fast signals.
Thermal paths for parts that run hot.
Antenna placement, keep-outs, the matching network, and a way to measure conducted RF power.
Creepage and clearance where higher voltages are involved.

Manufacturing and test

A board that works on the bench still has to be built thousands of times and tested quickly. I check:

Footprints and pin numbering against the parts actually being bought, including package variants of the same base part number.
Panelization, fiducials, and assembly notes for the contract manufacturer.
Test points that a production fixture can reach (see Designing for production test).
Fixtures and test software sized to the volume: simple and manual for a pilot run, automated as volume grows.
A plan for how each board will be tested, and how long it will take.
Part availability, lifecycle status, and second sources for anything critical, judged against how long the product has to be built and supported.

What a complete manufacturing package includes covers what the factory needs from you.

Compliance

Compliance testing at the end of a project is pass or fail. A review is the time to catch what will fail:

Fast edges and long traces that will radiate.
Cables leaving the enclosure without filtering.
Missing ESD protection on exposed connectors.
Radio modules placed in ways their integration guide does not allow.
Safety spacing, labeling, and insulation for the markets you sell into.

Plan for compliance from day one covers the rest of the path, from early pre-scans to final testing.

The seams between disciplines

The most valuable findings rarely sit inside one discipline. They sit where two meet: a mechanical change that moves a connector the firmware depends on, a power supply that is fine on its own but injects noise into a radio, a test plan that assumes access the enclosure no longer allows. These are hard to see from inside any one team, and they are the main reason to bring in a reviewer from outside.

Getting the most out of a review

Review early. A block-diagram review before schematic capture often saves more than a full schematic review later.
Share the context. Requirements, the block diagram, datasheets for unusual parts, and known open questions.
Ask for findings ranked by risk. A long list of equal-weight comments is hard to act on. The few items that could cost a respin should be at the top.
Close the loop. Track each finding to a decision: fixed, accepted, or deferred, and why.

My schematic and layout review checklist is a printable version of what I check.

If you have a design heading toward a board order and want a second set of eyes, get in touch.