Designing for failure

One of the things that impresses me the most about a product, either offline or online, is how well the product is designed to fail. Whether it's the fault of the user or the product, things are not always going to work according to plan, and it's important to guide a user back to what is normal.

This is a tough thing to do of course for a couple reasons. A biggie is because by this point most of us are trying to follow Pareto. How many of us are trying these days to build simple things? We are focusing on the 20% of the product that will get 80% of the use.

But what's tough is that the 20% changes. For brand new users, that 20% of the product that's getting used in the first 5 minutes are error pages and learning and exploring. It's not the "normal" flow.

Another reason we are bad at designing for failure is because we have the curse of knowledge. I wrote about an experiment mentioned in Made to Stick recently. The experiment was to prove that people are stuck in the curse of knowledge. People were picked as tappers and listeners. Tappers were to pick a popular song and tap it out for listeners. Tappers were extremely overconfident that listeners would understand the song they were tapping. Why? Because the the tapper can hear the song in their head. And it completely changes the perspective on their task.

So designing for failure is so much harder to do because of this. We can "hear" the product in our head already. We know all the normal paths and don't need to discover features. And we neglect to remember that our users aren't there with us yet. They'll be failing a ton for at least a minute or two.

Let me pick a case where things aren't designed for failure and show a couple that are.

37signals Highrise

Here's an example where 37signals' Highrise isn't designed for failure very well :) I'm doing this because I have a lot of respect for 37signals' design and they are often considered a gold standard, we also use Highrise quite a bit these days. They even wrote a book on this very subject. Yet we all have trouble with designing for failure.

Here I want to add a new Contact into Highrise. I emailed [email protected] recently. I didn't have the person's name, but I wanted Highrise to track the conversation with this company. So I clicked "Add a new person" from the Dashboard and here's the add a contact screen with company and email filled out.

I hit the Add this person button below this, and nothing happens. Not an error, not a success. Just nothing. Like the button doesn't work. I realized at some point that First or Last Name are required. There's no indication of that other than the labels are bigger than the other field labels. But that might indicate they are both required? No, they aren't. Only one is. But I don't have a name at this point. Shoot. It's when I started clicking around though directly to the Contacts tab did I discover a "Add a new company" link where I could add the company, my [email protected] and not have to enter in the names of this contact.

So this is where some extra thought could have been applied to handle errors related to not entering required fields.

Git

How often have you mistyped something on a computer expecting it to be the right command? Git takes the approach of trying to figure out what you might have been typing.

I mistyped git merge as git mrge and git tries to educate me that there is a command called git merge instead, or I can use help. Such a little but useful touch they've added to help when things go wrong.

Tgethr

One area that we are proud of in tgethr is how tgethr handles a couple error conditions. When you send a tgethr group an email and there's a problem, we'll send back help about the problem. We started with a generic, "there's been a problem" kind of error that most people throw up by default when an error can only be handled generically. But we wanted tgethr to be more helpful than that.

An example is now when someone tries to send a message to a tgethr group and their group only accepts signed messages, but they forget to sign their message, we tell them.

---------------------------------

No one is going to be perfect at doing this. But I can testify that in the cases where we get this right, we hear about it.