Blog

Designing for failure: a UX pain point checklist

A checklist of UX elements that are essential for users, but often overlooked by designers.

Sarah Kilian, Unsplash

As designers, we’re natural optimists. We focus on designing features in their best state, and for the most ideal situation. But successful user journeys aren’t the only ones we need to focus on — it’s the stumbling blocks, pain points and frictions that can drastically affect how a user interacts with, and feels about, your product. Designing for failure is a big challenge, but one we can’t afford to overlook.

As I have gained experience as a designer, I’ve started to build up a checklist of things to remember when I’m designing for digital platforms. Mostly this list consists of assets to export and things to remember to hand over to engineering, but recently I discovered it was becoming more of a list of UX failure points — tangible things that users can’t live without, but that often aren’t considered as a primary concern. When you start thinking of all of the things that can go wrong, you can begin to map out all the simple UX nuggets that need to be included.

Are you talking about 404 pages?

404 pages are a classic example of designing for failure but, as much as I enjoy a funny error gif, they’re generally not a good example. A clever 404 page might make users smile and reflect your company culture, but it doesn’t tell users what went wrong, or how they can find what they are looking for.

At the top of my failure checklist are custom error states. Relying on developers to use generic error states to solve user problems may have been fine in the past, but it just doesn’t cut it anymore, in a world where user expectations are so high.

Designing for apps and web platforms that have a vast amount of custom components calls for custom error states that help a user understand what has gone wrong and how to continue their journey as quickly as possible. This is the best way to create a great user experience.

This example of an error ‘snackbar’ from Tumblr shows what happens when a user action fails. As a message, it doesn’t tell them what happened, or what they can do to ‘make it work’. (On a side note the white text on the red background is also not very accessible to some users – but that is a whole other blog post…!) Is it a problem with their internet connection? Or has the app just had a breakdown? If I was the user, I’d be closing the app down and trying again out of desperation.

When testing a product with users recently, we found they didn’t notice that a snackbar had appeared at the bottom to tell them they weren’t connected to the internet. We had assumed they would see it, as a new area flashed up on the screen. Instead, they were frustrated that no new content was loading but continued with the cached content, regardless of the error message.

At this point, we learned to design for those users first. They needed something more obvious to wake them from their autonomous journey. We had wrongly assumed that this new behaviour would be easy to understand — when users are focussed on a task and something goes wrong, they need to be jolted awake as if they have an engine failure on a motorway.

Facebook shows a full-screen takeover to explain a similar problem, so the user can retry the action. This is a good example of gaining the user’s attention, but It’s not perfect. As a user, it gives me no indication of what I was trying to do in the first place, and there’s a good chance I will have forgotten by the time I’ve sorted my internet and gone back to the app.

Each use case comes with its own challenges, which shows that relying on generic error snack bars and error messages doesn’t always do the job. We have to create new habits for users, by subtly coaching them through problems and how to fix them. They may expect notifications or errors to appear in a different area, so locking everything else down until they see the problem may be the place to start.

Please make a U-turn

Another set of challenges is presented in helping users navigate through content to find something when they might not know what they want. They may follow a path we try to lead them down, or they might try to search and discover it for themselves. A no results page can help guide them in the right direction.

The above example from Muzli shows how adding a bit of character to a ‘no search results’ screen can make it feel less of a dead end, even though the user is a bit lost. A nice bit of UI here can go a long way.

It’s helpful to imagine that your users are the type of people that would blindly follow their sat nav and drive into a lake. They need everything to be as clear as possible, so tell them what to do — as Headspace does in the above example.

Planning for a bad connection

Error states are not only important for when passwords are forgotten and internet connections go down. Even in a world of 4G and ultra fast broadband, designers should plan for slow loading from the start.

To make a platform appear like it is doing some work whilst users wait for it to load, we design skeleton screens with ghost components to ‘fill the gap’. This isn’t a new concept but, like error states, it’s often overlooked as something that can be customised in the design stage to improve the user experience.

