Wednesday, December 14, 2005

The Inmates Are Running the Asylum by Alan Cooper

Time for another book recommendation. I've just finished reading The Inmates Are Running the Asylum by Alan Cooper. This is a passionate call the software to be more usable.

Cooper's argument is: software is not designed for usability and as a result much software is difficult to use and unattractive - he calls this "Dancing Bearware" - people use it because they have no choice.

Well designed software on the another hand is a joy to use, is perceived as being more powerful (even when it has fewer features) and creates a customer loyalty. Consequently this is good business not just good software.

(When Coopers speaks of software design he is talking about usability and anaesthetics - the same way we mighttalk of furniture design - not software design as programmers think of it with URL charts and object diagrams.)

Not only does he advocate better software design but he gives a selection of tools to use for design. This is interesting because many of the tools described are equally applicable to the work of Product Managers, e.g. personas, scenarios, etc. So the book is actually very useful to Product Managers even without the design discussion. Having said that, every Product Manager should have an awareness of the need for good product design and should read this book for that reason alone.

Programmers too should read this book. On casual reading you could get the impression that he does not think much of programmers, but in truth he is simply pointing out that they are not the best people to design software interaction.

It is hard to disagree a Cooper - he makes a very strong case. Where I do have an issue is his suggestion that we engage in the long design process upfront. Of course he is advocating we design the usage of the software, which is quite different to the way we normally talk about big upfront design of software. Still I worry that the same problems occur when we engage in long design periods without actually producing anything.

It may also be difficult to reconcile his design period with the incremental delivery models found in Agile and Lean techniques. However I'm sure we can reconcile these points of view as long as we remember to keep things simple and avoid waste.

After reading this book I'm left wondering why every software development project doesn't have its own designer. It makes good business sense: think iPod. Of all the companies I've worked for only one had a software designer - and he was cut in the first round of redundancies.

So if you are Software Developer this book is well worth the read. If you are Product Manager this book is a must read. And if you are Software Development Manager who can't understand what all the fuss is about, or why your programmers can't just develop the user interface as they go along, then buy this book now and read it tomorrow.