Designing Failure

What is contingency design?

Contingency design is the discipline of predicting how a system might fail and then designing solutions to either prevent the failure or to deal with the failure elegantly, negating any detrimental impact it may have. It's design for when things go wrong. In this article, I’m going to focus on contingency design from the perspective of user experience.

What is a failure?

In the context of this article, a failure is any situation where a user action asks the system to deal with a situation which was not intended or is not ideal; it’s a request which cannot be fulfilled. It's not necessarily the fault of the system or the user, but a result of the interaction between the two.

Let's look at some examples

Probably the most obvious example of contingency design is the humble 404 page. We predict that sometimes users will request a page that doesn't exist, either by typing the URL incorrectly or because the page has been moved or deleted. There are some defensive steps we can take to reduce the likelihood of the failure but ultimately we can't prevent it. Instead, we design the failure so that the user understands what has happened and what they can do about it. We might provide links to potentially relevant content or simply direct the user to a keyword search facility and by keeping a log of each request that results in a 404 we can identify and defend against reoccurring problems.

Another great example of contingency design is form validation. We predict that some users will forget to complete some fields or enter the wrong information. We can defend against this failure by providing clear instructions, either literally or preferably by the way in which the interface is designed. We can also reject the form if it's submitted with missing or incorrect data while explaining to the user what went wrong and how to fix it.

Thinking a little deeper, consider a property website - something that Red Ant happen to be working on at the moment. People can search for properties in a particular location and the system will return a list of matching properties. What if there are no properties in that location? We could display an error to that effect and ask the user to enter a different location, but that's not particularly helpful. If we're clever, we could look at nearby locations which do have properties associated with them and return those instead. What if there's a typo in the user's search term? Again we could simply display an error, but why don't we suggest locations with a similar [correct] spelling?

How do we predict failure?

Firstly we need to know a little about our users. Who are they? What are their goals? What are their limitations? It might help to give each persona a name and a personality. By creating a series of personas representing the different types of people that are both likely and unlikely to use our system, we can start to imagine how they might think and behave.

Once we've identified our users and have an understanding of their likely behaviour, we can make a list of 'what if...' questions and identify one or more solutions for each. We know what we want them to do, but what if they do it this way instead? What if they ask for something and we don't have it? Each scenario should describe a user action or request which is not ideal and is likely to test the system, and each solution should either defend against failure or propose a way for the system to handle the situation efficiently.

How do we defend against failure?

Once we've identified what could go wrong, we can put things in place to stop it. Our first option is to communicate with the user. If we want our user to follow a particular route, or perform a particular action, or provide particular information, we need to communicate these instructions in the right place at the right time, as simply as possible. Alternatively, be flexible and allow things to flow in a more natural, forgiving way.

If, through our personas, we predicted that some users might not understand an interface or a process, now is the time to take another look at that component and consider how we could improve the design so that it's clearer and more usable by everyone.

Instructions are sometimes necessary and beneficial, but our aim should always be to design an interface which is discoverable and understandable in its own right, without the user having to ask for help.

If we know that we cannot provide something, it might be a good idea to disable the functionality that would let users request it. For example, if we ask users to select which date they would like to attend an event and we already know that some dates are full, it would make sense to remove those dates rather than allow the user to make a selection that results in a time-wasting error.

How do we design failure?

It's important to recognise that it's impossible to defend against everything. Each user is different and has the ability to test our system in new and unexpected ways, but even if we can predict behaviour, we cannot necessarily prevent it.

The key to designing failure is to understand what the user wants and to identify solutions, alternatives and escape routes if things do go wrong. Our ultimate aim is to keep hold of the user; we want them to complete the task - we don't want them to give up in frustration and try elsewhere.

Sometimes users will ask for something that we don't have. If we're lazy and just throw a "computer says no" error, there's no reason for our user to stick around. We know what they've asked for so we should be able to look at what we do have and make intelligent suggestions for alternatives. If we don't have anything suitable at the moment, maybe we could collect an email address and let them know when to come back; we can't extend the current browsing session but we should at least encourage a return visit.

A failure shouldn't look like a breakdown. Follow the same style guide and writing style used throughout the rest of the website. The user should always know where they are and be able to go back to where they were before. Error messages and instructions should be calm, friendly and concise; don't shout "ERROR!" or make the user feel guilty for doing something wrong.

In conclusion

Good contingency design enforces user confidence, increases satisfaction and builds loyalty. We should aim to prevent failure by designing defensively but it's impossible to design a perfect website. We can't always prevent failure but we can design the failure by providing escape routes and intelligent suggestions which allow the user to do what they want to do with minimum effort.

We must observe user behaviour in order to learn how accurate our predictions were and to discover new use cases and scenarios which we hadn't anticipated. Carry this knowledge into future projects but remember that every system and every user is different.