View the original post
Summary: Empty states provide opportunities for designers to communicate system status, increase learnability of the system, and deliver direct pathways for key tasks. This article provides guidance for designing empty-state dialogues for content-less containers.
At times, users will encounter empty states within an application: containers, screens, or panels for which content does not yet exist or otherwise cannot be displayed.
Especially in complex applications that have not been fully configured by the user, empty states are quite common during onboarding and initial usage. Some typical scenarios when users might encounter empty states within an application are:
The default of an empty space is to simply remain empty: Display no content to the user until the space has been configured or personalized. While this approach may save development time (or even be an intentional decision during an early beta design of a product where other features must be initially prioritized), it ultimately creates confusion and decreases user confidence — and misses a goldmine of opportunities for increasing the usability and the learnability of the application, as well as the discoverability of key features.