I catch myself thinking the interface is obvious. I am at a standing desk with two monitors, noise-canceling headphones on, music playing. Whoever cannot use it is not paying attention. That is the foolproof software fantasy, and we fall for it more than we care to admit.
It is an easy trap to fall into. We build software in quiet rooms with fast machines and clean data. We know the schema, the business rules, the edge cases, and the long chain of decisions that produced every button on the screen. Then we ship that screen to someone who is wearing gloves, sharing a computer with two coworkers, and trying to process a return while a customer yells across the room. That user is not dumb. They are busy, cold, and under pressure.
Messy UX and messy code travel together, so the experience is ours to own. Owning it means understanding the people we build for. That starts with giving up the idea that users are just slower versions of us.
The Warehouse Floor Is Not Your Office
I learned this on many projects. We were building software for users from warehouse workers to call-center agents to dispatchers. Their environments were nothing like the offices where we wrote the code. Noise, interruptions, and physical movement were the default. A screen that looked clean to us looked fragile to them.
Imagine a worker trying to adjust an inventory lot. The shared computer is in a corner of the warehouse. The worker is wearing gloves because the freezer section is ten feet away. A customer is asking where an order is. The worker clicks a small target, misses, clicks again, and now the wrong field is selected. In that moment, the software is not the center of the worker’s life. The yelling customer is. The cold is. The clock is.
We cannot design for that moment by adding bigger fonts and calling it accessibility. We have to design for the fact that the user’s attention is split. Their eyes will not study the screen. Their fingers will not delicately tap. They will use the tool while thinking about the problem the tool is supposed to solve, and any friction becomes a wall.
The warehouse example is not an edge case. It exposes our assumptions about focus, context, and competence.
Software Is a Tool in a Larger Job
The same truth applies from the warehouse floor to the call center to the coffee shop. A warehouse worker adjusting inventory lots, a call-center agent on a headset with a customer waiting, a freelancer trying to get work done at a coffee shop while the Wi-Fi drops: none of them care about our software the way we do. They care about what our software helps them finish.
Users are rarely focused on the UI. They are watching their surroundings, the next task, the deadline, the person in front of them. Our application is one tool in a larger job, and usually not the most interesting one. That should humble us. As I wrote in Your Brain Can’t Multitask, But It Can Multithread, the user’s attention is already divided before our software ever shows up.
When I remember this, my priorities shift. I stop trying to make the interface clever and start trying to make it disappear. The best compliment a user can give us is “I got it done,” not “this looks beautiful.”
That is the balance. Usefulness comes first. It earns trust. But a tool that is painful to look at or hard to parse will send users looking for an alternative, even when it solves their problem. Someone in immediate pain may tolerate ugliness because the pain is worse. Someone without pain will not tolerate a hostile interface just because it is pretty. A pretty surface with shallow insides wears off fast; useful insides with a hostile surface push people away. Aesthetics gets them to stop. Usefulness keeps them.
Stop Assuming Users Have Your Context
This is where it stings. We assume users know what we know because the knowledge lives in our heads. We know why a button is disabled. We know why a fiscal period cannot be locked. We know that “post” means something different in accounting than it does in social media. To us, the system is transparent. To the user, it is opaque.
The confusion comes from information asymmetry. Users are not missing intelligence. They are missing time and context. No one is sitting in a training session or reading the manual. They are trying to finish a shipment, close a ticket, or explain to a customer why an order is delayed.
So when we say “the user is dumb,” we usually mean “they did not act the way I would act in my office, with my knowledge, and no pressure.” That is a design problem, not a user problem. Since UX is a developer’s job, it is also a code problem.
I wrote more about this in The Cognitive Friction Problem.
Design for Distraction, Not for the Ideal User
The practical question is: what do we do differently?
First, we stop optimizing for the best-case scenario. The best-case user is rested, focused, trained, and patient. That user does not need our help. The user who needs our help is distracted, interrupted, maybe wearing gloves, and rushing from one task to the next. That is the user we should design for.
Second, we make the software answer the questions the user would ask if we were standing next to them: why a button is disabled, what happens if they click it, and whether they can undo it. Those are not design flourishes. They are the same questions our if statements already ask in the code.
Third, we accept that the interface must work in the user’s context. A button that is easy to tap with a gloved finger helps anyone whose hands are cold or dirty. A confirmation message that explains the real impact respects someone who is juggling several real-world problems at once.
A Humbler Frame
We slip into thinking the user should have known better. The thought arrives after a bug report or a support ticket: they clicked the wrong thing. But the wrong thing was usually the thing the UI made easiest to click. The user was not dumb. They were human, in context, and short on time.
The frame changes what we build. A dumb user is someone to blame. A human in context is someone to support. If we make that switch, we stop writing software that tries to be foolproof and start writing generous software: with information, with undo, with clear language, and with the assumption that the person on the other end is doing their best under conditions we did not create.
The developer’s job is to meet the user where they are, with the right information at the right time, so they can get back to the work our software is supposed to serve. That matters more than building the cleverest interface or proving the user wrong.
Leave a Reply