Design the fault state first: HMI for a device's worst day.

Open any HMI design file and you'll find the happy path polished to a shine: the dashboard with good data, the workflow that completes, the animation that lands. Somewhere in a corner, if at all, live the screens nobody wanted to design — the sensor dropout, the failed update, the value out of range. Yet those screens are where trust is decided. Nobody remembers the interface from the day everything worked.

The demo-state bias

The bias is structural: demos sell projects, so demo states get design attention. But a device in the field spends real time degraded — connectivity flapping, a sensor aging, an operator doing something the flow never imagined. If those states are afterthoughts, the product's worst day is also its most confusing, which is precisely backwards. The worst day is when the operator most needs the interface to be calm, legible and honest.

Normal, degraded, fault — one model

We design the full state model as one artifact: every state the system can be in, what the operator sees, what they can and cannot do, and how they get back. Degraded states are designed to keep useful work possible — a device that goes dark because one input is stale has chosen drama over service. Fault states are designed to answer three questions instantly: what happened, is anything at risk, what do I do now. If a state can't answer those, it isn't designed yet.

Recovery is the feature

The most under-designed flow in hardware is recovery: resume after interruption, safe restart after power loss, re-pairing without a manual. Recovery designed well converts failures into non-events; designed badly, it converts minor faults into support calls and returns. We treat "back to normal in one obvious path" as a requirement with the same standing as any spec line — and test it on hardware, with the real latency and the real gloves, not in a browser mock. That's the core of our HMI practice, and nowhere does it matter more than in robotics, where the operator meets the machine through its worst five minutes.

Design the fault state first. The demo will still be fine. The Tuesday afternoon when everything goes sideways is the day your product earns its next order.