Design principles have been a hot topic this spring, with both Jeremy Keith and Whitney Hess giving talks throughout the country, and lots of folks looking for, and building, lists of principles. (Note: I haven’t heard either talk, but I’ve seen retweeted notes and my understanding is that they were both excellent.)
We have a set of design principles and heuristics at my primary employer, which I’m developing training for. I’m exploring concrete examples inside and outside of the web, since I’m the type that learns from those best.
Error handling: Make it easy to identify an error when it occurs.
I drive an 11-year-old 2001 Saturn SL 1, which I’ve owned since it was 12 miles old. That car and I know each other pretty well. (Her name is Fluffy.)
This morning, a new thing lit up on Fluffy’s dashboard.
Clearly a warning light, it was trying to tell me something, but I’d never seen it before. My first guess was “GO TO THE BEACH”, because it’s June and that’s where I want to be. My second guess was “oil is low” because oil burning is the biggest problem Fluffy has had in her later years, and thus it was fresh in my mind. But low oil hasn’t triggered a light before, so despite being this car’s expert user, all I really knew was what I didn’t know.
Fortunately, I keep Fluffy’s manual in the glove compartment. The manual describes all the obvious error messages and error conditions, what to do about them, and when to contact someone. It’s both unobtrusive in its home in the glove box, and accessible when I needed it, regardless of the error. (well, “passenger seat on fire” might have caused problems, but there’s no light for that anyway.)
I could have chosen to take out my iPhone, and Google the problem. But the book was easily accessible without power, without cell signal, and without searching a half-dozen websites for a solution. It fits perfectly in the lowest reaches of my glove compartment, where it doesn’t interfere with the napkins, pens, and (yes actually) gloves I’ve piled in there over the years. It was designed to be accessible when I need it and out of the way the rest of the time. It was easier for me to look up the light’s meaning than to drive away and worry, which is a triumph in designing against inertia.
(The light, by the way, is a warning that I’m low on engine coolant.)
Error handling design heuristics are tightly coupled with learnability heuristics. A novice user who learns where to look for help will eventually become an expert user that doesn’t use the manual for years, but might need to look up a random light on a sunny July morning. The language and icons need to be as understandable as possible for both the novice and the expert user. (Had I followed up on my first guess and added a quart of unnecessary oil, Fluffy would’ve been smoking for days!)
When we’re designing a process, we decide what the manual will look like. The manual can’t just be rainbows and puppies, regardless of how badly we want to give the impression that our sites will never fail. Everyone – even our expert users – will occasionally run into an event they weren’t expecting. It’s a task outside the happy path. The more obscure the problem, the better a chance we’re going to want to avoid building both the error notification and the follow-up steps altogether. That’s a temptation we should avoid.
Make sure that your messaging is findable and clear. If you can detect an error occurred, don’t just give a warning light, but also give instructions on what to do about it. Make choices on when to display that message immediately (“GET OUT YOUR CAR IS ON FIRE”) and when to put the error in the manual in the glove compartment. Make good conscious choices about all of the unhappy paths, and you’ll satisfy the people using your process even when things go slightly awry.