The Productologist

The Inmates are Running the Asylum by Alan Cooper

I have been meaning to read this seminal text on application development and usability for some time (read: years), but somehow it always ended up on my reading list just below something else. After seeing some others reference the book and discuss conference talks where the author expanded on his theorems, I decided to bump The Inmates are Running the Asylum to the top of the list. After finishing it up, I was surprised, to say the least.

Cooper spends a good portion of the book providing examples of what’s wrong with software development and user experience in particular, which is initially helpful, but gets a bit tiresome. Maybe it’s just my perspective as a Product Manager, but I know that software design and development is a dynamic process. Even when you improve the product dramatically (new features, ease of use, performance or cost), there are still more ways to make it better. I’ve never heard ANYONE say, “Ok, we’re finished. There’s nothing more we can do to improve this.”

Software is constantly evolving. There may come a time when development of a particular application is stopped for business reasons or the need for the application disappears (anyone remember XTree?), but there are always improvements to be made. Case-in-point, the application that I use to write the drafts for my posts is called Notepad ++. It’s your basic text edior with some nice add-on features, such as macros, word completion, and word count. It has a bunch of other features that are more geared toward folks who use it to code, but it does what I need it to and it then some.

You’d think that a text editor wouldn’t have a lot of room for growth at this point. Text editing programs have been around for such a long time and have been used for so many things that it’s hard to believe that there are many things still to be added to the feature set. But, just today, I was prompted by the application to download a recent update.

After upgrading, I went to take a look at what I was getting with the new build. Included in this release are at least 24 bug fixes (that’s how many were listed in the readme, but being a Product Manager, I know there were probably more that weren’t included in the readme) and six new features, which incidentally were more about the user experience than the actual functionality of the software.

Which brings me back to The Inmates are Running the Asylum. The main lesson that I got out of the book was this–

• The people who code the software are not the people who use the software, so they should not be the one’s who design the software.

It’s easy to create a list of features that a software package should have, but it’s an entirely different thing to make those features accessible and useful to the intended user. Cooper repeatedly claims that software engineers are fantastic at fulfilling the requirements of the first half of that sentence, but usually don’t have a clue on how to do the latter (or even stop to consider that there is a second half of that sentence).

I’ve worked with my fair share of software engineers and that assumption is generally true, though I have worked with some very talented developers who were good at coding and at understanding the needs of users who may not be engineers. The challenge that Cooper identifies is that users and programmers fall into two separate and mutually exclusive groups.

Users want the software to do most of the work for them. The best kind of software is the kind that doesn’t get in the way of doing what the user wants to do. They become frustrated when the limitations of the software are exposed to them. Think of the scene in Office Space where the laser printer displays the PC Load Letter error. To the software engineer who created the application inside the printer, this probably had some connection to what was happening or what the user should do, but to the user it is as cryptic as reading some alien language. The user has no idea what the problem is or what to do about it.

On the other hand, programmers revel in the challenge of getting past the problem, as witnessed by this passage–

If you aren’t utterly on top of your game, computers will leave you whimpering in the dust. It is easy to picture the exhausted programmer chugging Coca-Cola, grinning and saying “Yeah the fetch logic caused the crash, but only when the main heap grew beyond 64K, otherwise the cache wasn’t activated. Almost couldn’t find it!”

This fundamental difference in how users and programmers interact with the software exemplifies Cooper’s point that developers are not the right people to handle interaction design (which he differentiates from interface design). Cooper spends chapters 7 and 8 discussing the differences between programmers and users in detail.While most of the book centers around development, there was a passage that caught my eye, since it specifically called out Product Managers. It is in the chapter entitled, Wasting Money. Cooper calls all of us out on to the carpet with this statement:

“I’ve seen Product Managers sacrifice not only design, but testing, function, features, integration, documentation and reality. Most Product Managers that I have worked with would rather ship a failure on time than risk going late.“

Ouch, although, there is some truth there. Part of Product Management is balancing the must-have with the nice-to-have. In big companies, it may be more acceptable to slip a ship date, but in the start-up world, missing a product release deadline can mean missed revenue and even layoffs or closing the business. I’m not trying to be dramatic, but there are real differences on what types of choices a Product Manager has to make that are based on the size of their company.In Chapter 9, Cooper introduces what is likely the most novel concept in the book–Personas. He provides very concrete examples of what a persona is, what it’s for and why every software project needs them. When The Inmates are Running the Asylum was originally published, personas were not a common tool used in software development, but reading the text today, many more development processes include Personas at some level.

There is some dissension in both the Product Management and Programming communities about the usage and benefit of Personas. Cooper recommends creating full Personas (a name (which Cooper says is essential; without one, it’s useless!), pictures, lots of details about the person that may be unrelated to the software), but for me, that’s a bit of overkill.

When I create a Persona, it just has to describe what is relevant to the usage of my products. By making the Persona so specific, it loses some of the value of being a Persona and just becomes another user. I don’t need the Persona to “come alive” like a character in a movie. What I do need is for the Persona to provide insight into the needs of a type of user that helps me, the engineering team, the QA team and anyone else involved in creating the user experience what the archetypal user needs to be successful.

In chapter 10, Cooper makes the case that software should anticipate the needs of users and be “polite”. He lists a number of characteristics which he identifies makes software polite. Here are a few examples:

• Polite software has common sense
• Polite software is perceptive
• Polite software is deferential
• Polite software gives instant gratification
• Polite software is trustworthy

All admirable qualities for software (and people, too), to be sure, but hard to find in either one.

Cooper finds his way to poke fun at Product Managers again in chapter 12–

It is easy to see why product managers can mistake industrial design for interaction design. Just because the buttons are easy to find and pres doesn’t mean that the user will know which button is the right one to press.

His point is that it is easy to make something pretty to look at, but it’s a whole different thing to make a product easy to understand and use, which sums up much of what Cooper is trying to say throughout the book. It takes heavy lifting to make a product that has both the features and functions that users need AND a user experience that makes those features accessible.

Recommendation: Although the examples and concepts seem a bit dated, and I don’t agree with everything he says, and he takes the occasional potshot at Product Managers, the need to examine the user experience and improve upon it never goes out of style. The Inmates are Running the Asylum is a book that EVERY software Product Manager should read and review on a regular basis if they want to build great products.

Popularity: 70% [?]

This entry was posted on Thursday, April 10th, 2008 at 7:42 pm PT and is filed under Book Review, Design, Engineering, Interface, Personas, Usability.You can follow any responses to this entry through the RSS 2.0 feed.You can leave a response, or trackback from your own site.