Skeleton Screens Don't Always Win. The Data Will Surprise You.

Cover Image for Skeleton Screens Don't Always Win. The Data Will Surprise You.

Every modern product ships skeleton screens by default. The logic is so internalized that it rarely gets written down: skeleton screens make the interface feel like it's loading faster, they respect the user's time, they're more "modern" than a spinner. It's a solved problem.

Except it isn't. And the study that should have complicated the conversation has been mostly ignored.

What the Conventional Wisdom Says

The case for skeleton screens has a coherent perceptual argument behind it. Spinners provide no information — they just signal that something is happening and you should wait. Skeleton screens provide a structural preview — the page's approximate layout, suggesting the content exists and is coming. The theory is that this preview reduces perceived wait time and makes the experience feel more responsive.

Luke Wroblewski popularized skeleton screens in mobile design around 2013. The principle spread quickly: replace loading spinners with structural placeholders, reduce uncertainty, respect the user. The UX community absorbed it as best practice and stopped questioning it.

That's the problem. Best practices tend to become defaults before the evidence base catches up with the adoption rate.

What the Viget Study Actually Found

In 2017, Viget ran a controlled user study with 136 participants to compare skeleton screens, spinners, and a third condition (a custom branded animation). Participants were shown loading sequences and asked to estimate how long they waited, rate the experience, and complete a post-load task.

The results contradicted the conventional wisdom on every measured dimension:

Skeleton screen users estimated waiting longer than spinner users — not shorter. They rated the experience more negatively. They took more time to complete the post-load task.

Spinners, the supposedly outdated and inferior option, outperformed skeleton screens by the metrics that skeleton screens were specifically supposed to win on: perceived wait time and experience quality.

The Viget team's interpretation was careful — they weren't claiming spinners are always better. They were pointing out that the premise ("skeleton screens make loading feel faster") hadn't been validated, and their test suggested it might actually work in reverse.

The mechanism they proposed: spinners are familiar. Users have a well-established mental model for what a spinner means. Skeleton screens create a structural expectation — "the content is almost here" — and when that expectation isn't immediately confirmed, the gap between the skeleton and the actual content lands as a longer perceived wait rather than a shorter one.

The ACM Paper That Complicated It Further

A year later, the 2018 ACM ECCE paper on skeleton screen effects published results that partially contradicted Viget. In that study, skeleton screen users did rate perceived speed higher than spinner users — the skeleton screens worked as the theory predicted.

But the paper also found that spinners produced faster task completion on first visits. Users who had never seen the interface before moved through the post-load task more quickly after a spinner than after a skeleton screen.

The two studies together don't produce a clear winner. They produce a context-dependent answer:

Skeleton screens may score better on perceived speed for returning users who have an established mental model of what the actual content looks like. Spinners may perform better for first-time users who don't have that model yet.

Neither study is large enough to generalize from confidently. Both suggest the "skeleton screens always win" rule is wrong.

The Factors That Actually Determine Outcome

Extracting from both studies and the smaller body of related UX research, the variables that matter:

User familiarity with the interface. Returning users with a learned model of the content will find skeleton placeholders meaningful. First-time users may just experience the skeleton as a longer wait with more visual noise before the actual content.

Content type. Skeleton screens make most sense when the content has a predictable, stable structure — a feed, a card-based list, a profile page. When the content is variable or unpredictable, skeleton placeholders create false expectations.

How accurate the skeleton is. A skeleton that closely matches the actual loaded content works better than a generic one. Generic skeletons — gray rectangles that bear only approximate resemblance to real content — may produce the Viget result: creating a structural expectation that the content then fails to immediately confirm.

Load time. For very short loads (under 400ms), skeleton screens may actually be worse — the skeleton flashes in and out and produces a jarring transition. For longer loads, both approaches have a ceiling: at some point, the user perceives the wait as genuinely long regardless of what's animating.

The animation style. Animated shimmering skeletons may perform differently from static grey placeholders. The Viget study used a shimmer animation; the ACM study's conditions differed. This variable hasn't been fully isolated.

What You Should Actually Be Testing

The design industry skipped from "spinners are bad" to "skeleton screens are always better" without running the experiments in between. Most teams are now shipping skeleton screens as the default not because they've validated them for their product and their users, but because skeleton screens are what modern products do.

Calm UI isn't about aesthetic choices — it's about managing cognitive load. Loading states are a high-stakes cognitive load moment: the user is waiting, uncertain about whether something is broken, building or destroying trust with each second. Shipping the default because it looks right isn't the same as shipping what works.

What's worth actually testing:

A/B test for your returning versus new user segments separately. If the studies are right about familiarity being the variable, these two groups may behave differently with the same loading treatment.

Compare your skeleton accuracy. A generic grey placeholder versus a skeleton that closely mirrors your real content layout may produce measurably different results. If you're using a generic skeleton, you may be getting the worst of both worlds — the structural expectation without the accuracy that makes that expectation meaningful.

Test perceived time, not just task completion. Ask users directly after the load whether the wait felt long, short, or about what they expected. Task completion metrics miss a lot of the experience.

Test abandonment, not just perception. Perceived time is interesting. Whether the user actually waited is what matters commercially.

The Viget study is from 2017. The ACM paper is from 2018. There's been remarkably little rigorous follow-up. The design community adopted skeleton screens as best practice faster than the research could validate them, and the lack of ongoing testing means we're still mostly running on a claim that two contradictory studies left unresolved.

The question isn't "spinners or skeletons." The question is: have you actually run the test for your product, your users, and your content type? Or have you shipped the modern-looking default and called it UX?

Photo: Pixabay