Firmware is UX

There's a class of hardware project that deceives you: electronically mature, humanly a prototype. NeuroPulse lived in that state for a year. The second board revision did everything I wanted — controlled current, biphasic, per-phase charge limiting with an analog cut — and not a single therapist could use it without me standing next to them.

The diagnosis was humbling in the right way. The device had an 11-level menu. I had designed the menu for myself: every stimulation parameter (frequency, pulse width, ramp, charge limit) accessible, with a display and button navigation. Technically impeccable. From the point of view of a therapist with a patient on the table, it was a tax form with a current source at the end.

The lesson that stuck: in embedded instrumentation, UX is not the firmware's skin — it's the decision of what the user needs to decide. A therapist doesn't want to tune 11 parameters; they want named protocols ("deltoid strengthening", "subluxation prevention") they trust and, at most, an intensity dial. The expertise lives in the recipe, not the knob. The third NeuroPulse revision shipped with three physical controls (intensity, start/pause, protocol select) and an SD card where protocols live as plain text files.

This reordered the whole project. The firmware lost the menu and gained a protocol file parser — which is far easier to test. Safety improved for free: with three knobs, the device can refuse to run any protocol whose charge limit exceeds the value computed from the electrode area, without anyone needing to know the rule. The rule lives in the file; the device just refuses to violate it.

What I'd write to my self of a year ago: the firmware doesn't serve the board — it serves the hand that presses the button. The ~1,900 lines of C that survived are easier to maintain than the 3,400 that came before, and the interface got better by getting smaller. Any time a device feature requires a manual, the manual is the bug.