When all things fail - Designing for State
How to gracefully handle the state shift while designing your interface.
There is a common mistake we make as designers. We assume everything will always work fine. You make the same mistake, I make the same mistake, hell the best designer you know has made the same mistake. While this article would cover error states, it is only meant to define the transition from state to state and how to handle it graciously.
The Design State of Affairs
While designing, we are typically met with 3 possible states for components or pages.
Loading State.
Failure State.
Success State.
These states outline most of what your interface is all about. No matter what, your interface will always fall into one of these categories.
Back to the flow from state to state
Designers typically focus heavily on how the user feels when moving across their product. The core idea is to reduce entropy as much as possible, almost eliminating it in fact (this is nearly impossible to accomplish).
Loading anything
When loading a page or component, there are varying ways of handling that state. Some people use some sort of loading animation, others use a skeleton. These approaches depend on the use case and other technical constraints.
I’ll focus on using skeletons and the technical constraints of loading up components with data from multiple sources. What happens when nothing loads? What happens when some things load and others don’t? These are the questions that require answers.
Let’s talk about why we use skeletons.
The illusion of speed — Using a skeleton while loading information on a screen gives users an impression of progress and as such the feeling that the expected information has started streaming through.
Easy transitions — When users see skeletons as information loads up on a page, they begin to get an idea of the structure of the page when it loads fully. That way, depending on how detailed your skeletons are, the transition is typically smooth for users.
Non-repetitive — When data is being pulled from multiple data sources, it is easy to fall into the trap of using spinners per component. It goes without saying, that this is an incredibly bad idea as you have an interface that becomes a jam of multiple spinners. And this is typically not desirable.
We have talked about when things work out. On the flip side, there is a world where all things fail. When some things fail and others don’t we ideally want to give users a couple of things.
A way to know that something didn’t work as expected.
A way to know exactly what happened.
A way to retry what failed.
Depending on your data source and how your page is structured, you could have any given mode of failed states:
Page-Level Failure — This typically happens when no data is loaded on the page. This can sometimes be caused by total system failure (obviously things fail on the client).
Component-Level Failure — When things fail on a component level, it typically means the service that provides that data to populate said component unable do so at that given time.
Handling Page-Level Failure
Handling Page level failure can sometimes be very straightforward. Most times when this happens, a simple error message with a call to action at the centre of the page would do. Sometimes, you can make it fancy and lead users out of the failed state to a predetermined flow. In this case, a flow that adds value to both the user and the business.
Interface Flexibility — This means moving items around in such a way that the interface is still usable. It involves adapting the interface to handle component-level failure gracefully. This is nuanced as depending on how critical the failures are, you might want to make the failure obvious or in some cases, you might want to obscure them if they are not critical to the page/interface.
Rounding things up
It is important to handle failure when some things do and others don’t. In this case, you have how you handle it makes or breaks your interface. It also shows the level of attention you have put into designing your product.