A well-organised schematic can create false confidence. Hierarchical sheets, named nets, and a complete-looking BOM make a design easy to browse, but they do not prove that the intended product behaviour has been defined.
The better starting point is a short hardware requirements model that answers five questions before parts and pins are fixed. It need not be a large specification. It must, however, be explicit enough for another engineer to explain how the product starts, runs, sleeps, wakes, fails, and shuts down.
An editable desktop-robot controller project provides a useful worked example. Its engineering package contains five hierarchical KiCad modules, local symbol and footprint libraries, and a BOM with 39 line items and 75 placed quantities. The first draft is well structured around power, an ESP32 controller, a display, an environmental sensor, and a user interface. Yet it has no motor driver, battery-charging circuit, firmware, enclosure design, routed PCB, or validation data. These omissions are not merely downstream tasks; some of the related requirements should have been addressed at an earlier stage.
1. Turn Product Behaviour into States and Events
“The robot wakes when the user presses the button” sounds clear until it becomes a circuit requirement. Is the button monitored while the processor is in deep sleep? Does a short press wake the device while a long press forces shutdown? What happens if the battery is low, the display does not respond, or motion is obstructed?
Write a state model before drawing the circuit. For each state, record the entry event, powered subsystems, permitted outputs, exit conditions, and fault response. A first pass for the desktop robot might look like this:
| State | Entry event | Hardware implication | Exit or fault question |
| Off | User shutdown or depleted battery | Define what remains energised | Can a button or charger wake it? |
| Starting | Button, charger, or timed event | Rails and reset must rise in a known order | What is the start-up timeout? |
| Active | Successful initialisation | Display, sensor, radio, and possible motors may run | What triggers sleep or a safe stop? |
| Sleep | Inactivity or firmware command | Identify retained rails and wake sources | Which events remain detectable? |
| Fault | Brownout, stalled actuator, or watchdog event | Outputs must enter a safe condition | Latch, retry, report, or shut down? |
The original controller package does not establish whether motors exist, so “Active” has no defined motion behaviour and “Fault” has no actuator-safe state. That gap affects the power budget, connector count, processor I/O, protection strategy, and enclosure. A state model exposes the dependency before a motor symbol is added to the schematic.
2. Define One Power Policy, Not Just a Set of Rails
A rail name is not a power requirement. A useful power policy begins with all sources and loads, then defines voltage limits, current demand, sequencing, retention, and abnormal behaviour.
For each source and rail, specify:
- Nominal and permitted voltage range, including start-up and brownout conditions.
- Continuous, peak, and transient load estimates with stated assumptions.
- Which operating states require the rail and whether it may be switched.
- Enable ownership, power-good behaviour, discharge path, and start-up timeout.
- Source precedence, reverse-current expectations, and behaviour during connection or removal.
- Safe response to undervoltage, overload, short circuit, thermal stress, and failed start-up.
The robot draft accepts VBAT, generates SYS_3V3, and controls a VDISP_5V display rail. It also exposes PGOOD_3V3, BATTERY_LOW_N, and DISPLAY_PWR_EN. These names make the intent visible, but important policy decisions remain open. Battery chemistry, capacity, charging input, charge-while-operating behaviour, and connector current rating are not defined. Display inrush and the delay between enabling its rail and releasing display reset are also unresolved.
Those questions must be answered together. Adding a charger later can change source-path protection, thermal load, battery monitoring, USB or external connectors, and shutdown behaviour. Adding a motor later may introduce current spikes and supply disturbances that are not apparent in a controller-only power tree. Power architecture should therefore be reviewed against the state model, not approved rail by rail.
3. Treat Every Interface as an Engineering Contract
Interface labels such as SPI, I2C, GPIO, and “motor control” describe protocols or intentions, not complete electrical behaviour. An interface contract should state voltage domain, signal direction, driver ownership, reset state, timing or bandwidth, connector mapping, and response to disconnection or fault.
The desktop robot provides several examples:
- The display interface needs more than
SCK,MOSI, and chip select. The contract must define the display logic voltage, whether any line can drive the controller, the state of chip select and reset during boot, the relationship betweenVDISP_5VandSYS_3V3, and the permitted condition when the FPC is disconnected. - The HTU21D sensor uses I2C, so the contract must identify pull-up ownership, bus voltage, address, expected bus speed, power-off leakage assumptions, timeout behaviour, and recovery from a stuck bus.
- The user button needs active polarity, debounce ownership, wake capability, ESD path, long-press timing, and the safe interpretation of an open or damaged switch.
- A future motor interface would need supply range, stall current, control mode, direction and brake behaviour, fault reporting, and the required safe state during reset or firmware loss.
Treat connectors as part of the same contract. Pin order, mating orientation, hot-plug expectations, cable length, shielding, spare pins, and return paths can constrain the schematic as strongly as the IC pinout. When these details are documented early, interface review can occur without guessing what a net name means.
4. Assign Hardware and Firmware Responsibilities Before Pins
Many embedded functions can be implemented in either domain, but leaving ownership ambiguous creates duplicate logic or missing protection. Assign a primary owner and a fallback response for every timing, safety, and recovery function.
In the robot controller, the pushbutton path includes ESD protection and RC filtering, while firmware would still need to interpret presses and apply a debounce interval. The battery-low detector can generate BATTERY_LOW_N, but firmware must decide whether to dim the display, stop motion, save state, or shut down. DISPLAY_PWR_EN may be driven by firmware, yet hardware must guarantee a defined level while the ESP32 is resetting. A motor fault, if motors are added, may require a hardware disable path even when firmware also logs and reports it.
Write responsibilities as testable statements: “Hardware holds the display rail off until the controller output is valid”; “Firmware enters the safe state within the specified time after a battery-low event”; “The motor driver disables outputs independently when overcurrent is detected.” The actual time and threshold must be completed before component selection.
Only then should the team assign MCU pins. Boot straps, reset defaults, interrupt and wake capability, PWM channels, analogue inputs, peripheral routing, and debug access may rule out pins that otherwise appear convenient. Pin assignments should therefore follow the hardware-firmware responsibility model, rather than define it.
5. Carry the Decisions into the Engineering Package
Requirements reduce rework only when they remain visible in the artefacts engineers review. One way to create that intermediate handoff is SpeedUp, which turns a plain-language product brief into a first schematic and an editable KiCad starting point that engineers can open, inspect, and continue developing. The result still needs engineering review and completion; its value is that assumptions can be examined in concrete files rather than left in conversation.
The five robot modules—POWER_INPUT, COMPUTE_WIRELESS, DISPLAY_SUBSYSTEM, ENVIRONMENT_SENSOR, and USER_INTERACTION—give reviewers a clear structure for checking the current controller design. If motion and charging are confirmed requirements, they should become explicit blocks with named power and fault interfaces rather than being buried later inside the power or compute sheets.
Named nets should carry behaviour as well as connectivity. Names such as DISPLAY_PWR_EN, PGOOD_3V3, BATTERY_LOW_N, and UI_EVENT_N reveal polarity and purpose. Sheet notes can then state the relevant reset value, owner, and state transition. The BOM should add context for critical parts: function, governing constraint, approved footprint, substitution limits, sourcing status, and the requirement that drove the choice. Thirty-nine populated line items demonstrate scope, not completeness.
Finally, maintain an unresolved-requirements register beside the schematic. Each item should have an owner, due date, affected modules, and the decision needed. For this project, the first entries would include motor type and stall current; battery chemistry and charging method; simultaneous charging and operation; firmware wake, timeout, and recovery behaviour; enclosure dimensions and connector orientation; sensor airflow; button mechanics; and ESP32 antenna clearance. The pre-capture test is simple: can a reviewer trace every operating state, power transition, interface assumption, and hardware–firmware responsibility into a named schematic block or an explicit open item? If not, the drawing may be tidy, but the requirements are not ready. Resolve the decisions first, and schematic capture becomes implementation rather than discovery.
