The invision blog has a thought provoking post on ‘Why Empty States Deserve More Design Time’. The ’empty state’ is the time, usually when the app is first used, when the user or app hasn’t done anything yet and the UI has no content yet.
As the Dina Chaiffetz says in the blog, the empty state is often the first impression the user has of an app. First impressions can weigh heavily in the users’ decision to re-use or abandon an app. Dina suggests it’s an opportunity to educate, delight or prompt the user.
How do you implement these things? In the past I have worked on apps that have done one of three things…
1) Totally change the screen layout for the ’empty’ case. This can subsequently confuse some users’ concept of the normal navigation flow if not done well. Designs, re-designs and app state changes (e.g. going back to empty) tend to get overly complicated.
2) Use a ‘dummy’ element (e.g. dummy list item) loaded when the app very first starts. While this is the easy way, it can complicate subsequent coding that always has to cater for the dummy element – unless it is deleted once there is real data.
3) Use an OS provided mechanism. There’s sometimes a ‘show this text when empty’ or ‘show this view when empty’ API for a view that keeps the screen layout but automatically provides the temporary information. This is usually the best approach.
As Dina says, the ’empty state’ is often an afterthought. I find it’s always the rushed part of a project, is usually something people can’t agree on and often needs to be re-worked several times. Hence, consider it early if you can, so as to avoid problems late on in the project.