Software for operational work gets designed in the wrong room. It gets designed in an office, on a large monitor, by people sitting down, for people who are standing up.
That gap explains most of what goes wrong. Not taste, not visual polish. The conditions the software was imagined in versus the conditions it has to survive.
The conditions are the brief
A person entering a job on a factory floor is standing, possibly wearing gloves, on a device with a cracked screen protector, with a truck waiting. A field technician is in a vehicle, in sunlight, with one hand, on patchy reception. A warehouse worker is doing the same task for the eightieth time today.
None of those people are browsing. They have one thing to record and a reason to be somewhere else. If the software takes a moment longer than it should, they do not complain, they find a shortcut. The shortcut is usually writing it on paper and entering it later, in a batch, from memory. That is where your data quality goes.
So the brief is not what should this screen show. It is: how does someone standing up, in a hurry, with a glove on, finish this in as few actions as possible.
Design for the eightieth time, not the first
Most software is optimised for the first use. Helpful labels, explanatory text, a guided flow, confirmation on every action.
Operational software is used hundreds of times by the same person. On the eightieth repetition, every one of those helpful things is friction. The confirmation dialog is not a safety net any more, it is a reflex tap that no longer reads the message.
Design for the expert case and make the first-time path available rather than mandatory. Remember what the person entered last time. Default to the most likely answer. Put the thing they always do next where their thumb already is.
Two taps beats a better layout
There is a simple test I use, and it beats every opinion in the room. Count the taps, gestures and screens between starting the task and finishing it, then count the same for whatever they do today, including the paper method.
If your version has more steps, it will lose. Not because people are resistant, because they are busy. A worse-looking interface with fewer steps wins every time, and no amount of training changes that arithmetic.
Big targets, no precision, no typing
The practical rules are boring and they matter more than anything else.
Make touch targets larger than feels necessary, because the finger is moving and the surface is not stable. Avoid anything that needs precision, like small dropdowns or a slider with an exact value. Replace typing with selection wherever you can, since typing standing up is slow and produces errors that then need cleaning. Assume the connection drops mid-task and make sure nothing is lost when it does.
And test at real brightness. An interface with subtle grey-on-grey text is invisible in direct sun, which is exactly where a lot of this work happens.
Go and watch
The single most useful thing is also the least technical. Go to where the work happens and watch someone do it, without asking them to explain.
You will see the paper note in a pocket, the phone propped against something, the step they do out of order because the system's order does not match reality. None of that comes up in a requirements meeting, because it is not a complaint. It is just how the job gets done.
Ten minutes of watching beats a week of specifying. Everything in this post came from that, and none of it came from a mockup review.
