Empty states are places in apps that have no content or data. They are empty. A blank page. Traditionally empty states are overlooked as most designers focus on how best to display lots of content or data. It’s common for empty states to be dealt with by developers as they are often caused by exceptions (such as no internet connection). They often write the copy and as a result it can be a little difficult to understand or it is left with the basic styles. Not the best combination. It should be logged as something that needs designing but that doesn’t always happen.
There are three mains types of empty states. First use, User cleared and Errors (e.g. no internet connection)
1. First use
First impressions are vital. From meeting new people to learning how to use an app, they help users predict what that person (or in this case applications) will be like by comparing them to an existing mental model. Something they do have experience with. Sometimes there is no basis for comparison and users are a blank canvas, waiting to be impressed or disappointed. A bad first impression is very difficult to overcome.
When someone signs up for an app, the chances are high that they know what it does. It may not be clear to them *how* it does it though. When you sign up or log in for the first time, there is no data. It is the perfect opportunity to provide some careful hand holding to help users get the best possible experience. If the lack of data is out of their control then tell them; put them at ease and show that your app has some personality. Have a look at the way Buffer, Timehop and Dropbox do this. Buffer uses the same technique on their desktop site showing that it doesn’t matter what platform or screen size you’re on.
2. User Cleared
Consider the inbox. Love it or hate it, most of the time it’s full. Some people have hundreds of unread emails. Some people have only a handful. Either way everyone is on the quest for ‘Inbox Zero’ whether they know it or not. This can be quite a monumental task and as such should be rewarded with more than just your relief.
Take a look at how Sparrow, Gmail and the default iOS Mail app handle the empty inbox.
Sparrow shows an icon representing a traditional inbox and the phrase ‘Inbox Zero’. From an experience point of view this is quite nice. It’s clean, minimal and in keeping with the rest of the app. After all, everyone wants to achieve inbox zero.
Gmail goes a step further by injecting some character into the app with the smiling sun. By anthropomorphising the app, users can imbue the app with human emotions and connect with it on a deeper level as a result. The distinction makes it clear whether something is good, bad, wrong or right with the way they use the app. By looking at Sparrow, can you tell that getting to inbox zero is a good thing?
Mail has no feedback of any kind leading users to wonder whether they have mail and there is a connection issue or other error preventing them from seeing their mail. The fact that users may question that adds to the cognitive load, to the detriment of their experience.
Sometimes the people will experience an empty state as part of an error. Most commonly due to lack of an internet connection. This is another opportunity to make people aware that you know this can happen by having something more than just some ugly error text. It puts them at ease knowing that it’s probably not something they’ve done as you had spent time designing something for that specific case.
Look at the way Chrome and Opera Mini handle this compared to Safari.
Chrome has a huge amount of text that only tech-minded people will understand let alone bother to read. Opera Mini has something that resembles a modal window and nothing else. The language is more succinct than Chrome but nowhere near as easy to understand as Safari.
Safari on the other hand has an almost beautiful page explaining the issue in few words but making it even a much more pleasant experience. Which do you think puts people at ease when they get a connection error? One is calming, putting people at ease and one looks broken. While the connection is broken, there’s no need to scare people.
It still matters just as much even if your app isn’t a browser; another GMail example shows how the app handles a connection issue – again showing emotions. You know the app is sad but it doesn’t make you feel like you are responsible for it. Compare that with Instagram and YouTube’s connection-less state. A little underwhelming now that you know what’s possible. The Twitter app doesn’t even tell you that there is a connection error.
It still matters just as much even if your app doesn’t require an internet connection or isn’t an iOS or Android app. The fundamentals are still the same. Pay attention to when users will see nothing, and give them something.
Some companies are starting to pay specific attention to empty states; either as part of UX guidelines or a styleguide. Nokia draws specific attention to designing for empty states and — even though they don’t do a particularly great job, at least it makes it into their guidelines. Baby steps.
The important thing to remember is to make sure you add a layer of delight to your apps. Even the boring ones.
- Guide people on how to add data when there is none. A good idea is to break out of the conventional layout.
- Think about the goals people have when using your app. Will they clear data a lot or will it be a rarity? Design a nice surprise accordingly. If it is often, consider having a few designs and randomise them for an extra level of delight.
- Don’t scare users with errors. Do they make sense to someone who doesn’t know what they’re doing? Make them less daunting and more fun.
Above all, think about who is going to use the app and why. The details are what makes any app great. Delight your users and they will be much more forgiving if you make a mistake later on.
If you have any examples of good (or bad) empty states please submit them to http://emptystates.tumblr.com which is serving as an ongoing collection. You can also follow Empty States on Twitter. Here are some good resources for empty states as well as some anti-patterns to avoid:
Good article, thank you.
As always, nice, clean and very helpful read 🙂
Thank you so much
great tips, thanks!
I’m getting a “Not found” message when I visit emptystates.tumblr.com.
Was that intentional? 😀
Doesn’t the iOS mail app pop up an alert when there are connection problems? It might not be as nice as a separate screen but users are warned of errors. Of course, it wouldn’t be hard to say “You have no messages” but I don’t think it’s unclear. Still, I do agree something more would be nice, and it always is good to put something in that space.
Otherwise though, every iOS app which connects to the internet is required to report connection errors in some way. Though, how that is done is not very standard.
You’re right that they are required to notify the user but it’s just a nasty alert message. When gathering the iOS related content for this post I was in airplane mode and as such I was prompted to turn it off when any app required a connection.
However I think this post points out that you can design for those states and not just leave it for the system to handle. Having said that, I’m very aware that — due to time & budget constrains — these things rarely get included. Which is a shame.
“Mail has no feedback of any kind …” I would argue that they do through the “updated (insert time and date)” on the bottom.
Other than that, the issue of empty states is a good one. Thanks for pointing it out, Craig.
Ignoring empty states is part of a larger pathology, which is ignoring change altogether. I’ve seen a lot of static designs that work well with sample text and images, but fail miserably when exposed to the messy, dynamic world.
The only thing is that Safari’s error message is very often wrong or incomplete, so being succinct is not always ideal. It’s part of Apple’s strategy to load blame on others (in this case the internet connection) and never acknowledge anything wrong with its own product.
Craig, I agree with you on most of the stuff you pointed out. There are however two things in your article I highly disagree with.
The issue of error messages is one. Some designers think users panic and start crying when they see an error message, for this reason designers must hide or soften errors as much as possible. IMHO, this is wrong and leads to much confusion and in the long run leads to a bad user experience. For example, take your example with safari and opera. Opera gives me a very short explanation of what happened and how I should fix it. Safari gives me a much softer version of more or less the same text. BUT, opera has now a well defined method for showing me errors, safari does not. Opera is consistent (my number one design rule), safari is not. Also, this approach leads to safari (and ios in general) doing a lot of “silent drop” for errors then can not soften enough to show the user (application crashes for example). If an application closes, you wont know if it has crashed or if you accidentally exited the app. To me, this is the opposite of good design.
The second thing I don’t agree with is the part about Nokia. If you use meego about week and then go back to ios or android, you will notice that all the sudden things feel very awkward. You will be upset that things don’t work the way they are supposed to work. This shows that the design of meego so much more natural and easy to understand that you get used to it after only a week even if you have used ios/android since the beginning of ages. Thankfully, some core parts of meego are finding their ways to other OSes( swipe from edges for example). I think you should give Nokia credit when credit is due
Thanks for taking the time to respond. I agree with you that Opera has consistent messaging and I agree that Safari is sometimes inconsistent but you have to also consider who the audience is. The idea is not to hide the errors or to ‘dumb them down’ but to express them in a way that 80% of users will understand. I think the comparison between Safari and Chrome highlights this well, where as Opera seems to sit somewhere in the middle.
I’m sure Nokia have some good examples but in this instance — in their UX Guidelines no less — it’s not great but does draw attention to the need for an empty state. If you find some, please submit them to http://emptystates.tumblr.com/submit
(I cant reply to Craigs message, so I reply to my own instead).
Just out of curiosity, exactly what is wrong / not-so-good about this Nokias empty page?
If I recall correctly, they use this KISS-style UI pattern across all their apps, not only in empty spaces. I liked their KISS approach, so I love to hear why you don’t like it.
Nice article Craig. It’s a good idea to guide users through the app while not overwhelming them. A delicate balance.
Getting a lovely empty state for http://emtpystates.tumblr.com/
one of the links was wrong (it’s http://emptystates.tumblr.com/), I’ve updated Craig’s article now! Thanks for the feedback. Cheers, ML
Safari’s error message is very often wrong or incomplete,
Really interesting post, thanks. It’s surprising how much friendlier an application feels when you’re presented with an informative ’empty space’. It’s something I’m definitely going to add to my web applications.
That’s a pretty good post, cheers
This is indeed a nice article 🙂 I like the way notification copy was written which is really important for any one to understand what he is doing or missing either.
In Journalized, I didn’t want the users starting with a blank slate, not knowing what to put. I realised that in this situation, to get an entry made, they’d probably make one along the lines of ‘Downloaded Journalized for iPhone’, so I decided that when the app is downloaded, it should come with that entry. It gives everyone a nice starting point, rather than a set of instructions to follow.