Airbnb uses a simple skeleton of their results to indicate to the user something good is on its way. It makes the wait experience more enjoyable by giving a teaser of what’s to come. The ‘save’ icon in the top right of each result and the carousel button on the edge of the container are visible, even whilst loading. This is training the user to understand the layout before they even see the live data. There’s often an opportunity here to guide your audience on what you want them to click or see first, even before seeing any content.

Managing expectations is a big part of the design process, and providing an indication of the result of an action and how long it is going to take will always be good feedback for the user. If we change the environment they are in with a smooth transition using ghost content, we are helping their brain to adjust and process new information, as well as training them on the architecture of the page. It’s about considering the user journey before the user even knows they are on board.

Please wait… still loading...

The majority of users now expect an app to refresh by dragging down from the top of a feed — they see a generic loading icon and know what it means. Now that this has become intuitive, it’s important to incorporate it into familiar environments so the behaviour doesn’t have to be taught again. It saves time for users and for designers.

Generic loading icons will always be important in digital platforms as they reassure a user that their desire for action is being taken seriously. How can we push this UX further when loading and transitioning between screens? I’ve begun focusing on creating custom loading screens and messaging that fit with the brand (read more about messaging and the importance of UX writing here).

It’s easy for designers to forget about the transitions of pages as they load and what the user sees when they are waiting. The above example from Fabulous, a daily motivation & planner app, shows a full takeover loading screen. This is a great option when you want the user to feel like you have done a lot behind the scenes, as it gives the feeling of a journey from A to B. Fabulous provide a nice UI to keep users interested, as well as clever UX writing to keep them informed.

Make the most of haptics

There are some obvious differences between designing websites and apps, and one of the biggest things I see not being used to its full potential in app design is haptics — interaction involving touch.

On websites, we can get clever with hover states to make the user’s experience more enjoyable, and make it blindingly obvious what is clickable. As we’re unable to track users hovering digits on mobile and tablet devices, we need to give them the same experience using haptic technology.

I see pressed states as the app version of hover states. We don’t know where the user is thinking of going, but once they press a component we can give them the same experience. We now have the ability on some devices to incorporate functionality based on how forceful or long their press was.

This is lower on the checklist because it can’t be used to show the user what is clickable in an app — they need to know that from the UI beforehand. But once they have pressed, designers should think about how a user knows the app has recognised an action.

The pressed and dragged states in the material design system are a great example of how the user is able to see that their touch has been recognised. The detection of where the user clicked, shown by the placement of the circle, makes the experience feel trustworthy and elegant.

When we are creating design systems, we should start with the most simple interactions and see if they can be improved for the user in each instance. If a user clicks a button and it doesn’t work, at least with a pressed state they get some visual feedback that it isn’t their fault.

Check, check, 1, 2, 3

This UX pain point check list is almost always something I get to when all of the key flows are designed, the screens are tidy and my layers are named and organised (read more about my system for version control here).

UX pain point checklist:

  • Error states
  • No results
  • Ghost components
  • Loading screens
  • Pressed states

A lot of the above will be designed once problems are found in user testing. If you are designing a product, they might be implemented after an MVP has identified user frictions. It’s okay to prioritise the functionality and basic UX flow when designing, but I’m starting to like the challenge of creating the ‘nice-to-haves’ along the way.

Humans are not always paying attention. As designers, we like to think users will love our products and rave about every little detail. In reality, most of the time, they use them without thinking. Users have a job to do and just want to do it as quickly and efficiently as possible.

I admit to taking for granted how the products I have designed are built, and how they can go wrong due to a vast amount of uncontrollable issues. Designing for these situations helps me to help users when something trips them up, which can only result in making their experience better.

 

When it comes to user error, prevention is better than cure. Watch our on-demand webinar on friction mapping to find out how to uncover the pain points in your user experience.

Read next

Like what you see? We’ve got more where that came from.

Share: