Why The Inmates Are Running the Asylum Book Still Explains Your Worst Tech Nightmares

Why The Inmates Are Running the Asylum Book Still Explains Your Worst Tech Nightmares

Ever tried to set a digital clock and ended up accidentally resetting your entire microwave? Or maybe you've stared at a "user-friendly" software update that somehow made it impossible to find the save button. It's maddening. Honestly, most of us just assume we’re the problem. We think we aren't "tech-savvy" enough. But back in 1999, a guy named Alan Cooper wrote The Inmates Are Running the Asylum book, and he basically told the world that it’s not our fault. It’s the programmers.

Cooper, the man often called the "Father of Visual Basic," didn't hold back. He argued that the very people building our technology—the "inmates"—were the ones making the design decisions for the "asylum" (the software industry). The result? Products that work perfectly for computers but feel like a psychological torture chamber for human beings.

The Cognitive Friction Problem

Cooper’s big idea revolves around something he calls cognitive friction.

Think of it like this. When you open a physical door, you see a handle. You pull it. It opens. The "interface" is the reality. But software is different. Software is invisible. To make it do anything, a programmer has to create a layer of interaction. When that layer is designed by someone who thinks in logic gates and edge cases rather than human goals, the friction becomes unbearable.

You’ve felt this. It’s that resistance you feel when a task that should take two seconds—like changing a font color or checking out of an online store—requires a mental map of a dozen sub-menus.

The book argues that engineers are inherently the wrong people to design these interfaces. Why? Because engineers love complexity. They thrive on it. For a developer, a "cool" feature is one that provides maximum control. For a normal person trying to get home from work, a cool feature is one that stays out of the way. Cooper points out that most software is written to please the "dancing bear." It doesn’t matter if the bear dances well; people are just impressed the bear can dance at all. In the 90s, we were just happy the computer turned on. Today, we’re tired of the bear stepping on our toes.

Why Interaction Design Isn't "Making It Pretty"

One of the most misunderstood parts of The Inmates Are Running the Asylum book is the distinction between interface design and interaction design.

Most companies make the mistake of building the engine first. They let the programmers decide how the data flows and how the buttons work. Then, at the very end of the process, they hire a graphic designer to "skin" it. They want it to look "sexy."

Cooper says this is like designing a house by letting the plumbers and electricians decide where the walls go, and then asking an interior decorator to pick out the wallpaper. By the time the decorator arrives, the toilet is in the middle of the kitchen. No amount of pretty wallpaper can fix a toilet in the kitchen.

Interaction design is the act of defining the behavior of the system before a single line of code is written. It’s about understanding the user's goals. Not their "tasks"—their goals.

  • A task: Entering data into a spreadsheet.
  • A goal: Not feeling like an idiot.

If the software makes you feel stupid, it has failed, no matter how many features it has. Cooper introduced the concept of Personas to solve this. Instead of designing for "the user" (a vague, shapeless entity), he suggested designing for "Margie," a specific, archetypal person with a specific job, a specific stress level, and a specific level of patience. If you design for everyone, you design for no one.

The Revenge of the "Inmates" in the 2020s

You’d think after twenty-five years, we would have solved this. We haven't. If anything, the "inmates" have moved from our desktops to our dashboards and our kitchen appliances.

Take modern cars. Many manufacturers have replaced tactile, physical knobs for volume and climate control with giant touchscreens. To an engineer, this is "elegant." It’s one piece of hardware instead of fifty. It’s easy to update via software. But to a human being driving 70 mph on a rainy night, it’s a death trap. You have to take your eyes off the road to navigate a menu just to defrost the windshield.

This is the exact scenario Cooper warned about. The "inmates" (the engineers and cost-cutters) prioritized the efficiency of the build over the safety and sanity of the user.

We see it in "smart" homes too. Why does a lightbulb need a firmware update? Why does a fridge need a Twitter feed? These are features born from the "because we can" school of engineering. It’s technology for the sake of technology, which is the hallmark of the asylum.

The High Cost of Bad Design

Bad design isn't just annoying. It’s expensive. Cooper goes into detail about "shelfware"—software that companies spend millions on, only for employees to find it so unusable that they go back to using paper and pencils.

👉 See also: Seamless texture wood floor: What most 3D artists and designers get wrong

The business world often treats "usability" as a luxury. A "nice-to-have." But the book argues it’s a massive hidden cost. When your employees spend 30% of their day fighting with a CRM that doesn't make sense, you are losing 30% of your payroll to cognitive friction.

There's also the "apologist" culture. We’ve all met the IT guy who says, "Oh, you just have to hold Shift while clicking that, then wait for the beep, then hit F12." That guy is a "power user," but in Cooper’s eyes, he’s an apologist for bad design. He’s learned to speak the language of the machine, and he expects everyone else to do the same.

How to Actually Apply Cooper’s Logic Today

So, what do we do? Whether you’re a product manager, a business owner, or just someone tired of fighting with your phone, the takeaways from The Inmates Are Running the Asylum book are surprisingly practical.

First, stop starting with technology. When a team starts a project by saying "We’re going to use AI for this," they’ve already lost. They are starting with a solution and hunting for a problem. Instead, start with the person. Who is this for? What are they trying to achieve? What is the one thing that would make their life easier?

Second, give the designers "policing power." In most tech companies, the engineers have the final say because they are the ones who "know how it works." Cooper suggests that the designers should be the ones to sign off on a product. If it doesn't meet the needs of the persona, it doesn't ship. Period.

Third, recognize that "ease of use" is a technical requirement. It’s not a subjective feeling. You can measure it. You can see how long it takes a new person to complete a core task. If it takes more than a few seconds, the code is broken, even if it doesn't crash.

The Enduring Legacy of the Asylum

It’s easy to look at the dated references in the book—he talks about "personal digital assistants" and 90s software—and think it's irrelevant. But the core psychology hasn't changed. Humans still have limited cognitive loads. We still get frustrated when things don't work the way we expect. And engineers still love to build complex things.

The "asylum" has just gotten bigger. It’s in our pockets, on our wrists, and in our clouds. Alan Cooper gave us the vocabulary to fight back. He gave us permission to say, "I’m not the problem; the design is."

If you’re involved in building anything—be it a website, a physical product, or a company process—you owe it to yourself to look at the world through this lens. Stop letting the inmates run the show. Put the humans back in charge.

Practical Steps for Implementation

  1. Audit your current tools: Identify the software your team complains about most. Measure the time "wasted" on workarounds. This is your design debt.
  2. Create one persona: Don't make ten. Make one. Give them a name. When you’re looking at a new feature, ask, "Would [Name] actually care about this, or is this just something our dev team thinks is cool?"
  3. Prioritize "Goal-Directed Design": Shift your focus from "What can this tool do?" to "What does the user want to accomplish?" Often, the best way to help them reach their goal is to remove features, not add them.
  4. Read the original text: While the tech examples are old, the chapters on "The Professional Culture of Programming" are still the most accurate description of why tech feels the way it does.

The inmates are still there. They’re still brilliant, and they’re still trying to give you a 50-button remote control for a 2-button problem. It’s up to you to say no.