Sometimes books sit on my shelf for a long time before I get around to reading them. This particular book sat mostly unread for about ten years. With a new software project starting up that desperately needs sensible design, I finally finished reading Alan Cooper’s The Inmates Are Running the Asylum.

The book is more or less divided into two parts. The first part aims to persuade the reader that software products are severely lacking in good user interaction, and that much improved user interaction could theoretically exist; the second part aims to persuade the reader that something can in fact be done about this problem.

It’s like the fellow who leads a huge bear on a chain into the town square and, for a small donation, will make the bear dance. The townspeople gather to see the wondrous sight as the massive, lumbering beast shambles and shuffles from paw to paw. The bear is really a terrible dancer, and the wonder isn’t that the bear dances well but that the bear dances at all.

Cooper argues that software users have endured many technological dancing bears, and that these users end up as either “apologists” or “survivors”. The apologists are delighted that the software functions, and make excuses for its poor user interaction design, claiming that it’s not really all that bad, and you just need to be more computer literate in order to use it. The survivors are less persuaded about the goodness of the software, but they don’t want to appear stupid by complaining about it, so they just quietly put up with it.

The apologists say, “Look what the computer lets me do!” The survivors say, “I guess I’m just too stupid to understand these newfangled machines.” The apologists say, “Look at this! A dancing bear!” The survivors say, “I need something that dances, so I guess a bear is the best I’m gonna get.”

Unfortunately, most of the people involved with creating software lean more toward the apologist side, failing to understand how incomprehensible the software comes across to people who do not enjoy challenging themselves with computer interaction puzzles.

When left to their own devices, programmers build software the way that makes the most sense to them. They frequently do not “design” the user interaction aspect at all, but rather just start coding. That may work well enough for programming tools like compilers and debuggers and text editors, but software that is meant to be used by non-programmers should take into account how those users think, and what those users want to do with the software.

Confusing, poorly-designed software development can be especially problematic when building custom software used internally in a business, for it is being foisted upon employees who lack the option to avoid using it.

Badly designed business software makes people dislike their jobs. Their productivity suffers, errors creep into their work, they try to cheat the software, and they don’t stay in the job very long. Losing employees is very expensive, not just in money but in disruption to the business, and the time lost can never be made up. Most people who are paid to use a tool feel constrained not to complain about that tool, but it doesn’t stop them from feeling frustrated and unhappy about it.

Cooper recommends that deliberate design should be a major part of a software project, and that it should take place before any user-facing software is written. Further, the design would best be done not by programmers, who are expert in intricate, mentally-challenging details, but rather by dedicated designers, who are in position to better advocate for the users. (It is conceivable that programmers could also be good designers, but there is often too much conflict of interest.)

What to Do?

What would good design look like? The second half of the book is overflowing with helpful ideas. Hitting on a few topics:

• Don’t design for specific literal users; instead, based on real users, invent personas — fictional characters that represent your users. These will help keep the design process grounded without trying to account for every possible detail of every possible actual user. Trying to build software that pleases all the people all the time is unwise, as there are so many different potential users. Instead, focus on as few users — or as few personas — as possible, and do everything you can to make sure your software is not only liked by them, but utterly and completely loved.

• Not all tasks that a user needs to accomplish in the software are equal, and they should not be presented as equal. If a typical user spends 95% of their time accessing five features, and 5% of their time accessing twenty other features, then make those first five the most prominent. Also, since your time to design is not infinite, devote more time to designing those five features than to designing the twenty that aren’t used as much.

• Software design should be documented clearly and completely. While programmers should be free to get creative with the software internals, anything that impacts how the user interacts with the software should be plainly spelled out. Which is not to say that the design is unchangeable, but rather, that it shouldn’t be ignored or taken as a mere suggestion.

• Users do not necessarily know what they want, nor do they (any more than random programmers) necessarily have any clue about software design. Accordingly, software should not be developed just as a laundry list of features requested by users. Some requested features might be good to add to a software product, but some might not. If adding a feature would ruin an otherwise good design, then it should be rejected. Listen to users, and endeavor to meet their needs, but do not obey users. They aren’t in control of the software product development.

• Some very large companies (such as Microsoft, especially Microsoft of the 1980s and 1990s) can afford to publish poorly-designed software, accept insults and ridicule from users, and iterate new, improved versions of their software until the users are reasonably happy with it. Most companies cannot afford to do this, but seeing Microsoft do it can suggest that it is the optimal way to develop new software. All companies, big and small, would be better off doing real design rather than just flinging software out the door to see what users think they like, but small companies especially can’t afford not to design. [This might not be as true as it once was, since starting a small software company is so much less expensive than it used to be. Nevertheless, if a good product can be made right away through design rather than iterating through several bad products, it stands to reason that the design phase is still valuable.]

Conclusion

Many ideas that Cooper recommends for better software design I see happening today. Progress is being made; software is better than it was ten years ago. But many of the problems of bad software design still linger on. Perhaps most disconcerting is that the very concepts of software design that Cooper outlines seem to be neither taught in computer science education, nor advocated for in common practice. Clearly some programmers, some companies, must be implementing ideas along these lines, but the status quo appears to still be apologist programmers skipping the design phase on the way to shipping dancing bearware, which may or may not get iterated into something good.

For software developers, I cannot recommend this book highly enough. I only wish that I had read it ten years ago, and maybe again every year since then. If you know a software developer, it’s not too late to get free Amazon shipping before Christmas.

Bonus: Song Lyric Meanings

I think it is now clear that, written in 1960s, Randy Newman’s song Simon Smith and the Amazing Dancing Bear is in fact about a programmer who skipped the design phase, dumping ill-conceived computer software on unsuspecting users: