The Inmates Are Running the Asylum, Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper is a seminal book on user-centered software design. The central theme of this book is how the IT industry resembles an asylum taken over by inmates – with software products completely missing the goals of their customers due to a combination of programmer psychology and sales-driven feature explosion. Alan Cooper argues that programmers drive the development process using their own image as a guideline, and overloading the software with features which require expert knowledge. On the other hand, sales and marketing push for features that can be used by beginners in order to expand the customer base. Most of the software users are, according to Cooper, ‘perpetual intermediaries’, so their needs are not addressed at all. Cooper advocates fighting back against this unnecessary complexity and refusing to give in to the mass craziness. His proposed solution is interaction design, a relatively new design practice focused on improving the way users access software.
I found the first part of this book especially interesting, as Cooper prepares the arguments for interaction design by taking a look at programmer psychology, and trying to explain the root causes of miscommunication between programmers and clients (and managers in between). Illustrated with anecdotes on the edge of irony and humour, Cooper describes several “programmer’s personal traits like considering failures a success if they learned anything in the process, sacrificing everything for knowledge, insisting on hard reality and over-emphasising edge cases. Based on that, he then argues that programmers are consistently running the development show, regardless of the organisation structure or methodology, as they can, in Cooper’s eyes, always push features dull, unimportant or uninteresting features to the bottom of the list just by estimating the development time too high. Cooper also attacks programmers for developing the software with the primary aim to maintain it easily, not to meet the goals of customers, and for requiring users to gain internal knowledge of the systems they build.
In the first part, Cooper also attacks overloading products with features, and the world’s acceptance of ugly interfaces and buggy software just because it enables solving complex problems. He compares those imperfect products to a dancing bear – it looks really ugly when a bear dances, but it’s fascinating enough so that people don’t mind that it’s not really a dance.
Cooper proposes design as a key factor to product success and customer loyalty, especially interaction design. Without going into too much detail, he attributes the fall of Novel and Borland to the lack of interaction design in their products, and argues that good design is responsible for customer loyalty which kept Apple from completely vanishing, and helped them resurrect a few years ago.
His approach is completely opposite to the current trends in the software industry, as he argues for much more up-front design and against being directly customer driven. Cooper calls doing layout design after development ‘painting the corpse’, and proposes a phase of interaction design before software design. His goal-driven design technique starts by identifying core user groups and representing them by a single, imaginary person, then focusing on those person’s goals. The idea of interaction design is making that one customer ecstatic about the product, and the book contains several detailed case studies which show how to do that, but still not push away other customer groups. Once those target customers and their goals are identified, Cooper argues that having ‘named persons’ to represent users significantly improves communication, and makes it easy to remove the features which are not needed and would just introduce unnecessary complexity.
Last thirty or so pages, where the author tries to sell his process, were not very convincing to me. Out of respect for his experience in the industry I will not say that he is plainly wrong, but in my humble opinion he misses to consider some very important realities of software development. For example, Cooper compares software development with film making, arguing that the two are essentially the same in terms of having a pre-production, production and post-production phases, and that changes such as deciding to blow up a train instead of an air plane cannot be made easily in production, but can be quite easily made in pre-production. Software business and films may seem close on a silver screen, or to a consultant that just jumps from one project to another, but software is developed, maintained and supported for years after the release, which cannot map to anything in the movie world. I imagine that studio executives would just laugh at an offer to sell a popular blockbuster movie to a large retailer only if Julia Roberts was replaced by Pamela Anderson, but 15cm taller, and if the story takes place in a futuristic instead of a medieval environment. But I see changes like that in enterprise software every day – and being able to accommodate such silly requests is one of the key market advantages of good enterprise software. Again, I might just be one of the followers of the ‘dancing bear’, and trying to find an excuse for the imperfections rather than solving them – but I’ll leave that to you to decide.
I still recommend this book very much to any open-minded developer (and especially development managers). It is full of good case studies and, although I do not agree with a lot of ideas described in the book, it was very refreshing to read. Not very often did I come across such a detailed analysis of the software world from outside, by someone who has been an insider and with a viewpoint that will certainly make you think about ways to improve. I do not believe that interaction design is a silver bullet that can solve all the issues in software development, but I believe that Cooper identified real problems which should be addressed. I agree very much with him that we should put more effort into removing the complexity, and attacking unfounded common beliefs. And even if you don’t agree with the arguments which conflict with modern software development trends, there are a lot of ideas from this book that can be applied to improve software development and communication. For example, although Cooper’s approach completely at odds with Agile methodologies, his persona-focus is very similar to what Mike Cohn proposes in User Stories Applied, one of the agile bibles. Similar, focusing on customer’s goals is an excellent guideline for software development (I wrote earlier about my experiences with goal-driven development in The Magic of Goals: Focused Projects and Better Requirements and How to develop software like commanding a tank).
