Designing for a trigger, not a mouse

Most UI advice assumes a person sitting still, looking at a screen, tapping with a thumb. The apps I design for Identium's field hardware get used by someone else entirely: a warehouse worker, standing, holding a rugged gun-grip PDA, pulling a physical trigger to scan, often without looking at the screen at all.

I keep being surprised by how much that one detail changes.

The trigger is the primary input

On a phone, the primary action is a button you tap. On the CX1500N it's the hardware trigger, and the screen's job is to confirm what the trigger did, fast and legibly, from arm's length. So the scan count is huge. Feedback is haptic first, visual second. The most important number on the screen has to be readable without actually focusing your eyes on it.

Two design languages before a line of code

For CX Flow Pro I did something I don't usually get the time for: I designed the whole product twice, in two complete visual languages, before writing any code.

• An iOS-premium language: soft, glassy, generous spacing, the "nice" version.
• A red, monolithic, industrial language inspired by Nothing's aesthetic: high contrast, monospace, unapologetically a tool.

Doing it twice felt wasteful for about a week. Then it paid off. Seeing the same flow in two skins turned out to be the fastest way to find out which decisions are structural (they survive both skins) and which are just decoration (they change with the skin). The structural stuff is the actual design. The rest is paint, and paint can be argued about later.

What survived both

The scan-first layout. The trigger-confirmation hierarchy. One-handed reachability. All of those showed up in both languages, because they come from the hardware rather than the mood board. When I start a new field app now, I carry those over first and save the arguments for the paint.