Poor Contingency Design Can Cost You
June 08, 2004 | 
23 Comments
If you are designing or developing Web sites, especially if you use complicated functionality, lots of forms or heavy task-based interaction you need to get yourself up to speed with contingency design.
What it contingency design? It’s design for when things go wrong. Things like error messages, 404 pages, and form behavior fall within the realm of contingency design.
My suggestion for those of you who have no experience with contingency design is to pick up a copy of 37 Signal’s book, Defensive Design for the Web. It’s a very easy and informative intro to contingency design that should be in every Web designers collection.
Contingency Design Is Still New To Many
It’s pretty obvious that contingency design is one area that most Web designers and developers are lacking knowledge in. I know it’s still pretty new to me, and I’ve really just begun to understand how important it is.
I’ve said before that much of the Web is unusable. I still believe this to be the case, but hopefully it’s getting better. I can see that many more people are looking into things like user-centered design and Web standards and these things can and will do a lot to make the Web an easier place to get around.
But we still have major problems in many places.
When Things Go Wrong
I recently tried, pretty damn hard to be honest, to buy an FTP program. After filling out the form three different times I simply gave up. The company from whom I was going to purchase this software lost a sale because of poor form design and even worse contingency design.
It was supposed to be so easy…
The first time I filled out the form, I accidentally pushed the “clear” button. I do this all the time. Simply putting it further away from the “continue” button would have been a great help. Frankly I’ve never, ever, had a reason to clear a whole form any way, and I doubt their use.
The second time I lost my information by clicking the browsers “back” button after receiving a rather uninformative error. Shouldn’t there have been some mechanism in place to remember my info?
The last time I clicked their “back” button, again after a vague error. I lost everything and had to start over yet again…only to get another vague error. That’s when I just gave up. I mean I’d entered my credit card info and everything else three damn times! Did they not want my money?
You should have heard the “F”-bombs I was dropping. Everyone in my office did.
Don’t Get Caught With Your Pants Down
All of this could have been avoided pretty easily. Just taking some time to write some clear, human readable error messages probably would have got me through the purchase process just fine, and if there was a “real” problem that I could understand I’d have been more inclined to try to work it out.
I don’t have the patience to deal with even the most simple frustration on the Web. There are way to many alternatives, no matter what you’re trying to do with your site.
It’s true that if something can go wrong it probably will. It’s important to test your designs and try, as hard as you can, to anticipate where your users will run into problems.
This kind of design isn’t all that hard at its most basic. Simply learning about it, thinking about what may go wrong and planning for what will go wrong can do a world of difference. It’s too bad that more sites, and more designers, don’t think about this stuff at all.
Just a little knowledge and effort can go a long way and doing nothing can really cost you.
Filed under: Web Design
Comments
1. Paul G said:
Too true. In computer science classes, you are taught to code programs to “fail gracefully” and the blocks of code dedicated to error handling can sometimes exceed the length of the program itself. Good error handling is the differentiating factor between a “fair-weather” program that chokes on the slightest problem and one that is professional, polished, and rock-solid.
It’s a shame that similar methodology is not taught when learning the ins and outs of web design. You’d think it would be even more important on the web, given that a competitor’s product is only a click away. I tend to be very intolerant of poorly handled errors on the web, mainly because I know I can find a dozen other sites to get what I want and would rather not spend the time trying to figure out why this particular one is functioning so poorly.
Poor contingency planning also smacks of unprofessionalism. I am immediately more wary of giving out personal or financial information when a site errors out without a good mechanism to tell me what just happened and what can be done to resolve the problem. Errors will occur, and they can shake your customer’s trust, but proper contingency handling is the difference between that trust taking a momentary dip or having it take a long walk off a short dock.
Posted on June 8, 2004 10:51 AM | #
2. Joshua Porter said:
Most web stats packages will give you the details about what urls you served up as 404s (and other HTTP error codes). Of course, raw logs show them, too.
Sometimes it’s fun to go through the list and see what your users are seeing. You probably won’t feel their pain, but the embarrassment can be persuasive.
Posted on June 8, 2004 11:14 AM | #
3. Jeroen said:
You hereby receive the first price for the most creative ‘speling’ error:
Besides this, I fully agree with you. I can’t believe the difficulty some sites give me to perform basic actions.
Posted on June 8, 2004 11:58 AM | #
4. Keith said:
I just love it when people point out my typos and spelling errors in public. I don’t have an editor, but I do have an e-mail address.
;)
Actually that one is pretty funny.
Posted on June 8, 2004 12:11 PM | #
5. Sam Ingle said:
I love it when people who point out typos have typos in their statement
Posted on June 8, 2004 01:35 PM | #
6. Mike P. said:
Funny, I have a post on contingency design ready to put up, just waiting to proff-read it (haha).
I’ve found in my experience that contingency design is something rather intangible to clients, and therefore can be a hard sell. It’s a details thing that does take time to implement in some cases, though I suppose with good forethought holes can be plugged more easily…
I’ve had most success working contingency design into websites once we’re in the maintenance phase of things…
Posted on June 8, 2004 02:17 PM | #
7. Keith said:
Mike – can’t wait to read it. I think contingency design should be a fairly easy sell, at least at it’s most basic. I mean it obviously depends on the site, but if someone is selling something or trying to collect leads, etc. contingency design is vital to the success of the site.
Posted on June 8, 2004 02:24 PM | #
8. Rob Cameron said:
Of course there will always be those clients/bosses who counter with “if you make it right in the first place then users shouldn’t see any errors anyway.”
That’s one of my biggest aggravations at my job: since the bosses only see the end result, they assume that 100% of my time is going towards the stuff they see, when in actuality they’re really only seeing 40% of the entire site, everything else is back end and contingency design. It ends up being a hard sell when I say that I need 40 hours to design and work on something that they’ll never actually see.
Posted on June 8, 2004 02:30 PM | #
9. Keith said:
Rob – That’s true – and isn’t that always the case?
I guess, as with other similar issues, you just have to try your best to educate them to the benefits of thinking about contingency design and the possible pitfalls of not thinking about it.
The bottom line is that this can end up costing your clients big time. A good way to get “in” (at least in some situations) with decisionmakers is to educate the sales folks about this stuff and let them advocate for you.
I’m pretty sure they’d care about the possibility of snagging extra sales.
Posted on June 8, 2004 03:00 PM | #
10. Kevin said:
Rob, I’ve found that when when working on error handling or other back-end, detail-type things that are largely invisible to users and bosses that it can help to take pile of code and diagrams to the boss/client and show them what you are doing. Of course they almost never really want to hear the details but I’ve found that seeing a huge pile of code or diagrams helps them to understand that you are doing something real, even if they don’t really understand it.
The goal is not to point out how great you are or how little they know but to take something that is largely intangible to people like back end coding for form processing and make it tangible.
Also, for anyone who wants it, I’ve found that ieSpell is a great way to quickly check your ‘speling’ in comments on places like this. It tends to catch my most egregious errors. I’m sure there’s something similar out there for FireFox or Safari too (I’m still using Avant Browser most of the time).
Posted on June 8, 2004 03:08 PM | #
11. Josh King said:
Pardon me if this is overly apparent, but I think it is important to underscore the importance of testing with actual users when discussing Contingency Design. I think had the individual responsible for the form you had problems with actually sat users down and had them go about their business, this type of thing probably would have been averted. With deadlines it can be tempting to skip testing, but this can almost always be avoid with good planning. Maybe the lessons of software engineering will stumble onto the scene much like information architecture and usability have. /me crosses fingers.
Posted on June 8, 2004 03:25 PM | #
12. Keith said:
Josh – You’re right. It’s not overly apparent to everyone and while it should go without saying that you should test with real users, it’s always good to be reminded.
Posted on June 8, 2004 03:28 PM | #
13. Mike P. said:
Responding to Keith in comment #7:
The post isn’t anything too special, just an extension of an earlier idea. At any rate, you are totally right.
“I think contingency design should be a fairly easy sell, at least at it’s most basic.”
Totally, but it never seems as cool to them as it does to me!
Posted on June 8, 2004 03:35 PM | #
14. Timothy Uruski said:
Keith, you work on a Mac at all? Safari and any other browser that uses WebCore as it’s foundation gets free spell-checking in all form fields! Plug!
Good post! I think that people are finally starting to see that flip-side of web design; what the user gets to see when things turn pear-shaped.
Posted on June 8, 2004 03:58 PM | #
15. Keith said:
Timothy – don’t want to get too off-topic: but yeah, I use Safari and I do spellcheck everything. Don’t know what I’d do without my handy in-browser spell checker.
Posted on June 8, 2004 04:24 PM | #
16. Max Thrane said:
Great post indeed.
PS: When I do websites I usually do double check, first with JS and then with PHP.
Regards
Posted on June 9, 2004 04:44 AM | #
17. david g said:
I noticed you and Andy Budd are both plugging this book today.. which is odd, as it’s been available for a few months now. Is it not selling well, or is this just a coincidence?
Posted on June 9, 2004 07:34 AM | #
18. Shawn Rice said:
When working on a rather large project, I was deeply focused on the mantra of “Make it work!” Somewhere in my head a voice was whispering “If you make it all work like it is meant to, there should be no error pages or 404s to worry about.” Sadly, this wasn’t absolutely true. Sometimes errors will occur. It’s just a fact.
I picked up 37signal’s book, devoured it, and took another look at the site I was building. I originally had little error catching, no indicators of required form fields, etc. What a mess! I ended up spending almost a third of the overall development time putting in the contingencies that I should have been thinking about from the beginning.
In the end, the client was as thrilled over the fact that the site would display a custom error if the database connection broke (for example) as they were over the intended functionality of the site. Now, I think about previous sites I’ve worked on and cringe over problems I know need to be fixed.
Posted on June 9, 2004 07:59 AM | #
19. Keith said:
davidg – It’s just a coincidence. I’ve had the book for awhile and it’s a great one. I don’t really care too much if it sells – other than because I feel it’s a must read – as it’s not my book.
I’m affiliated with 37signals at all and would have no clue as to how it’s doing.
Get the book. It’s a good one.
Posted on June 9, 2004 10:15 AM | #
20. Matthew Linderman said:
Hey guys, Matt from 37signals here. Thanks for the kind words about the book. And fwiw, it’s selling just fine. ; )
Posted on June 9, 2004 02:58 PM | #
21. Keith said:
Matt – good to hear from you and I’m very happy to hear it’s selling fine! I’ve been, as you can see, recommending it quite a bit as I found it very enlightening and very helpful.
Thanks for putting it out!
Posted on June 9, 2004 03:04 PM | #
22. david g said:
glad to hear it’s doing well.. the timing was just odd, i guess. your site is just below andy budd’s in my “slacking off at work” bookmarks, so for a second i got disoriented that’s all.
and yep, it is a good book. there’s definitely a need for more books focused on designing web apps, and this fills a good niche. we have a copy in the office, and i’ll probably buy one for home use too :)
Posted on June 10, 2004 09:35 AM | #
23. dusoft said:
“Clear” buttons are not very useful for public forms. They work much better when in admin interface - e.g. you want to edit article, then when you press Clear/Reset, data enetered are undone. This is useful sometimes.
Otherwise, it is easy to put onclick function on reset button and then use PHP to remember data entered, even if error is encountered.
Posted on June 10, 2004 05:30 PM | #
Comments are now closed