Planning for error: the UX of broken things
When I was working on creating error states, I did what any good designer does and googled the crap out of error patterns. What I found were some great articles of best practices, blogs that showed examples of error states, and some other fun ones too. What I didn’t find is how to plan and prepare for error states. What it seems like is that there are a lot of articles that speak about how, as a designer, we can create delightful errors as a reaction to when a product breaks, but I strongly feel that designers also need to be accountable and be proactive about preparing for error within our products and services.
Even with the best, most wonderful, beautiful, delightful, and amazingly designed product, there’s one thing that will always be true: Users make mistakes. They break things. Sometimes they can just (seemingly) go out of their way to interact with something in the exact opposite way it was intended to be used.
As designers, how can we better plan for user error in a way that helps our teams?
Start with what you know: Your user’s journey.
As an experience designer, what you know best is your user’s workflow. Utilizing your deep understanding of how users are going to use the product, you can understand when there are opportunities for error. You can do this for either a product or a service. I’ll walk you through using the techniques listed below.
- Identify most-frequently completed workflows on your site
- Understand your dependencies
- Provide in-context help
Let’s use an e-commerce website as an example. I’m a designer working at a company that sells soy candles with sassy messages on them.
Our typical users are folks who buy candles for events like birthdays, weddings, and one-off purchases of unique candles. We also sell a variety of candle accouterments like stands and hangers. Together as a team, we work to uncover the typical journey of our users through our site.
After looking through your user’s journey, you can identify what are some high traffic areas. By identifying the most frequently completed workflows on your site, we can start to see the places we want to focus on helping our users when they get tripped up.
Identify most-frequently completed workflows on your site
All in all, our most frequently completed workflows involve purchasing, browsing, and customizing candles. These are the key points where we find our users engage with our Sassy Soy Candle™ business. These commonly used places are the areas where we should focus on efforts on defining error because those are the places where, if an error occurs, users will likely get the most frustrated.
Understand your dependencies
Software errors don’t exist in a silo. While sometimes the error may be due to a freak accident, other times errors can occur because a part of the complicated machinations of multiple systems working together.
When we look at these high traffic areas, let’s take a peek under the hood.
Bring in your development team to understand how the inner workings of your product functions. You can uncover some core structural dependencies that are a part of the engine that makes your product run. For example, what if there is a 3rd party service that connects the candle messaging to the manufacturing service — something that helps our organization know that stock of the candles available to be produced. If something breaks down between the two, we may not have an up-to-date connection to our company’s inventory — resulting in users accidentally ordering candles that aren’t in stock.
Understanding how the dominos of development are laid out help us as designers to provide better context to our users as we craft error copy and interaction patterns.
Provide in-context help
Finally, we can start to build out how these errors are expressed. A good rule of thumb is for errors to be close to contextual as possible. We want to be able to assist users in the process they are trying to get through — not take them immediately out to help documentation or a chat if it’s not necessary. Utilize interactions that are built into your UI, like tooltips or notifications, to help orient your users in their own workflow.
Web errors and beyond
Thinking about error states also helps to define the boundaries of the components we use on a webpage and helps us to create limits on how things on the site should work — to decrease the odds of error in the first place.
Finally, there are a bunch of generic web errors that teams should design an experience around. But these web errors don’t have to be stale, dry parts of your experience. Error states give your organization a way to express some personality. Funny copy, drawings, or pictures of puppies are a great way to make the non-ideal path into something that is charming and shows that error, even in a product, can somehow still be human.
Why are there so many terrible errors out there?
Designers often get really focused on building a happy path for their users. After all, we are aiming to provide the best of the product or service we’re building. But after this happy-path design is handed off, it’s the developers who are left to build out the not-so-happy experiences.
User experience is a team process. As designers, we play a role in how user-centeredness is disseminated into our organization. We need to enable our broader teams to provide the best experience with design principles and best practices ensure that good user experience can work at scale. Part of that enablement means bringing team members into the process of creating designs. Thinking through potential errors and pitfalls gives us an opportunity to interact with our broader team and to bring them into the process of design.
As the user experience grows in the domain of experience design itself and more and more organizations utilize user-centered design at their core, delivering great user experiences becomes a philosophy as well as a practice. The reflective nature of planning for error within a product is an opportunity to practice that philosophy.
Ploy Buraparate is a designer based in Austin, Texas. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
