The Inmates are Running the Asylum

I just finished a great book on product design called The Inmates are Running the Asylum by Alan Cooper. Computers have really reached into every aspect of our daily lives. Whether in the bedroom, kitchen, automobile, office, or on the go in our cell phones, a computer is present behind the scenes. The problem, Cooper argues, is how horrible the interactions are with the vast majority of those devices and software programs. Not just the interfaces, but the entire interaction. And it's these horrible interactions that are generating a digital divide across the world between those that put the time in to accommodate and learn the poor design (apologists) and those that just suffer silently (survivors).

I'm certainly not a stranger to some of the concepts around design. I studied human computer interaction while I was at Berkeley, tasking several classes in user-centered design, UI design, and usability and even did a research project on an alternative handwriting recognition option for the Palm platform. Berkeley definitely opened my eyes to the importance of design in building technology solutions. We never talked about "interaction" design, though. Perhaps we just never called it that. But Cooper outlines an alternative to the traditional product design and development process that is meant to regain control of design from where it's held today -- with engineers.

Cooper feels that the current product development process gives engineers too much control of design and these "inmates" are designing for themselves (advanced users that think like computers) rather than the actual people that will be using the end product. Having worked at an enterprise software company, I can definitely attest to having witnessed many of the symptoms Cooper highlights - features that never get used, extensive training sessions required for end-users, difficulty in writing documentation, etc. These symptoms point to a deeper underlying issue - the lack of up-front interaction design. (It's not surprising that we didn't have an interaction designer on staff ... or any HCI person at all for that matter! The engineers indeed owned the product.)

The solution is to give control of the design back to the designers and to utilize an interaction design process before any implementation begins. The main components of Cooper's interaction design process are 1) personas, 2) goals, and 3) scenarios. More on each:

1. Personas - First, come up with a few personas of people that you're designing for. You generally only have a handful of these (around 3 - 5). These are very detailed descriptions of "representative" users. But they're more than representative. They're specific and specific for a reason. They need to have names, backgrounds, and stories because the objective is to make the users real in the mind of the entire team (designers, programmers, testers, etc.). Each primary persona has their own interaction design. That's important because it means that if you have two primary personas, you have two completely different products you're building.
2. Goals - When I was studying user centered design at Berkeley, we talked a lot about task analysis and designing systems to help end-users complete their tasks. What we didn't talk about was goal-directed design. Goals describe the desired end-state. Tasks, while important, shouldn't be the main focus because many of them will likely become obsolete. Each persona has goals that they are trying to achieve, both personal and practical. Personal goals might be "I don't want to feel stupid" while practical goals might be "I want to fulfill the client's order". But a main constraint in design is that you must support the user in achieving both practical and personal goals.
3. Scenarios - Scenarios are detailed descriptions of how personas achieve their goals through interaction with a system. Seems consistent with other definitions of use-cases and scenarios. What's new here is what your focus should be. Instead of trying to support every scenario, you should instead focus on the ones that are most frequent - e.g. daily uses. Edge cases should not get attention! Having developed systems during my consulting days, it's amazing how much time is invested in talking about edge cases ... scenarios that rarely if ever happen. So invest your time wisely - spend your time designing the interaction for the most frequent scenarios.

Cooper also explains why traditional usability testing (which happens after implementation) is wasted effort -- because it happens after you can really affect design! He makes another point about the customer-driven death spiral, a tendency to listen and respond to your customer's feature requests rather than focusing on the personas and goals you're trying to support. The argument is reminiscent of The Innovator's Dilemma.

A lot of what Cooper argues for seem initially like subtle changes on the process, but they're not. I am curious, though, to learn more about how new development approaches like agile blend with the interaction design process that Cooper argues for. With agile, you don't necessarily design everything before you start coding. So how do you reconcile this? I know Cooper's a strong believer that the two are mutually supportive, so I just need to read up on them more. At any rate, great book.