The first time I watched a firefighter use my software, he was standing in the engine bay with structural gloves still on, stabbing at a tablet mounted by the door. He missed the button twice. The third time he hit it, the screen had already moved on to a different state. He looked at the tablet, looked at me, and said the most useful thing anyone has ever said about my work: "Make it so I can't miss."
I'd spent two weeks on that screen. It had a lovely little transition. It had hover states nobody would ever hover. It was designed, in other words, for me — a person sitting comfortably at a desk with a mouse and unlimited time. It was not designed for a person wearing gloves in a hurry between calls.
The ninety-second interface
Public safety software has a brutal honesty to it. Nobody uses it because they want to. They use it between calls, at shift change, at 3 a.m. when the readiness report is due. Every extra tap is a small tax on someone who is already paying attention taxes you and I never will. So the rules I build by now are simple:
- Targets you can hit with gloves on — nothing important smaller than a thumb.
- State you can read across the room. A truck is in service or it isn't; the screen should say so from ten feet.
- No dead ends. Every error tells you what to do next, because "something went wrong" at 3 a.m. is a small act of cruelty.
Make it so I can't miss.
The funny thing is that these constraints didn't make the product worse looking. They made it calmer. When you strip an interface down to what a tired person can use, what's left tends to be honest: big type, clear states, and real words.
Code that fails loudly
The same philosophy runs below the surface. When a readiness check fails at shift change, the system doesn't retry silently and hope — it says exactly which unit and which check, in the language a chief would use on the radio:
// Not "an error occurred" — say it like dispatch would
if (!unit.passedCheck("SCBA")) {
alert(`${unit.callsign} — SCBA check incomplete. ` +
`Flagged out of service until cleared by ${unit.officer}.`)
}
That's the whole trick, really. Software for serious people doesn't need to be solemn, but it does need to be legible under stress — and stress is the one condition we never test in.
Aevix Operations is in the field now, and every release still gets measured against that engine-bay tablet. If a feature can't survive gloves, a glare, and ninety seconds, it doesn't ship. I have a growing suspicion that this is true of all software, and the rest of us just haven't met our firefighter yet.
