The Inmates are Running the Asylum (Buchbesprechung)
The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity was written by Alan Cooper in 1999. The revised, second edition was published in 2004 and is the basis for this article.
The book consists of 5 Parts in 14 Chapters, the paperback volume comprises 288 pages.
Cooper tries to explain how important good interaction design is for software in contrast to the design methods used today. In his remarks, he shows that people rely on the software they use, therefore it has to be well designed. His opinion is expressed in an unusually open way throughout the book.
The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity is a dedicated work that opens the readers' eyes to what is currently wrong with interaction design. The author tries to present ways of solving problems, quoting examples from his own company.
- 1 Computer Rage and its Roots
- 2 Today‘s Standards of Programming Software
- 3 The Future Approach According to Cooper
- 4 Conclusion: Don't Let the Inmates Run the Asylum
- 5 Links
Computer Rage and its Roots
As long as computers have existed, there have been desperate users who often express their feelings by screaming or cursing at their computer. In the worst case so-called computer rage will burst out of the users. These people have been known to destroy their hardware and experience personal satisfaction when they "harm" their computer.
Unhappiness with software is often caused by ill-designed graphical user interfaces (GUIs) which frustrates the user. First of all, it is too hard to figure out how to work with it efficiently, and the program is also asking too many questions or delivering insufficient possibilities to respond to its actions. Also, lots of programs tend to give the user unhelpful error messages that he cannot understand (e.g. messages like "exceptional error 673"). It blames the users for problems or errors, not giving helpful advice, but telling users over and over what they did wrong.
Software often contains unwanted features that are of no use to the user. He has to search too long to find a way to use the program for his needs, which is often also determined by the complexity of the software. Another reason for the frustration with GUIs is the inflexibility of the program that doesn't remember preferences. However often the user enters his preferences, it mostly doesn‘t remember them, so he has to adjust the GUI over and over again, even though he might be doing the same tasks every day.
You can easily say that computer rage mainly came into being because of the poor or even non-existent interaction design of the GUIs.
Today‘s Standards of Programming Software
The standard methods of programming software are unfortunately often not aimed at the user's needs but are urged by companies' managers who are not willing to invest much money or even time in the development process of the software.
Therefore, the design often 'happens' while programming, there is no pre-production phase that would allow interface or interaction designers to specify the users of a program as well as their tasks and goals they want to achieve with the software, which would be a very important step for deciding what the software has to look like and which features it should have.
The software programmers are responsible for designing the core as well as the appearance of the software, even though they are not qualified for it. They design GUIs the way they think it would be used later, but since they have a professional background in software technology, programmers tend to design the GUI with too much complexity. Especially for customers who don't have experience with software it is almost impossible to use it on the spot. The study of instructions is unavoidable, because the programs are not intuitive enough. Often, they are not customised for a special clientele, so they have too many unnecessary functions that confuse the user.
Additionally, the re-use of existing code has become one of the standard methods of programming. Programmers tend to write their software including portions of code they already used for other programs. That may cause different problems like including old bugs. It is obvious that the program was not written for a pre-defined target group. Re-using code may save time for programming and therefore save money of the company, but will and cannot lead to well-programmed software that satisfies the requirements of the clientele.
This can also not be achieved by the managers who define features they want to have included in the software. Some of the companies' leaders think subjectively of their own needs instead of objectively defining goals of the potential users.
The Wrong People are in Charge
Cooper's central theme, the title of the book, is striking: "The Inmates are Running the Asylum". The statement below will make clear what was previously said: the wrong people are in charge of interface design. They cannot do their job well, because they were not trained for it, it is simply not their task. Cooper doesn't want to blame them for the insufficient job they are doing in the design, instead he wants to reproach the companies for their methods of producing unusable software.
|The high-tech industry has inadvertently put programmers and engineers in charge, so their hard-to-use engineering culture dominates. [...] It's the engineers who are running the show. In our rush to accept the many benefits of the silicon chip, we have abdicated our responsibilities. We have let the inmates run the asylum. [...]
When the creators of software-based products examine their handiwork, they overlook how bad it is. Instead, they see its awesome power and flexibility. [...] They ignore how excruciatingly difficult it is to use, how many mind-numbing hours it takes to learn, or how it diminishes and degrades the people who must use it in their everyday lives.
(Alan Cooper. The Inmates are Running the Asylum. Page 15)
Why Programmers Should not Design Software
Unfortunately, when programmers design GUIs, it often will be too advanced for intermediate users. Engineers and programmers seem to have a different way of thinking, since they are 'insiders' to the computer world, they project their way of thinking on the potential buyer of the product. This is definitely the wrong way of programming software that should serve a special clientele for their needs.
Programmers likely accept complexity of their programs, as long as they have full control over all of its features. As opposed to the programmers, the average user does not long to understand the whole inside of the program, as long as it does what he wants without the need to study long introductions or manuals. Software engineers and programmers accept this advance preparation as a necessary step to understand all the possible cases the program might run though, so they can understand every event that will happen during the use of the software. Since they want to understand every detail of their software, they will also accept its failures. When a failure occurs the programmer can go deeper into the guts of the software enhancing their understanding of the code.
Users usually won't care much about the small details, as long as the software is running without mistakes and crashes. They want to intuitively understand the software so that they can work with it immediately.
This behaviour conflicts with the programmers' misbelief that the more features a program has, the better it is. They try to put as many features in the software as they can in their given time, even though most of the potential buyers will only use a small number of those features, and will probably be confused by the others.
Recapitulating, it can be said that programmers design for function, not for humans, and therefore should not be responsible for designing the interface of the software.
Why Managers Should not Design Software
Managers of software companies too often try to influence the process of software development. They are telling programmers which features should be included in the software from their personal point of view.
Since the managers are responsible for delivering the working product on time, they fear that they cannot meet their deadlines. Connected with this fear are even more worries, like the company or the project running out of money or not earning enough from the product if it does not succeed in the marketplace.
Managers could free themselves from this vicious circle by hiring a team of interaction designers who could analyse the potential users and their goals. The developers can be given the program specifications that is based on the users' needs. They then would have an idea of what to do and could try to meet all requirements by the deadline.
Most managers, unfortunately, do exactly the opposite. They often refuse to invest money or time in the pre-production phase of software design, and prefer labelling their products "USER FRIENDLY" without having tested the usability properly. By trying to save money they let programmers re-use their code.
Another big mistake is that they don't give specific goals of the software to the programmers, and therefore leave important decisions concerning the design to the programmers. On top of that, they are setting unrealistic software deadlines to the programmers. They will hurry programming as many features as they can into the software, because lots of managers think that a better product includes more features.
They don't specify a target group for the program, and think it can be sold to more users then: 'It's made for everybody, so everybody wants it.'
After trying to put as many features into the program as possible, the project often runs out of time, which is why the software ships delayed or non-finished. Many managers don't mind that fact, because they would rather ship a product unfinished then too late.
The Future Approach According to Cooper
It seems that users think it is better to have some program then having no program, so they accept bad interaction design as an unavoidable cost.
Cooper is making use of new techniques to develop user-centered design for software.
Internal Program Design vs. Interaction Design
Until today, internal program design was more important than interaction design.
Today, programmers are responsible for both internal and interaction design, and they bear all the risks of a program failure, even though they are not trained for usable interaction or interface design.
Cooper demands in his book that the internal program design must be done by programmers with technical expertise, but the interaction design must be done by professionals in an appropriate time period before development begins.
Programmers vs. Designers
As opposed to a programmer, an interaction designer's task is to think about the user, trying to understand what they want to accomplish from the product.
After determining this knowledge, the interaction designer will translate it into a detailed and precise product specification that will be given to the programmers.
That means that the programmers' responsibility is designing the program.
An important point is that the designer must not be involved with the programming - otherwise there would be an unavoidable conflict of interest between programmers and interaction designers.
There are three major production stages, the pre-production phase, the production phase and the post-production phase, of which the first is practically non-existent in software-developing companies today.
Alan Cooper revolutionised the pre-production phase by making it the most important. In his book, he emphasises the importance of this phase by giving a detailed description on the techniques his company would apply to the software.
The pre-production phase of the software engineering process should, according to Cooper, become more important. For him, it is an unavoidable process that should start before any programming begins. The pre-production phase should ensure that the software conforms to the user's goals.
During this phase, the goals of the potential users and the software must be described precisely by the interaction designers. They interview company members for which the software is being produced, so that their requirements can be taken into account. From the results of these conversations, the goals and needs of the users are analised, making it possible to target the program more effectively.
The interaction designers of the production company develop so-called personas which are used as representatives for the users. Cooper's interaction designers create a cast of characters with a primary persona that the software is written for. There are also negative personas that represent the users the program is not designed for.
Alan Cooper invented a method called Goal-Directed Design®, that assigns goals to the personas.
These personas re-enact software scenarios (daily-use and necessary-use scenarios). With this information, the interaction designers are able to define the requirements of the personas. The companies' programmers now have an exact idea of who they are designing for.
The team storyboard and sketch their solutions and present them to the managers. This enhances their understanding of the ideas and allows the programmers to develop a GUI that satisfies the interaction designers' recommendations.
For these reasons you can say that the interaction designers are responsible for everything that comes in contact with the user – they are the "ultimate owners of product quality".
Since managers, programmers and designers are involved in these meetings, it is important that everybody understands each other. This sounds simple, but imagining managers with their administrative vocabulary, programmers with a language that includes lots of computerised terms, and interaction designers speaking of personas, scenarios etc., it is very important that these different groups use an established common vocabulary to define the projects they are working on.
In the pre-production phase, the programmers will then be hired and the money for the project will be raised by the manager.
The production phase is the time during which the program is developed. Aside from minor concerns, this phase mainly involves the programmers. According to Cooper the managers should not be involved in this phase except for giving support to their employees. They are not involved in the process of writing the program and should not interfere. (Results will of course be presented to them.)
The last phase of the software process is the post-production. This will involve intense debugging, documentation and finally the software is ready for market.
With his methods, Cooper is trying to create what he calls "polite software", that users are willing to work with, as opposed to 'impolite software' that asks lots of questions, and gives too many choices for the users' actions.
Conclusion: Don't Let the Inmates Run the Asylum
Cooper emphasises that a programmer should only be responsible for the 'guts' of the program, while the interaction designers are responsible for the product quality. They respect the users' requests and incorporate the most commonly mentioned into the design specification.
Cooper introduces a drastic change in software design in his book, especially with his new method of Goal-Directed Design® that is catered to the users' needs.
He has presented a successful method for finding a way out of computer rage. Of course his methods must be established first, especially in the business world. Programmers will have to be convinced of the merits of this new technique for software design. Ideally, it will guide them back to their original tasks in the production process. Their new task is to master the challenge of meeting the requirements that the interaction designers demanded for the software.
- Cooper, Alan (1996): Goal-Directed® Desing. Online available: http://www.chi-sa.org.za/articles/goal-directed.htm
- Barnes and Noble (Hrsg., 1999): Interview. Online available: http://search.barnesandnoble.com/booksearch/isbninquiry.asp?ean=9780672316494&pwb=1&displayonly=ITV (Alan Cooper discussing with Online Users)
--MoonSoleil 13:53, 17. Aug 2005 (CEST)