While our team was researching how warfighters used a device to call in air support, we heard what sometimes happened when they had to abandon it in a hurry.

They shot it.

The device held sensitive information and included a zeroize function. But the control was difficult enough to find that, under pressure, destroying $5,000 worth of equipment was faster and more dependable. The product met the requirement. The workaround exposed what the requirement had missed: the device needed to be secured in seconds.

What field workarounds reveal about the intended workflow.

Warfighters are trained to respond when equipment fails, conditions change, or the original plan stops matching reality. That ability is part of what makes them effective, but it can also hide problems in the technology. The operator finds a way around the problem, the mission keeps moving, and from a distance, the system can appear to be working.

Every intended workflow rests on assumptions, and the field is where those assumptions get tested.

The cost shows up somewhere else: an extra step, another tool, a memorized shortcut, or a piece of equipment destroyed because the intended process takes too long.

Product teams spend a lot of time defining the intended workflow: what should happen first, what follows, and what information the operator needs at each step. That work is necessary. So are the requirements, reviews, and decisions that keep a complex program moving forward. But every intended workflow rests on assumptions, and the field is where those assumptions get tested.

When the workflow breaks, what gets skipped or substituted? What does the operator do to keep the mission moving? Those moments can reveal that the system was designed around assumptions about timing, attention, or sequence that don’t hold up in the field. 

Know what the workaround is solving.

Not every improvisation should trigger a redesign. The question is whether the workaround is compensating for a real gap in the system.

Is it saving seconds that matter, reducing cognitive load, or replacing a process built around time and attention the operator doesn’t have? Does the same behavior appear across people and situations?

When operators repeatedly find a faster, safer, or more dependable way to complete the task, the program should pay attention. The product might appear to be working only because the operator has worked out a way to achieve their goals despite the product. This can lead to outdated requirements, misguided training, and place undue burden on warfighters.

Fix the assumption, not just the interface.

It'd be easy to look at the zeroize story and think that the control just needed to be easier to find. But if the real need was to secure the device almost instantly while moving out, clearer labeling might have been too small a solution.

The answer might have been a physical control, an automated response, a different sequence, or a different definition of what the device should do when it was about to be abandoned. Those decisions sit deeper in the product. That’s no longer a question of where to put the button. It reaches deeper into how the product is supposed to behave.

Every intended workflow rests on assumptions, and the field is where those assumptions get tested.

The problem appeared in the interface, but it began in the assumptions behind the system. Operator insight has to enter the program early enough to shape requirements, architecture, and workflows, before those assumptions become expensive to change.

That can’t sit with the design team alone. Complex programs need stable requirements and forward momentum, but delivering exactly what was specified is still a failure if the specification misunderstood the mission.

Design has to do more than improve the system it's handed. It has to help the program find out whether it is building the right system in the first place.