Defensive Design for the Web
In: Reviews > Book Reviews
Published on August 4, 2004
This book won’t teach you any new coding tricks, but it may change how you think about Web sites and Web design.
I enjoy 37signals’ articles on the Web, so I had this book in my Amazon.com wishlist well before it came out. Because I’ve been hit by budget cuts as hard as everyone else, I still wanted to do a little research before I actually shelled out my money. Welcome to the greatest invention ever: the downloadable chapter.
I downloaded the free chapter about forms. Though I haven’t created many forms in my sites, I read the chapter and it changed the way I looked at Web sites. Suddenly, instead of being frustrated by a poorly designed form and becoming angry at myself, I turned that anger where it should be directed, at the site designer. I also took the time to examine the form and see how it could have been done better. It turned the whole Web into a learning experience.
So, I handed over my hard-earned cash and bought the book.
What’s in the Book
The authors describe what the book is about better than I ever could:
“This book will teach you all about contingency design, design for when things go wrong.”
Anyone who’s worked with Web sites knows that if something can possibly go wrong, it will, but I’ve never thought about designing specifically for when things go wrong. This book shows you how to do that by giving lots and lots of examples from real Web sites.
Reading Defensive Design for the Web was like surfing to hundreds of different Web sites with a usability expert whispering in my ear, explaining the site, showing me not only what was bad about the site (which is generally easy to point out), but also what was good.
For variety, the authors also pitted similar sites against each other, head to head, a little like Discovery Channel’s Animal Face Off. Not only was it fun, but it dispelled the myth that maybe it’s just too hard to design well for failure because the winning site showed how to do it right.
My favorite part of the book was the real world analogies. For some reason, when we start talking about Web sites and the Internet, people think we’re completely divorced from anything real. The authors bring us back to reality by giving real world examples of what we come across all the time on Web sites.
For instance: “You’re at a department store and you ask for a mop. But the clerk sends you to the electronics section.” We’ve all had a search do that to us, but most of us just accept it as the way it is. The real world examples throughout the book help remind us that it doesn’t have to be that way and, indeed, really shouldn’t be that way.
- Understanding Defensive Design: making mistakes well
- Show the Problem: display obvious error messages and alerts
- Language Matters: provide clear instructions
- Bulletproof Forms: create friendly forms that are easy to complete
- Missing in Action: overcome missing pages, images or plug-ins
- Lend a Helping Hand: offer help that’s actually helpful
- Get Out of the Way: eliminate obstacles to conversion
- Search and Rescue: deliver the right results with smart search engine assistance
- Out of Stocks and Unavailable Items: make sure unavailable items don’t become dead ends
- The Contingency Design Test: see how your site rates
- Contingency Design: a long-term commitment
Chapters 2 through 9 are the meat of the book, giving the guidelines and examples that illustrate each subject.
It’s strange to think about the usability of a book. I often use books as an example of usability we don’t have to think about (e.g., chapter titles, tables of contents, page numbers), but when you’re trying to learn about something as complex as Web design, you can use all the help you can get.
Remember all those weighty textbooks in school? Well, were they weighty because of the subject matter or because the authors didn’t spend the time and effort to make it easy to learn?
I expected a very usable book from 37signals, and got what I expected. They described up front what was in the book and what all the symbols meant. Then they used graphic design to make everything easy to read and find, like putting a black background behind the title of each guideline and making the pages at the beginning of each chapter grey. Little touches like this make a manual easier to use.
I had only a few minor quibbles with the book.
They only used the term defensive design in the title and the first chapter. They switched to the term contingency design in the introduction and throughout the rest of the book. I could almost hear someone saying that “Defensive Design” sounds better for the title, but industry people would be more familiar with contingency design. Does this detract from the book? Probably not.
I don’t agree with their little diatribe about calling visitors to the site people not users. I personally like the term user because it reminds me that visitors are not passive, they are actually using the site. But, you say potato, I say potato (you know what I mean.)
For the most part, I completely agreed with what they identified as good contingency design versus bad contingency design, but I’ll throw in my two cents on one point: soliciting feedback on help pages. The authors suggest that you let visitors tell you whether a help page was in fact helpful or not. Seems like a good idea, but I know that I have never filled out one of those little forms and have, in fact, found myself irritated that, when I can’t find the info I need, they want me to help them improve their site.
Using the principles of the book and my own personal experience, I would be more likely to tell them I hadn’t found the help I needed if they would then offer to get me better help, maybe by connecting me to a chat room or forum.
Shift in Attitude
I’ve finally shifted away from thinking of a “finished” Web site as a complete and perfect thing. I tell my clients up front (again and again) that the Web site we launch won’t be perfect. I try to present this as a plus, not a minus. The fact is that Web sites are much closer to stores, which can have mis-stocked items and clueless clerks, than they are to magazine articles, which can be very close to perfect and are not changed after they are printed. This book helped to reinforce the idea that Web sites will never be perfect and to put a positive spin on the whole idea.
After reading Defensive Design for the Web, I think of potential problems as places to learn more about the user and to make the site better. The page that hit me the hardest was about a customer relations study at a hotel. They actually found that visitors who had a problem that was nicely resolved rated the hotel higher than visitors who hadn’t had a problem at all. That’s a study that can give hope to us all. We can strive for a perfect Web site, but will never achieve it. It’s nice to know that we can build strong customer loyalty by using contingency design—and this book will help you do that.
What It’s About
Designing for problems and user error. This book points out that user error or site errors can actually be an opportunity to gain the user’s good will.
Who It’s For
Intermediate to Advanced Web Designers, though anyone can get something out of it. There is so much to learn when you just start crafting Web pages that this book may feel like (and may be) a waste of time for beginners. If you have an open mind and some free time, it’s a good read.
Like Steve Krug’s Don’t Make Me Think, this is a book that non-technical people can read and understand, though it may be too long. Perhaps excerpts would be good.
Lots of examples, both good and bad, from real Web sites.
As the authors admit, the task of designing your site for contingencies can seem daunting, but the authors give suggestions on how to start.
An excellent resource for anyone working on Web sites who already knows the basics of creating pages.
Defensive Design for the Web
New Riders, 2004, 256pp.