The Inmates Are Running The Asylum

I have stolen my title from a book of the same name by one Alan Cooper. Mr. Cooper is Founder and Chairman of the Board of the Cooper company, which is devoted to leading-edge, customer/user oriented product and software design. From the company website:

For over 30 years Alan Cooper has been a pioneer of the modern computing era. His groundbreaking work in software invention, design and construction has influenced a generation of programmers and business people—and helped a generation of users. Alan is the author of two best-selling books, About Face: The Essentials of User Interface Design and The Inmates Are Running the Asylum, and his visionary ideas and outspoken style make him a popular speaker. Whether you know him as the "Father of Visual Basic," the inventor of personas, or the guy who thinks software should be spanked, we know him as the man whose ideas are the foundation of what we do.

Mr. Cooper has a rather radical outlook on software and indeed other high tech offerings. From his "Inmates" book:

No matter how early in the development process specifications are drafted, they cannot substitute for interaction design. And no matter how hard they try, programmers cannot consistently arrive at a successful design. Not only are their methods, training, and aptitude wrong for the job, but they are caught in a strong conflict of interest between serving the user's needs and making their programming job easier. Yet, in company after company, software engineers are allowed to control the development process, often from start to finish. Sometimes, their control is overt, but more typically it is indirect.

Hence, the inmates (the programmers...no offense!) are running the asylum. This is more or less what yours truly has been saying for a while in reference to PACS. The vendors are allowing their engineers and programmers to create technological magnum opuses which allow too many permutations, and ultimately get in the way of my reading my studies. Why is this tolerated? Cooper compares this to a dancing bear: we are all so impressed with the fact that bear is dancing at all, that we fail to observe just how badly it is choreographed.

So few software-based products have exhibited any real dancing ability that most people are honestly unaware that things could be better-a lot better. Most people using spreadsheets and word processors on modern computers imagine that all the problems that a computer can solve have been solved, and solved adequately if not well...Bill Gates once observed, with uncharacteristic cynicism, that the way you made software user friendly was by making a rubber stamp and stamping each box with the legend "USER FRIENDLY." Unintentionally, his method has become the computer industry's real method.

Mr. Cooper's premier design company will help one create a software product (or hardware, for that matter) that does not suffer from these maladies. The company motto is: "Companies are more successful when their products help users achieve their goals." Accomplishing this gargantuan task takes several steps, including Planning, Research, Modeling, Requirements, Framework, Refinement, and Support. Of these, modeling may be the most characteristic of Cooper's contributions.

Are you frustrated by trying to develop a product that serves thousands--or even millions--of different users? Imagine if instead of trying to please everyone, you could design for three distinct people you knew very well. Wouldn't that make your job easier?

This is the power of personas, a technique for modeling users that we invented here at Cooper. As we interview and observe users in their natural habitats, we look for patterns of behavior and goals shared by multiple people. Each distinct behavior pattern becomes the basis for a persona: a description of an archetypal user.

Personas help everyone from programmers to executives understand users in a way no other tool can: at a gut level. Personas help guide design decisions, end those lengthy arguments about what users need, and get everyone to agree on what product you're building.

You don't need an enormous project to enjoy the benefits of personas. For short projects, personas may just be quick sketches based on limited data. For large initiatives with distributed teams, a well-researched and thoroughly documented set of personas can be an essential reference and communication tool.

In an article about Cooper, Allison J. Head further describes this process:

The gist of Cooper's argument is fairly straightforward: There will be far greater success designing an interface that meets the goals of one specific person, instead of trying to design for the various needs of many. At first blush, though, it may seem downright counterintuitive to design for just one person, whether hypothetical or not. How can designing for a single soul possibly ensure an interface that supports the needs of many users? But as an interface becomes more layered and complex and tries to serve an ever-widening audience base, Cooper's argument holds true.

As long as personas are developed with diligence, the planning and development tool has three key benefits for interface design projects of all kinds. First, personas introduce teams to hypothetical users who have names, personal traits, and habits that in a relatively short time become believable constructs for honing design specifications. Second, personas are stand-ins with archetypal characteristics that represent a much larger group of users. Third, personas give design teams a strong sense of what users' goals are and what an interface needs to fulfill them.

She goes on to describe what may happen if programmers and designers don't user personas:

One of the best arguments for using personas comes from some misguided design efforts at Microsoft. When the software giant geared up to redesign its well-known Microsoft Office Suite for a 1997 release, the research team soon discovered that many of the features users wanted already existed. In fact, four out of five of the features users requested for Office 97 came with Office 95. The outcome of Microsoft's design approach is just what Cooper warns against. In trying to support the diverse tasks of many conceivably different software users, Microsoft cobbled together a product that was bloated with capabilities and ended up satisfying few users.

I think most would agree. I am reminded of some PACS systems I have used....

Anyway, how might this approach be used to create a PACS? Can we assemble a "Joe Radiologist" persona that would cover most radiologists? Well, let's see.... What do radiologists do all day with respect to PACS? We sit in front of the darn things and read studies. That pretty much is all we do, except for the interventional types and the barium-slingers. The real question is how Joe Radiologist wants to interface with his PACS. That is indeed the question. If I were taking this approach, I would talk with all of my partners, and ask them what they like and what they don't like about the PACS systems we already use. In fact, I would post the question here on the blog, and open it up to as many rads as possible. I would then synthesize and distill this wide pool of answers down to a usable persona.

The key to this process is, I believe, to drop all preconceived notions, but not to forget lessons learned. If you are going to build a PACS (or a car, or a toilet-paper holder) you would like to make it usable, and comfortable. There should be adequate features to cover at least 95% of situations that will arise (easy with toilet-paper holders, harder with cars, easier than some think with PACS.) Many products out there are obsessed with how to handle something that Joe Radiologist might have to do once a week, or once a month, and pay little attention to the repetitive grind that makes up 95% of our work. And many vendors are stuck in the rut of doing things the same way, version after version. Therefore, it is critical to see how a wide swath of your potential customers would use your product, and it is very important to understand how they work with your competitors' versions of the same thing. When Saab designs a new car, for example, it is probably wise to determine if the 99% of the world that buys cars other than Saab's would appreciate having the ignition key on the center console, which is where Saab (and no one else) puts it. If you are a PACS company, it is probably not terribly wise to gear your Joe Radiologist persona to those who are mostly users of your PACS, and then proceed to come up with the next generation of a PACS with its ignition key on the center console. I should also add that real radiologists need to be reintroduced to the process; don't go with the stereotyped "Joe" for a prolonged period without a reality-check from the flesh-and-blood version. Trust me, if these caveats to the Cooper approach are discarded, the result will not be what "Joe Radiologist" wants at all.

One of my partners told me in all seriousness that I should create my own PACS system. I wish I had the time and the wherewithall to do so. Of course, out of vanity, my persona would be used instead of "Joe's" which would naturally yield the most wonderful system ever. Absolutely. Guaranteed.