Whoever finally mastered the confusing software becomes its fiercest defender.
Nobody sets out to build software that makes people feel stupid, yet a great deal of it does. The usual explanation is that users need more training. Alan Cooper’s answer in The Inmates Are Running the Asylum is organizational: most bad software is shaped by the preferences of the people building it rather than the needs of the people using it. When implementation becomes the de facto product strategy, the inmates are running the asylum.
Two kinds of difficulty
A violin is difficult, but its difficulty is in the music; the instrument itself stays coherent. A badly designed microwave is difficult in a different way. It makes you manage modes, remember button sequences and think like the machine just to warm a cup of coffee. The first kind of difficulty builds skill. The second kind, which Cooper calls cognitive friction, only makes the user feel stupid.
Friction would get fixed if anyone complained about it, but it splits users into two camps that both stay quiet. Survivors, humiliated by the machine, blame themselves, because feeling stupid is socially costly. Apologists, proud of having mastered it, turn endurance into a status marker, so criticism of the product sounds like an attack on their competence. So the people most fluent in a system end up judging it, and their fluency hides the tax it imposes on everyone else: the Expert Beginner problem in product form.
Goals outlast tasks
Cooper’s alternative is goal-directed design. Instead of designing for an elastic abstraction called “the user,” design for specific people trying to achieve specific things. The person at the microwave has a task, setting power level and time, but the task is temporary and will change with the next model. The goal is stable: hot coffee, without feeling trapped or blamed by the machine. Design around the goal and you can change the mechanics without breaking the experience. Personas exist to make that goal specific, because a product aimed at everyone usually satisfies no one.
The same vagueness explains why so many products are a pile of features. Teams mistake a feature list for a product description, so the release date becomes the only real standard of “finished,” and whatever exists by the date ships. Design then gets offered after engineering is done, which is like offering architecture after the concrete has set. That is why “painting the corpse” fails: better visuals and usability sanding cannot rescue an interaction model that is hostile to how people think.
Who gets to decide
Neither training nor polish fixes this, because software becomes dehumanizing when the implementers are allowed to define the product from the inside out. The fix is to start from a precise model of the user’s goals, give design real authority before code is written, and treat cognitive friction as a product failure rather than a user failure.
This is not an argument against engineers. The people closest to implementation accumulate veto power by default, because someone has to decide and they are the ones in the room, until what can be built comfortably becomes indistinguishable from what should be built. Engineering needs a coherent intent to serve, or it will improvise one.
Which raises a question worth putting to any product you use daily: who decided it should work this way, and were they ever the person standing at the microwave?
References:
- Alan Cooper, The Inmates Are Running the Asylum