Alan Cooper’s The Inmates are Running the Asylum

Alan Cooper brings together his breadth of experience with interaction design, as demonstrated through his works with Visual Basic, and consulting with many prominent clients in order to explain the need for, and the role of interaction designers. Having recently finished the book, and found it very educational, I’ll draw out, and discuss some of the book’s main points.

Primarily Cooper is definite about the job title being ‘interaction designer’, rather than ‘interface designer’. The connotations are important here – an interface designer would be someone who just designs the part of the customer-facing part of the code. Cooper notes that this is just applying plasters to a broken system – instead we need to start considering interaction from a holistic viewpoint, and build systems that take user experience into consideration from the start.

To achieve this, we can no longer put design in the hands of programmers – as is currently often done, due to historical legacy. Although they know the code inside out, there are many reasons why they should not design it:

• Programmers typically think about implementing a list of ‘features’, and this is not an appropriate manner to design software if we want to end up with a positive user experience
• Programmers have a vested interest in either reusing existing code, or implementing code that they know how to do.
• The programmers ability to design will be blinkered by their past experience of programming and using computers, and this makes it hard to see novel ways of achieving things
• Programmers will often assume that users are as adept with computers as they are, or diagnose user issues as lack of training. Instead it should be the system’s job to accommodate users.

 
Instead we should implement a goal based design process, based on personas. Personas (personae?) involve distilling a large amount of user research (interviews, etc) into a small number of generic ‘people’. These people will be given names, back stories, maybe little pictures, and will sum up the experience of their demographic using the software. For example, if you were designing software for an image manipulation program, you might (after an extensive amount of research) define two key personas, “John” the web designer, who uses the program to create a large number of graphics and logos for his sites, and “Jill”, the casual home user, who uses the program’s wizard to improve the quality of her digital pictures. Creating personas will allow you to identify the goals of each user, the pitfalls they may encounter, and allow you to focus on necessary features/aspects of the program. By being able to realistically identify with the end users, it is possible to design software for them, rather than a generic ‘user’ who is a mis-mash of various ideas and people and would lead to software that is too generic and unfocused.

Another key point drawn out from Cooper’s book is the importance of goal based design. Typically software design is done by making a list of features. For example you may approach the programmers and say “it must be blue”, “it must allow the user to resize photos”, “it must allow the user to reduce red eye effect on photos”. These features would then be added, and ticked off. Features that didn’t make the cut, for whatever reason, would not be implemented. Goal based design is an important development of this. Instead of adding a list of feature, you must use your persona’s, and think about the tasks they might want to do. There is a distinction between the ‘task’ they must do to achieve it, and the ‘goal’. For example, with resizing photos, the task would typically be ‘click on ‘resize photo’ and insert a new height and width’. This is not the user’s goal. The user’s goal is to have a resized photo. Focusing on this as a goal, rather than a task or a feature allows us to think about the optimum way to achieve this. What would the user want to do to resize their photo? By approaching it from a goal perspective, we can see how the user may want to adjust the image by dragging a corner of it, that they’d typically want it to stay in proportion, that they’d like to preview the change before it occurs… lots of things that may optimize their user experience.

The part of the book that I felt is particularly useful in explaining interaction design is Cooper’s metaphor with shooting a film. In a typical software design scenario user experience testing would only be thought of in the ‘edit’ stage, after the shooting (programming) had been done. This is obviously not how it is done in films, for the shooting is the most expensive part of the process. To minimize this expense, and to ensure fewer changes need to be made, films have scripts and storyboards to guide the shoot. This is what our job, as interaction designers, should be within the field of software design.

Implementing a complete design approach, thinking about the user experience from the beginning makes sense at every level. Despite concerns about the loss of time (and the expense of having programmers idling) the outcome will be a better designed product that will receive a warmer reception from users. It will give managers and marketers a larger degree of control over the final product, and give programmer’s a map to progress with, allowing everyone involved to know when the product is complete. The time loss (and potential loss of being ‘first to market’) is more than made up with by quality, as can be seen by the difference between Apple’s Newton and the PalmPilot. Ultimately it can mean the difference between a successful product, and an expensive failure.