In The Inmates are Running the Asylum, Alan Cooper lays out the business case for investing in interaction design.
Computers are taking over an increasing amount of our lives. Yet they are ruled by dysfunctional, counterintuitive interfaces and interactions.
Similar to Design of Everyday Things, Inmates opens with putting the blame on for the difficulty of using computers not on the user, but on designers and engineers.
“The fault for our burgeoning problems lies not with our machines, but with us. Humans designed the interfaces we hate; humans continue to use dysfunctional machines even as the awkward interfaces strain their eyes, ache their backs, and ruin their wrist tendons.”
This book is not a “how to” design book, Cooper says. It is a business case for interaction design.
Every business is high-tech now. Tech has invaded every corner. Efficiency is key. The technology you use must easy to learn, use, and understand. It must help you reach your goals. When it doesn’t, it wastes money, time, and opportunity. Thus: if you care about your bottom line, you want better, easier-to-learn, easier-to-use high-tech products.
So what’s the business case for interaction design?
A business operates to make a profit. You can make increase profit using two levers: increase revenue, decrease cost, or both.
Traditional mindset looks at programming as a variable expense. Hence they see cutting costs there as a way to increase profit.
This doesn’t work in the digital age, since reducing costs (firing engineers or offshoring) results in worse quality product and runs the company into the ground in the long run.
Instead: improve the product quality to radically increase revenue, which can only be done by increasing spend. This increase in spend will see a greater increase in revenue, as product loyalty and satisfaction goes up.
Good analogy: pharmaceutical companies. Manufacturing a pill is cheap, like distributing software. Developing treatment is absurdly expensive, like paying for good engineers. And shipping a drug that fails or backfires is catastrophic, even if it saves money during development.
User experience design process (user research, scenario definition, interaction design) is often on the chopping block as a cost-saving measure. This is devastating for those who cut costs in order to increase profits. The design process is the key to increasing profits in two ways: (1) investing in a good design process yields huge savings during programming and (2) good design yields a better product, which increases revenue.
“Every dollar or hour spent on architecture [interaction design] will yield tenfold savings during programming. Additionally, when you invest a sufficient amount of competent design, your product becomes very desirable, which means that it will make more money for you.”
The design process should take place before engineering begins. This will save costs as engineers spend time wisely and don’t have to backtrack and rebuild.
“There is a colossal opportunity for companies to break this logjam and organize around customer satisfaction instead of around software, around personas instead of around technology, around profit instead of around programmers.”
Another parallel with Design of Everyday Things: discussion of “human error”. There is no human error – only bad design.
Bad design is all around us. As more and more things get “computerized”, they too will probably be more difficult to use. And everyday objects are becoming increasingly computerized since it is cheaper than relying on older, mechanical methods.
(Cooper defines computerized as devices become more complex and rely on chips rather than mechanical methods to function – for example, a digital alarm clock that requires many presses to set the alarm, as opposed to a mechanical one with a simple switch.)
“Just about every computerized device or service has more features and options than its manual counterpart. Yet, in practice, we often wield the manual devices with more flexibility, subtlety, and awareness than we do the modern versions driven by silicon-chip technology. High-tech companies—in an effort to improve their products—are merely adding complicating and unwanted features to them. Because the broken process cannot solve the problem of bad products, but can only add new functions, that is what vendors do.”
Bad usability has real-world effects. Lost time, productivity, money. Frustration.
Cooper coins the term “software apartheid”: you’re not employable if you’re not computer literate.
“Software apartheid”: Otherwise-normal people are forbidden from entering the job market and participating in society because they cannot use computers effectively… By purposefully designing our software-based products to be more human and forgiving, we can automatically make them more inclusive, more class-and color-blind.”
Since the product development process includes designing things every step of the way, from picking the programming language to adding visual flourish, Cooper splits the definition of ‘design’ in two parts. One is ‘interaction design’, which is the design that directly affects the end user. The other is ‘program design’, which is everything else.
Another important distinction is between ‘interaction design’ and ‘interface design’. Interaction design includes anything that affects the end user – that can include programming language or database type (if it affects app responsiveness), whereas ‘interface design’ relegates design as an “after programming” step meant to merely clean things up.
“The key to solving the problem is interaction design before programming. We need a new class of professional interaction designers who design the way software behaves… To deliver both power and pleasure to users, interaction designers think first conceptually, then in terms of behavior, and last in terms of interface.”
Bad computer design has a high cost: it makes you feel stupid. It’s hard to use a Swiss Army knife wrong – its use is clear from its appearance. But a remote with buttons, an interface that changes… these can confuse, demoralize, frustrate, and waste time and money.
Cognitive friction: the resistance encountered by human intellect when it engages with a complex set of rules that change as the problem changes.
How people react to cognitive friction: they learn the minimum they need to get by, and ignore the rest.
“You can predict which features in any new technology will be used and which won’t. The use of a feature is inversely proportional to the amount of interaction needed to control it.”
Reminds me of 3D Touch on iOS. Incredibly useful once you get used to it. But a total pain in the ass to learn, as its totally hidden and does not always have a function.
Without a product design process, companies bleed money. This happens in two ways:
Product managers rely on deadlines in order to know when to ship products. The problem is that the arrival of the deadline does not mean the product is ready. If a team follows a product design process, then having a clearly defined product is how you know when the product is ready. It is better to ship something of value late than to ship a shit product on time.
Side note: this definitely seems like an outdated book now. A company with no product design process at all wouldn’t last a minute today. I’m sure they exist, but probably isn’t as big of a problem as it was when Cooper wrote this book.
One hidden cost: say you’ve shipped a bad product. If someone’s job depends on it, you’re now costing them time and money as they struggle to learn and use your product.
Another hidden cost: customer service and/or tech support. A product that is frustrating and hard-to-use will require more hand-holding by the company that made it.
Cooper does an excellent job outlining six major areas where software is failing users. It’s neat to see how these have changed over the years since the book was released.
Larry Kelley of Doblin Group introduced a framework of three qualities of a high-tech company.
“Design takes a product that can be built and performs well, and that can be distributed and sold profitably, and makes it a success by making it into something that people really want. This third leg brings stability and converts an interesting technological achievement into a long-term success.”
Needs may be more urgent, but desires have long-terms influence over happiness and behavior.
If a product merely meets your needs, you may use it, but not be happy with it or recommend it to others. But if it meets your desires, its your friend and you evangelize it.
If your product only meets a customers needs but not desires, then those are not loyal customers – they will leave when a competitor arrives.
Fulfilling customer desires is the path to loyalty. Cooper lauds Apple for this.
“Devotion to design and attention to the details of interaction have created for Apple a customer loyalty that borders on—and frequently transgresses into—fanaticism. Macintosh users are the most loyal product owners in the entire world of software-based products. No other product or manufacturer inspires personal loyalty to the degree that Apple does.”
Cooper blames the proliferance of capable yet unusable products is due to the “inadvertent hijacking of the industry by technical experts.”
“Despite all of our marketing rhetoric, the form of our products is really determined by the people least equipped to determine it.”
Cooper dedicates a whole chapter to explaining the differences between programmers and “regular humans” — maybe appropriate or necessary at the time of publishing the book (2004) but reads as unnecessarily hostile now.
“Programmers are somehow different from ordinary people. Their stereotypical behavioral differences have been the subject of jokes for years: the social awkwardness, the pocket protectors, the bookish manner. Those are just the easily noticeable—and easily ridiculed—surface differences. The really substantive differences are not only far subtler, but they have a more profound effect on the cognitive friction–rich interactive products that programmers build.”
His main point is that programmers want control and accept complexity as a trade-off, whereas everyone else want simplicity, and accept less control as a trade-off.
Some of his individual points are true – for example, engineers liking to reuse code and save time – but then he chalks that up to a culture of inadequacy and other wild generalizations.
Major takeaway from this part of the book:
“The single most important process change we can make is to design our interactive products completely before any programming begins. The second most important change is to turn the responsibility for design over to trained interaction designers.”
The book so far has outlined the causes and impacts of the problem. Now onto what a design process is and how it can be introduced to your product process.
Start by talking to your users. A user is an expert in their problem.
Don’t make the mistake of considering the user an expert in the solution, though. Instead, talk to many users and create personas, detailed representations of real people.
A persona captures the goals, struggles, background, and other characters of a type of user. Then design your product (or feature) around that persona.
A persona gives discussion a breath of realism. A good persona is specific, representative of a group, and feels real – it inspires empathy.
“If you want to create a product that satisfies a broad audience of users, logic will tell you to make it as broad in its functionality as possible to accommodate the most people. Logic is wrong. You will have far greater success by designing for a single person.”
Using the phrase “the user” or “designed for the user” is not sufficiently specific. Instead, refer to a specific persona. Similar to how an engineer would never say “this would run well on a computer” – they would specify what computer, operating system, etc.
Loved this anecdote:
“Robert Lutz, the chairman of Chrysler, says that 80% of people in focus groups hated the new Dodge Ram pickup. He went ahead with production and made it into a best-seller because the other 20% loved it. Having people love your product, even if it is only a minority, is how you succeed.”
Give names to your personas. Refer to them by name. This makes them concrete and real. Easy to reference and remember. The more real they feel the easier it is to empathize with their goals and needs.
Personas must be precise and representative of the group. Edge cases are not important – personas should capture the people close to the center. Averages don’t matter. The average number of kids in your community may be 2.3. But nobody has 2.3 kids – perhaps they have 2, perhaps they have 3. Ditch the average and craft a persona that is sufficiently representative of the group.
It’s useful to develop anywhere from 3 to 12 unique personas for a given project. Not all of them will be designed for – indeed, some personas are only defined to make it clear you are not defining for them. That is called a negative persona.
Every cast of persona has at least one primary persona, who is the main focus of the design. Each primary persona requires a separate and unique interface.
Goals and personas are two sides of a coin: each give meaning and definition to the other.
“”Good interaction design” has meaning only in the context of a person actually using it for some purpose. You cannot have purposes without people. The two are inseparable. That is why the two key elements of our design process are goals and personas—purposes and people.”
Goals are why we perform tasks – and why we use products.
Important distinction is between practical and personal goals. Practical goals: complete a task or goal. Personal goal: feel good, in control, etc. A product can fulfill practical goals while failing at personal goals.
A goal is comprised of tasks. Tasks change as technology changes, but goals stay stable. For example: my goal might be to get to work. The task may be to walk, ride a bike, hop on the subway, take an Uber – or in the future, hop in an autonomous drone. The task changes as technology changes. But my goal is the same.
The wrong way to design is by identifying tasks. Instead, start by identifying goals.
People prefer polite computers and products. What does that mean? Communicating clearly with the user, not blaming the user for mistakes, making it easy to undo, and sharing necessary information (not being stingy) are a few examples.
Cooper provides a laundry list of how software can be polite:
“A scenario is a concise description of a persona using a software-based product to achieve a goal.“
Only develop scenarios that further the design effort.
This means a primary focus on daily-use scenarios: actions that the user will perform with the greatest frequency. Second focus is on necessary-use scenarios: all actions that the software must be able to perform, though not necessarily frequently. And you can largely ignore edge case scenarios: these can be rough and pushed to the background of the interface.
Cooper introduces a few other useful tools for your design process. Three that stood out to me:
Inflect the interface: simplify the interface by placing daily-use scenario controls prominently and moving all others to secondary locations.
“The designer knows that each element of the user interface is a burden on the user. Each button and icon is one more thing that the user must know about, and must work around, to get to what she really wants. Doing more with less is always better. If the designer is doing well, she is removing interface from a product.”
Perpetual intermediaries: a mental model for a user’s skill level. Most users are not beginners or experts. They are perpetual intermediaries. They are the far majority of your users, so keep them at top of mind. There are not many beginners because they either become intermediaries, or they drop out and start using software where they have intermediate proficiency. And experts are few because experts are few. So focus on creating a good experience for the perpetual intermediary.
“Pretend it’s magic”. A useful design exercise where you assume there are on constraints on what the computer can do. What would your product look like then? This exercise highlights the goals (separates them from tasks), making it easier to know what to focus on.
Tech’s entrance into the mass market has radically changed the user population. What used to be tech-savvy programmers is now a sea of nontechnical consumers.
Cooper issues a few warnings here, first against style guides, then focus groups, and finally against a blindly iterative design process.
Cooper is skeptical of style guides, which he says stifling interface innovation and is useless to the interaction design process.
Cooper warns that focus groups can be misleading. Users aren’t good at being introspective about software. They are nervous to ask for big, exciting things. They aren’t conducive with significantly innovative products.
Design over several iterations is also dangerous. It’s true that designs can be improved by iterating. But shipping something half-baked and expecting iteration to save it will merely waste a company’s money, user’s time, and won’t result in a phenomenal product. Iteration is like sandpaper – you can sand a table to make it smoother, but you can’t sand it and turn it into a chair.
Cooper presents a great analogy between making movies and making software. Programming software is like shooting a movie – it is the most expensive part of the process. Investing in detailed pre-production planning saves massive sums of money and time later on.
Interaction design is like pre-production planning; it saves programmer time and money later. Designers need to write, sketch, storyboard, and animate their solutions with enough fidelity that they can function as blueprints for programmers.
Oftentimes designs that work well for the end user will create more complication for programmers. Cooper recommends that when communicating this to programmers, to frame it positively: (1) you are doing it for the end user to have a better experience, and (2) it’ll be a fun technical challenge for the programming team.
Documenting designs helps the entire company. It helps programming by clarifying what’s the product is, what it’ll look like when it’s complete, and why it is designed the way it is. It helps marketing by giving them a voice in the product, via their relaying of customer feedback. It helps tech support as it reduces the customer need for help with products. And finally, it helps managers by clearly defining product scope and creating order in the product development process.
Who owns product quality? When everyone is responsible for it, then nobody is responsible for it. Here Cooper makes what he says is the central suggestion of the book: interaction designers are solely responsible for product quality. They own the product and represent the user. They have a lot of authority – and thus the responsibility for product quality is theirs too.
Once a company sees the value in interaction design, they must embed it into the beginning of the product development process. It cannot be tacked on as an afterthought.
Company leadership needs to make clear that designers are now responsible for product quality. They must emphasize that design documents are blueprints for programmers, meant to be followed exactly—they are not merely advice. Programmers can improvise below the skin of the program, but everything related to user interaction is defined by designers.
“The engineering community says merely that users will have to become “computer literate.” I believe history will view that phrase in the same way we treat Marie Antoinette’s famously condescending “Let them eat cake.” The French Revolution gave food to the masses, and the coming design revolution will give technology to the masses.”