A Battle Tested Hardware Design Workflow
Why This Workflow Matters
Over four decades of new product development—across industrial controls, medical devices, and embedded systems—I’ve refined a repeatable process for turning customer needs into production hardware. This isn’t theory. It’s what actually works when schedules are tight, budgets are real, and “close enough” means a costly respin.
Every project teaches something new, but the fundamentals hold. Some steps you can compress depending on project constraints. Others you skip at your peril.
The 10-Step Process
1. Define the Problem and Constraints
The most important step—and the most commonly rushed.
As Dave Gray emphasizes in Liminal Thinking1, talk to customers to find out what they really need, not what you think they want. This distinction is critical. Marketing might say “customers want longer battery life,” but when you talk to actual users, you discover they want the device to last through a specific workflow—which might be solvable with better power management, not just a bigger battery.
Key questions to answer: - What problem are we actually solving? - What are the must-have requirements vs nice-to-have features? - What are the environmental constraints? (temperature, humidity, shock, EMI environment) - What certifications are required? (UL, CE, FCC, medical, automotive) - What’s the target cost? (Don’t design a $500 solution for a $50 problem) - What’s the production volume? (Affects component selection and testing strategy)
2. Research Viable Solutions
With clear requirements in hand, explore broadly before committing to a path.
AI tools have become valuable for exploring potential solutions. I use them to brainstorm approaches and document my thought process. This creates a record I can reference if my initial direction doesn’t pan out and I need to pivot.
Field Application Engineers (FAEs) are your secret weapon. They know about circuits and components you didn’t know existed. Build relationships with FAEs from key vendors—they’ve seen what works and what fails in production.
Application notes and reference designs save months of development time. Manufacturers have already solved common problems. Study these carefully before reinventing wheels.
Document your research: Keep notes on solutions you considered and rejected. Future-you (or your replacement) will want to know why you didn’t use that “obvious” alternative approach.
3. Build Proof-of-Concept Designs Using Evaluation Hardware
Research narrows the options; prototyping proves them. Evaluation boards are your design insurance policy.
Stitching together eval boards forces you to thoroughly read datasheets—a necessary learning process for using new ICs. You can’t skip sections when you’re trying to make hardware actually work.
What prototype building gives you: - Real measurements on actual hardware with real parasitic effects - Sensor integration testing that’s difficult or impossible to simulate - Early EMC risk assessment (I’ve used prototype hardware for quick EMC pre-checks) - Concept validation before committing to custom PCB costs
On one project, I started exploring an IC on an eval board to see if it might solve a recurring problem across several products. The idea proved successful—this approach led to a novel solution that proved valuable across multiple product lines. That discovery came from spending time playing2 with evaluation hardware to generate new ideas—time that looks “wasted” if you only think about scheduled deliverables.
Practical tips: - Buy eval boards for critical subsystems even if they’re expensive—they’re cheaper than a PCB respin - Use header pins and jumper wires liberally—you want flexibility to experiment - Take photos and notes of what works and what doesn’t - Measure everything: voltages, currents, waveforms, temperatures
4. Simulate Circuits and Verify Correlation with Prototype Behavior
Prototypes give you real data; simulation lets you understand it. Each validates the other.
Building sub-circuits in simulation requires even deeper datasheet diving and detailed design work. Exact component values must be calculated. A significant amount of learning about circuit behavior comes from simulating circuits and understanding why they behave as predicted (or don’t).
Why simulation matters: - Worst-case analysis is easier in simulation (temperature extremes, component tolerances) - Stress testing components beyond safe limits to understand failure modes - Optimization of component values before buying expensive parts - Documentation of design calculations for future reference
I once simulated a buck converter that looked perfect on paper. When I built the prototype, the inductor was saturating under load—something my simulation missed because I’d used an idealized model. Cross-checking against hardware caught this before it became a $50K respin. After updating the simulation with a real inductor model, I found the saturation, selected a higher-current part, and hardware and simulation finally agreed.
My simulation workflow: I use LTSpice primarily—it’s fast, free, and has excellent model libraries. Schematic tools have built-in simulators, but I find importing and maintaining models there more trouble than it’s worth. Transposing from a separate simulation to the schematic has never been a significant problem for me.
Correlation is critical: If simulation and hardware don’t match, investigate why. Either your model is wrong or your measurement is wrong—both teach you something important.
5. Write Initial Firmware Using Evaluation Hardware
With circuits validated in hardware and simulation, get firmware running early—it informs hardware decisions while you still have flexibility.
Writing firmware on candidate MCUs helps make design decisions early in the prototype stages. Utilizing the eval board and writing functions that control circuits and read sensor measurements helps determine if the chosen MCU is appropriate. Bottlenecks can be identified before committing to custom hardware.
Benefits of early firmware development: - MCU validation: Is it fast enough? Enough memory? Right peripherals? - Algorithm development: Control loops, filtering, communication protocols - Timing analysis: Can you meet real-time requirements? - Power consumption testing: Measure actual sleep currents, not just datasheet typ values - EMC pre-checks: Having firmware controlling prototype hardware helps during EMC testing
Test planning starts here: Now that you’re making measurements and using firmware to gather data, you can determine how you want the circuitry tested. This is the time to identify test points you want in the schematic. Write firmware test commands now to help the testing process later—don’t wait until manufacturing when you’re under deadline pressure.
Example test commands I build in: -
test_adc_channels - Read all ADC inputs and report -
test_outputs - Toggle all outputs sequentially -
test_communications - Loopback tests for UART/SPI/I2C -
test_power_modes - Cycle through sleep states and measure
current
6. Develop Schematics and PCB Layout
Prototype circuits are validated, firmware is taking shape—now integrate everything into custom hardware.
This phase requires balancing multiple constraints simultaneously. It’s where art meets engineering.
Design Constraints
Mechanical: - Component height limits (will it fit in the enclosure?) - Mounting holes and keep-out areas - Thermal management (heat sinks, airflow, copper pour) - Connector placement and cable routing
Supply Chain: - Component availability and lead times (check during design, not after) - EOL (End of Life) risk—avoid components with single-source or NRND status - Second-source options for critical components (chip shortage taught us this) - Automotive-grade or industrial-grade for better longevity - REACH, RoHS, conflict minerals compliance
Economics: - Target BOM cost and how volume affects it - Manufacturing costs (assembly complexity, test time) - NRE (Non-Recurring Engineering) costs—how many prototypes can you afford?
Quality & Reliability: - Expected lifetime and environmental stress - MTBF requirements - Derating (running components well below max ratings) - Redundancy for critical functions
Compliance: - EMC requirements (FCC, CE, industry-specific) - Safety certifications (UL, CSA, IEC) - Industry standards (medical, automotive, aerospace)
Fabrication and Assembly Considerations
Specify these before finalizing the schematic:
PCB Stackup: - Layer count, copper weight, and dielectric material (FR4 for most; Rogers for RF/high-speed) - Controlled impedance requirements (USB, Ethernet, high-speed digital) - Stackup design directly affects signal integrity and EMC performance
Manufacturing: - IPC-7351 compliant land patterns - Via treatment (plug, cap, or planarize for thermal management under components) - Surface finish selection: ENIG, HASL, or OSP based on assembly process - Capture special requirements in fabrication drawing notes
Manufacturability: - Prefer 0603 or larger passives where possible—markings aid optical inspection and rework - Minimize part number variety (more unique parts = higher cost and complexity) - IPC Class 2 for commercial products, Class 3 for high-reliability
Testability: - Choose your test strategy early: ICT, functional test, flying probe, or bench test - Place test points and programming pads during schematic capture - Write your test plan during schematic capture, not after PCB layout!
EMC and Signal Integrity
- Minimize high-impedance loop areas—the largest source of EMI
- Use solid ground and power planes—don’t compromise on this
- Keep high-speed signals short and direct; use differential signaling where appropriate
- Study eval board layouts and replicate their techniques for critical circuits—manufacturers optimize these for EMC
- Low-ESR decoupling capacitors close to IC power pins
- Separate analog and digital grounds with a single-point connection; use power plane partitioning for noise isolation
7. Continue Firmware Development During PCA Fabrication and Assembly
Boards are out for fabrication—don’t sit idle. Use this time productively.
While PCBs are being fabricated and assembled (typically 3–6 weeks), continue firmware development:
- Algorithm refinement using simulation or eval hardware
- Code review and optimization
- Documentation of firmware architecture
- Test script development for board bring-up
- User interface development (if applicable)
This parallel development saves weeks on the overall schedule. When boards arrive, you have mature firmware ready for integration, not a rushed hack.
8. Test Assembled Boards Against Simulation and Design Requirements
Boards are in hand. Methodical validation prevents nasty surprises later.
Board bring-up sequence: 1. Visual inspection before power-up (shorts, reversed components, solder bridges) 2. Power-on with current limiting (watch for shorts or excessive current) 3. Measure power rails (are all voltages correct under no-load and loaded conditions?) 4. Program and test MCU (does it boot? Can you communicate?) 5. Test each subsystem individually (ADC, DAC, communication interfaces, sensors) 6. Integration testing (do subsystems work together correctly?) 7. Environmental testing (temperature extremes, humidity, shock, vibration) 8. Compliance testing (EMC, safety, if required)
Compare against requirements: - Does it meet the specifications from Step 1? - Does hardware behavior match simulation predictions? - Are there any unexpected behaviors or anomalies?
Document everything: - Test results, measurements, waveforms - Deviations from expected behavior - Workarounds or modifications made
9. Iterate as Needed for Performance, Manufacturability, and Reliability
Rarely does hardware work perfectly on the first iteration.
Common reasons for revision: - Performance issues discovered during testing - EMC failures requiring layout or filtering changes - Manufacturing feedback (components hard to place, test coverage inadequate) - Cost reduction opportunities identified during prototype build - Reliability concerns from environmental testing - Component obsolescence requiring redesign
Make revisions count: - Batch multiple changes together to minimize iterations - Prioritize must-fix issues vs nice-to-have improvements - Consider the cost of delay vs the cost of less-than-perfect first production
When to stop iterating: Good enough is sometimes better than perfect. If the design meets requirements, passes compliance, and is manufacturable, resist the urge to “just make one more improvement.” Shipping a good product beats perfecting a prototype that never reaches production.
10. Document and Publish Design Decisions and Theory of Operation
The most neglected step—and the most valuable long-term.
Documentation serves three audiences: 1. Your future self (you won’t remember why you made that decision in 6 months) 2. Your team (sustaining engineering, manufacturing, quality) 3. Your successor (the person inheriting your design in 5 years)
What to document:
Design Rationale: - Why did you choose this topology or architecture? - What alternatives did you consider and reject? Why? - What were the key tradeoffs?
Theory of Operation: - Block diagram showing signal flow - Explanation of each major subsystem - Critical timing diagrams - Power budget and thermal analysis
Lessons Learned: - What didn’t work during development? - What surprised you? - What would you do differently next time?
Tribal Knowledge: - Things not in datasheets that you learned the hard way - Special assembly or test procedures - Known limitations or quirks - Recommended spare parts for field service
Component Selection Notes: - Why specific components were chosen - Second-source alternatives - Critical parameters for replacement parts
Test Procedures: - How to verify the design works - Calibration procedures - Troubleshooting guide
Where to store documentation: Place documentation in a stable, simple, and maintainable repository that is and will be accessible over time. Options include: - Company wiki or knowledge base - Version control (Git) alongside design files - Engineering documentation management system - At minimum: PDF stored with project files
I’ve learned this the expensive way: Every hour spent documenting saves 10 hours of archaeology later. When a customer issue arises 3 years after product launch, documentation makes the difference between quick root cause analysis and weeks of reverse-engineering your own design.
Adapting the Workflow
This isn’t a rigid checklist—it’s a framework. A simple sensor board might skip extensive simulation. A medical device demands far more documentation and validation. A cost-optimized consumer product might compress testing. The key is knowing which steps you can compress and which ones you skip at your peril.
Some steps are negotiable based on time, budget, and risk tolerance. You can skip prototyping when you’re using a proven reference design with minimal changes. You can skip simulation for simple, well-understood circuits. You can scale back testing for internal tools where you control the environment.
But after four decades, these are the steps I never skip: 1. Talk to actual customers (not just sales/marketing intermediaries) 2. Check component availability during design, not after 3. Build prototypes before committing to layout 4. Write the test plan during schematic capture 5. Document decisions while they’re fresh
Conclusion
Hardware design is part science, part art, and part learning from expensive mistakes.
The best engineers I know aren’t the ones who never make mistakes—they’re the ones who: 1. Make new mistakes rather than repeating old ones 2. Document what they learn 3. Share knowledge generously 4. Remain humble about how much there is still to learn
The fundamentals don’t change: understand the problem, validate early, test thoroughly, document everything. The tools and technologies will keep evolving, but this process holds.
This is the workflow I bring to every engagement. If your team needs experienced hardware design support—from concept through production—let’s talk.