|
Ellen Isaacs | |
|
The Inmates are Running the Asylum makes the business case for interaction designers playing a central role in the development of technology products. It starts by providing examples of technology that is difficult, frustrating, humiliating, and even dangerous to use. Cooper argues that, although people have gotten used to being humiliated by technology, it doesn't have to be this way. His claim is that most technology, especially software, is designed by engineers who tend to think differently than non-technical people: they enjoy being challenged by difficult problems and they are trained to think in terms of "edge cases" rather than on the common case. Thus when engineers design software, they tend to create products with far too many neat features that clutter the interface and make it difficult to do the simpler tasks. In the second part of the book, Cooper describes an approach that he and his design firm uses to simplify products and keep them focused on the users' needs, eliminating or hiding more complex features that few people use. He gives some specific and compelling examples of how they took a different approach to an interesting design problem and were able to keep the product simple while still being powerful. He makes the case that you can grab a market with powerful, feature-rich, complex software that is frustrating to use, but you don't build customer loyalty that way; as soon as a well-designed version of that product comes along, your customers will defect. If you delight the user with your products, on the other hand, you will engender deep loyalty that will help see you through some poor business decisions. His primary example of this is the fanatical loyalty that Apple garners from its users, compared with the rage that Windows users feel toward Microsoft. Apple has weathered some horrendous business decisions and still survives, whereas Microsoft users are more than happy to defect when a better product comes along, and in fact revel in the defection. As an interaction designer myself, I had strong mixed feelings about this book. On one hand, I believe that most products are too hard to use and I agree that it is usually because products are not designed from the user's point of view. I also found his design techniques interesting and thought-provoking, especially the notion of creating one or two detailed personas for whom the product is designed, to keep the team focused on the features that are really needed. And I was impressed by his examples of simplified interfaces, especially some basic scanner software that has some wonderful ideas about how to make it easier to save and crop images. (As a frequent Photoshop user, I'd love to see Adobe adopt their approach.) He also made me think about how difficult the hierarchical file system is for many users, and there were times I wanted to cheer out loud in agreement about how hideously bad Microsoft's software is. (If I've just saved the last three files in a particular directory, and then I save another one, is there some reason I have to navigate back to that directory YET AGAIN?) I also am comforted by his case that good design wins in the long run, even if I'm not completely convinced it can overcome the many other factors that play into a company's success, even long term. On the other hand, I was strongly put off by Cooper's attitude throughout the book, which is condescending to anyone who is not an interaction designer, especially to engineers. I can't argue with his characterization of the way engineers think, but their approach is well suited to their jobs. He seems to blame engineers for being the ones to design the software, rather than blaming the businesses who set up their process so that engineers are designing the user's experience. Part of me wants to give this book to every engineer, marketing person, and manager I've worked with, but his attitude is so arrogant and accusatory that I think it would put off just those people he wants to convince, especially the engineers. I've worked with a lot of engineers, and most of them have been very receptive to the idea of handing over the design of the user experience to me, once they understand that they still control the design of the architecture. In fact, we usually work together to give each other constraints that help both of us design a workable solution. Cooper sometimes says this, but usually as lip service on his way to insulting the engineers for the way they think. It's ironic that he's very critical of engineers for being so arrogant, and yet it's just this characteristic that so alienated me from the book. In one chapter explaining the difference bewteen interaction designers and other types of roles that affect the design, he actually says, "There is one final pretender to the throne of interaction design." I also don't think he makes it clear enough that he's not proposing doing fewer features to make products simpler and easier to use, he's talking about doing different features. For example, he argues that software should not be so lazy; it should stop making the user do work that the computer is better suited to doing (e.g. remembering where they put files), and it should stop making users go through the same steps over and over again, as if it were the first time they had ever met this user. He argues that Do you really mean it popups are evil (and I couldn't agree more - as most of my coworkers know), and instead it should be easy to undo anything, so it's not so catastrophic to do something you didn't meant to do. I agree with all that, but of course building a reasonable "undo" mechanism is a very complex feature. To cure the How could you possibly want to quit my ever-so-important application? popup syndrome, it would be much better to make the software very fast to start up, and to have it come back in exactly the state you left it in, so that quitting when you didn't mean to is not a problem. All of this is well worth doing, but it is lots of engineering work; it's another feature. I'm all for shifting engineer resources to these features instead of the but somebody might want to do this obscure thing features, but it should be clear that this is not doing fewer features, it's doing different ones, ones that help smooth the user's interaction with the software. Cooper seems to imply that engineers are so lazy that they don't want to do these features, but most engineers work very hard and care about their product. The key is to make it clear why doing this feature right will make such a big difference to the product. My experience has been that the more you understand the work involved in doing a feature, the better you can work with engineers. Not only can you better trade off engineering effort for user benefit, but engineers respect you for understanding what you're asking. Having said all that, I can't deny that I finished this book with some very specific ideas about improving my own designs, and a renewed sense of the importance of what I do. I just wish Cooper could have articulated the case without putting interaction designers "on a throne."
|
|||||||||||||||||||||||||||
