Quick ~review: The Inmates Are Running the Asylum

A post on Isaac's blog was a reminder for me to pick up a book I'd meant to read for a while: Alan Cooper's The Inmates are running the asylum.

If you're interested in building software, I can't recommend the book highly enough. Cooper makes an incredibly compelling case for how and why so many software products are terribly broken. He goes over how the software process prevents us from building awesome products even when smart people are well-intentioned, how attention to interaction design pays off in the long run, why engineers are often exactly the wrong people to make interaction decisions, and how the introduction of a design function in the product development cycle would actually work.

I was characteristically skeptical of a few things before I started on the book, but I quickly lost count of the number of times I shook my head with "oh yeah, I remember when that's happened."

I'm going to avoid a typical review and summarize the points that resonated most with me

• User goals are different from business goals: e.g. A business wants software to do the accounting, but the user using the software probably cares more about not feeling stupid while doing the accounting and wants to avoid mistakes so he can get done and go home early.
• Design as a competitive advantage: if users are passionate about your software they'll stick with it even when the competition catches up. Look at how Apple users supported the company during the Mac/PC wars. Design is the only way to make user passionate (i.e. satisfy "wants" vs. "needs")
• Software needs to be polite: this is the part of the book I enjoyed the most. The way to satisfy the users' personal goals (i.e. not feel stupid, get done quickly, feel productive etc.) is often to build software that is polite. He goes into behavior that is "polite" and how you can build it into a product.
• A great framework to evaluate a product is to use Larry Keeley's Capability-Viability-Desirability model. Capability is what the product can actually do (typically coming from engineering), Viability is getting the business model/pricing/market etc. right (typically coming from the business team) and Desirablity is understanding what people really, really want (not just need - and this is where Design comes in.)
• Feature lists and negotiating over which features stay in or out doesn't make much sense... even though everyone does exactly that.
• "Launch and iterate" is really broken even though not enough people notice this.
• Talking in generics about the "user" hurts. Engineers (in particular) are conditioned to think about edge cases and in product discussions the user expands (e.g. "What if the user does this or wants that") to the point that you can't have a meaningful discussion about product behavior. Use personas instead, and always anchor any product behavior discussions around those personas.
• This is hard to get right, but there are some great case studies in the book of how this can work.

I'm now on the third chapter of Cooper's About Face, and looking forward to finishing it this week.