Improve your design by using 🦴skeleton UI 🦴
I would be very suspicious if a fellow designer told me that she had no skeletons in the closet of her design files. I know this from my personal experience because I also take shortcuts from time to time. Sometimes we forget to arrange and group the layers of our design files or break an insignificant guideline with our fingers crossed that no-one will notice. These are not design-crimes but to become better at crafting beautiful and functional user interfaces, we must strive to improve our toolbox and skills. Skeletons may be a bad thing when pulled out of your closet, but if you take them out of your design toolbox and use them to enhance the users’ experience, they may have the exact opposite meaning. In this article, I want to share my thoughts about skeleton interfaces, when and how to use the paradigm, and pitfalls to be avoided when using it.
My first experience with a skeleton UI is from a few years ago when I still used the Facebook app on my phone regularly. Skeleton UI is the visual state of certain components, which belongs to a paradigm popular among front-end developers and known as optimistic UI. At first, it looked as if the app was there, under my fingertips but not really and that frustrated me. Then, within a few seconds, the real content appeared, I understood that this pattern is here to stay because my thoughts and feelings made a u-turn.
I had certainty and confidence about what would be revealed a few seconds later because the skeleton UI prepared me with some visual cues
Excellent UX is all about predictability and certainty that help the user feel in control of the situation. Skeleton UI creates a sense of expectancy because we usually see some parts of the app e.g. its main navigation while data for others is being loaded e.g. lists, tables, or feeds with images and posts. Furthermore, it has some specificity about the content it describes unlike a generic progress indication, which may give us an idea of how long we would have to wait but not really what we are waiting for. This brings me to a couple of pieces of advice on using skeleton UIs that I want to share with you.
Use skeleton UI when the layout and its elements are familiar, but data is not available at the moment e.g. it may need to be downloaded from the cloud.
Use skeleton UI for operations that will last a few seconds and when something is likely to take longer show a progress bar with an informative label.
These rules can be applied in many use cases and often with new ideas. We may lose track and instead of using them to improve a design or experience, we may find ourselves creating skeleton UIs for every screen. To avoid this, it is crucial to ask ourselves where do my users begin their experience with the product, which is the first screen they see, and under what circumstances it may take longer than a few seconds to load content. Then we should think about the components that are heavy consumers of data in our application, such as a feed with thousands of items, a data table, or a chart. UI elements meant to show a vast amount of data in a structured and easy to comprehend fashion to our users. In the Indigo.Design System that our team is evolving, we purposefully chose to provide skeleton variants in the UI Kit only for components that have the tendency to show big data sets. These include the various grids we have for showing data in a tabular fashion, the list items and lists, as well as the cards frequently used in a collection or to create feeds. Here I will promise that with the next release you will also get skeleton variants for the beautiful charts we have in it.
This brings us to more useful advice but before we jump to them let’s play a quick game. Which of the two screens below do you find to be more appropriate for using a skeleton UI and why?
I hope your answer is the one on the left because that is the correct answer and let’s elaborate on the reasons for this with two more pieces of advice I want to share before I wrap up.
Use skeleton UI for data-bound components such as tile layouts, lists, card collections, charts, data grids, and tables.
Use skeleton UI for areas in the user interface showing rich content and media, e.g. think of your feed on popular social media platforms.
While a list containing items with a consistent layout but different information is a good candidate, a simple data table with a couple of columns and a handful of rows to show my personal best achievements as a skier is not really the place where a skeleton visualization will add value. I think this example sheds more light and puts the paradigm in a better perspective given the 4 pieces of advice when considering ways to leverage skeleton UI in your designs.
When used consciously and with attention to the needs and behaviors of your users, skeleton UI are not just a force for the good, but may even be the thing that gives our users that wow factor. On the other hand, if we are intrigued by them just because everyone else is and neglect when and how they give value to people we risk falling into our own trap. So my request is let’s not create another monster like splash screens, unskippable onboarding processes, and things preventing our users from achieving their goals. Let’s be deliberate about design and use skeleton UI to make things better for our users!
This article appeared originally on Infragistics.com!
