Everything you need to know about skeleton screens – UX Collective


This is actually really helpful information.

My take away is just keep page loads under a second instead. :slight_smile:

:microscope:Research summary (TL;DR)

  • Skeleton screens (as splash screens), when used to indicate that a screen is loading, are perceived as being shorter in duration when compared against a blank screen (our control) and a spinner — but not by much
  • Skeleton screens should not block gradual content loads (real content should replace skeleton objects immediately when the data is available). The vast majority of skeleton screens in use today are splash screens, and not skeleton screens in the original way described by Luke Wroblewski.
  • When designing skeleton screens, I recommend using motion to further decrease perceived duration time
  • Skeleton screens that leverage motion that moves from left to right (e.g. a wave or shimmer like animation, much like Facebook or Google uses) are perceived as shorter in duration than skeletons that pulse (opacity fading in and out)
  • Skeleton screens using motion that is slow and steady are perceived as shorter in duration than skeleton screens that use fast or rapid motion
  • The sample sizes in this study are too small to conclude anything definitively, but they do provide useful hints as to how we could design waiting experiences

Skeleton screens always annoy me, because they use these cute wireframe outlines of content and assets, and it makes me think the browser already loaded the data and is being blocked by a script from loading it correctly…

1 Like

This is one of those posts I really like. I, personally hate skeleton screens. However, someone else thinking “do these really help? lets test!” is encouraging to me. Like, across all UX/UI discussions.

1 Like

Yeah, it’s pretty cool they went for it. I was advising someone this morning, “talk to your users.” It’s hard to manage, but is invaluable for design.