When starting a project, it isn’t often that we build from the ground up envisioning the error states in a product.
Instead, we first design the absolute ideal state – how the product should look when everything is going right.
At the end of the day, we can’t forget to design scenarios for all the little moments in between. So in no particular order, let’s look at some UI states that we often forget to design.
The first thing I want to say is – the less error states in your app, the less negative reinforcement there will be overall.
We want users to feel like they are making progress, and successfully navigating through your product. When those bright red, flashy error signs pop up incessantly, you’re only going to make your user more frustrated.
Examples of success state scenarios:
- Correct Input This is the most basic form of a success state. Your user has entered their email and password in correctly, yay! Let them know that they have done so, instead of just hopping to the next page immediately.
- Upload Success. Documents and files that get uploaded should alert the user that they have successfully done so.
- Save Settings. Did I hit save? Did my changes apply? Make sure you make it clear that a user has saved their settings.
Message sent. In-app communication is tricky. If a user has to send information to another user (maybe they liked their content?) make it clear that the action has been successfully performed.
Ah yes, the necessary evil twin to success states. Although we want to minimize the number of errors that occur throughout the product, sometimes things just don’t work and we need to show that.
Error states become extremely important when vital workflows are being blocked, inaccessible, or required.
Examples of error states:
- Wrong input. Sometimes, a user is going to put the wrong thing into a textbox that you might not be able to predict. If you’re not already restricting the inputs on the back-end, show the user in the UI that this input isn’t going to work out.
- Can’t Upload/Download. If data cannot be retrieved for whatever reason, this needs to be called out. Let the user know that they are unable to upload/download – and if you can, let them know why.
- Not accessible. Sometimes, a user just isn’t allowed to access some data, and they should know why. If you have a product with layers of roles/permissions, and something isn’t hidden but not accessible, you might want to explain why. Sometimes, it might be an accident (like face ID going wrong)
404. These are usually related to connectivity issues, or a page that simply doesn’t exist anymore. Best to let the user know this is a dead end.
While success and error states might naturally come up in your process, empty states are the long forgotten sibling. They are actually crucial in how a user interacts with your product, but they are usually the last to be worked on.
Empty states are important so the user knows that the page hasn’t broken, or their data isn’t coming through – it’s just not there right now.
Tip – empty states don’t need to just announce that nothing is there. Take this opportunity to guide a user to an action that will add data to the page.
Examples of empty states
- First time using. Sometimes, the first time a user logs in, they won’t have any data to manipulate. This is a prime chance to guide them towards an action.
- No items in list. This can be any kind of list – documents, users, search results. If there’s no data to show, make sure they know the page isn’t just broken.
Empty input fields. What does this search bar look like before a user types?
This is a term I use for myself to describe information being directly manipulated by a user on a page – and is therefore active. Active states are crucial for apps with a lot of input fields – text, dropdowns, selectors, and so forth.
You may design the perfect form from top to bottom, laid out perfectly as a user loads in. But what does this form look like when populated with information? A user could input a little, but what would it look like filled to the brim? These are situations you might want to plan for ahead of time.
Examples of Active States
- Text fields. What if the input is short? What if it’s really, really long?
- Selection fields. If you’re working with a pre-built UI API, these might be defined for you. But on a highly customized product, you might not want to forget these.
- Buttons. We usually think of a button as active from the get-go, so just don’t forget this guy.
Loading states are one of those magical moments that let a user know things are happening when they don’t even realize. This is why skeleton loading, for instance, has become wildly popular – a user just knows there is data that’s supposed to be here, but it hasn’t loaded in yet.
We try to make our experiences as natural as possible on the most advanced of technology, and that’s exactly what the loading state does. Instead of us wondering if a page is loading, we know something is happening at all.
The computer doesn’t need to use a loading state – it would just pop in as info appears. But we carefully craft it in such a way so that a user doesn’t have to know that.
Examples of loading states:
- Data populating. The most common one, usually on page load. Let a user know data is loading in.
- Sending information. Much like the success state, let the user know their submitted data (form, message, etc) is actually sending.
Downloading/uploading. Let the user know their data is successfully getting sent to where it needs to go.
Data is not black and white. If we have it – yay, it’s there! If it’s not, then we think about the empty state. But what if it’s there, but just can’t be used right now? That’s when disabled stated come in.
Maybe a user WILL have the option to perform an action, but they must fulfill some prerequisite. Enter, disabled state.
You have to be careful, however. Disabled states are only one side of the coin, and work best in conjunction with more informative states like error states (letting the user know why this button isn’t working). Try not to use a disabled state until it is otherwise clear why the user can’t access this particular feature.
Examples of disabled state:
- Incorrect input. This goes hand in hand with error states sometimes. If they don’t provide the right input, perhaps the button is not going to be clickable.
Archive information. Maybe this data used to be here, but it’s not accessible anymore. BUT you still need a record of it. That’s when archives can be handy.