37signals (Matthew Linderman with Jason Fried), Defensive Design for the Web: How to Improve Error Messages, Help, Forms, and Other Crisis Points, New Riders, 2004.
If you work on web applications of any type, this book is a must read to improve your contingency design skills.
I’ve spent more than my fair share of time creating web forms. Getting the forms functional is usually fairly easy; doing them right, well, that’s a different story. Successful form interaction hinges on the details. Get the details right, and your audience will love it (or, it will be so easy they don’t even notice!). Get it wrong and you can easily frustrate and lose your audience.
Defensive Design is a book about the details. The 37signals team (the same folks behind Basecamp, a great example of a web application done right) focuses on “crisis points”—the times when something doesn’t go right. They not only explain how to design so people can successfully recover from errors and other glitches, but they focus on how to avoid putting your visitors in those positions.
The book is broken up into a number of topics:
Linderman and Fried offer forty guidelines within these topics. Each guideline is illustrated with a number of short examples or case studies. Guideline number 3, “Always identify errors the same way,” has two examples. Two screenshots from E*Trade show inconsistency in error messages, while Priceline’s site is held up as an example of how to follow the guideline. The text is punctuated with customer quotes and interesting analogies (“It’s as if the stop signs in one state are red octagons but in the next state they’re blue rectangles.”)
For the most part, the guidelines are right on. They’d be quite useful as a set of heuristics to analyze a website. Apparently Linderman and Fried agree, as they’ve included just such a tool in the form of a “Contingency Design Test” at the end of the book. But, as with all “guidelines” offered up by experts, the final judge should be you. Don’t use the guidelines as a substitute for critical thinking and user testing. Your audience, goals, or resources may dictate a direction that differs from that laid out in this book.
Having said that, I found only few guidelines to quibble with. And in these cases, I wouldn’t say the guidelines were wrong, only that there might be another approach to that issue, or a valid reason to reject the guideline.
This is not a technical book. The focus is on design, not coding. This helps extend the useful life of the book, as code-heavy books can often stale quickly. And, it makes the book more accessible to non-technical members of a web team. This approach can also be a liability. Some tips, especially surrounding search query modification, are predicated on a fair amount of programming work. The book almost completely ignores the implementation issues. This approach is fine for those who understand the behind-the-scenes details, but it could leave other readers with a false impression.
Technology books are often corpulent tomes, contributing to widespread deforestation. This is not one of those books. It weighs in at a svelte 246 pages, including index. The writing style contributes to the featherweight feel of the book. Linderman and Fried have taken web content best practices to heart and cut the prose down to the bare minimum. Often, a paragraph is all that accompanies each example screenshot. Whitespace abounds. This makes for a very easy to read book; I finished it in well under three hours. For the most part, the brevity was welcome. However, there were cases that could benefit from additional discussion.
All in all, I heartily recommend this book. If your work involves web applications or web forms, the guidelines offered in this book will, at the very least, make you think about some of the things that might be missing in your work. Reading the book sparked a number of good ideas that I plan to put to use in a future project.
Posted by Karl
April 9, 2004 08:38 PM