The screens were the easy part

Problem

From the outside this is a simple product. A technician installs a piece of hardware, the app confirms it worked. Three screens, maybe four.

Everything hard about it is invisible. The hardware talks to firmware, the firmware talks to software, and any of them can fail. And the technician is standing inside a building with no connectivity at all, which turns out to change the entire shape of the product.

The thing that changed the design

There's no signal on site. So the question was never a layout preference. It was: does the technician configure every device first and connect them all later, or do it one at a time? The honest answer is that it depends on the building, and the building doesn't ask us. So the app had to support both, without making the technician think about which mode they were in.

Getting three teams to agree

Hardware, software, and firmware each understood their own failure modes and quietly assumed the others had theirs covered. Nobody had written down a single list of what can go wrong.

I built a blueprint of every interaction the product needed, which surfaced the blockers nobody had named, and I got the three teams to align on one shared picture. That blueprint became the design. Every error state, how likely it was, whether the technician could recognise it, and whether they could fix it themselves or had to call for help. The interface stayed simple because the hard thinking happened somewhere else.

What shipped

The app was the gate on the hardware launch. It shipped, and the product went to market.