When we design our products, we often design for the happy path scenario, ideal user flow without any obstacles. But in real life, there are situations which don’t go to plan. Such conditions are called “edge cases”.
Edge cases might be pretty rare, but they have a significant impact on user experience. Users rarely remember positive interaction, but they often remember negative experiences; if you fail to prepare for such situations, the whole experience might quickly fall down.
In this article, I’m going to share some edge case scenarios you might have to deal with, and how you can plan for them in your designs. There are two basic approaches for handling edge cases:
Given a choice, it’s always better to prevent the edge case from happening. In some cases, this can be done by reducing the complexity of the system (e.g. limit the number of features or actions users can perform when interacting with a system); less complexity decreases the possibility of edge cases in the first place. However, there are times when it’s impossible to prevent edge cases from happening, so you’ll frequently find that supporting edge cases is the best option for your users:
As technology enables faster experiences, users’ willingness to wait has decreased. According to the latest Google survey, 2/3 of mobile web users say that the speed it takes to load a page has the most impact on their overall experience. To satisfy users’ expectations, you should do everything you can do to make your app/website load as fast as possible. But no matter how hard you try, there’ll be situations when you won’t be able to comply with speed guidelines. Slow loading time might be caused by limited internet connection. If you can improve the actual performance, at least try to create a perception of speed — how fast something feels is often more important than how fast it actually is. One technique that can help you with that is called skeleton screens. A skeleton layout is a version of your page that displays while content is being loaded. Skeleton screens give users the impression of speed (most users will believe that loading is happening more quickly than it really is).
LinkedIn use skeleton screens to give the impression of speed.
Check this Codepen example of skeleton effect in pure CSS. The effect of pulsation gives a user the feeling that a website is alive and content is loading.
It’s possible that individual screens in your app or website that should be populated with data will have nothing to display in some instances. For example, a screen with user challenges in a fitness app will be empty during the first-time experience (simply because users won’t have any challenges yet). As designers, we need to think about how the page looks like in this case. Showing a blank page isn’t the right thing to do. Instead, we can provide instructions on how to populate the page with data. Khaylo Workout for iOS is an excellent example of how empty space can be used to create context.
Empty space on the page can be used to give clear instructions on how to get started.
Every user interaction with a system can be a potential source of error. Error states are especially common when users need to provide data input. I’ve already mentioned that it’s better to prevent errors from happening in the first place and this rule should be applied to user input. But when it comes to user input we should focus on handling the following potential problems:
In both cases, you should ensure the app is handling errors gracefully. Error messages should be written in a clear, user-friendly language (no jargon allowed) and the system should provide a precise solution (this might be an instruction or something else that might help).