Empty States, Skeletons, and Spinners: What Users Prefer

A product manager at a B2B SaaS company recently shared a telling observation: their team had spent three months perfecting their dashboard's data visualizations, only to discover that 40% of users never saw them load. The culprit wasn't performance issues or bugs—it was the generic spinning loader that appeared for 2-3 seconds while the system fetched data. Users, trained by years of encountering endless spinners, simply navigated away.

This scenario illustrates a fundamental tension in modern interface design. Every application has moments of waiting—data loading, processing requests, establishing connections. How we design these moments directly impacts user perception, task completion, and ultimately, product success. Yet most teams default to whatever loading pattern their framework provides without questioning whether it serves their users' needs.

The stakes are higher than many realize. Research from the Nielsen Norman Group indicates that users form lasting impressions of system responsiveness within the first few interactions. When those interactions involve poorly designed loading states, the damage compounds across every subsequent session. A study published in the International Journal of Human-Computer Studies found that perceived waiting time can differ from actual waiting time by as much as 36%, depending entirely on how the wait is presented.

The Psychology of Waiting

Understanding user preferences for loading patterns requires first understanding how people experience waiting in digital interfaces. The perception of time during a wait depends on several psychological factors that have little to do with actual duration.

Uncertainty amplifies perceived wait time dramatically. When users don't know how long a process will take or whether it's even working, anxiety increases and patience decreases. A 3-second wait with no feedback feels longer than a 5-second wait with clear progress indication. This explains why indeterminate spinners—those that simply rotate without indicating progress—consistently underperform in user satisfaction metrics.

The concept of "active waiting" versus "passive waiting" further shapes user experience. Active waiting occurs when users can see something happening—content gradually appearing, progress bars filling, skeleton screens revealing structure. Passive waiting leaves users staring at static indicators, wondering if the system has frozen. Research from the ACM Digital Library demonstrates that active waiting reduces perceived duration by 15-25% compared to passive waiting of identical length.

Context collapse presents another challenge. Users arrive at loading moments from different mental states and with different urgency levels. Someone checking a dashboard first thing Monday morning has different patience thresholds than someone frantically searching for data during a client call. Effective loading patterns acknowledge this variability rather than treating all waits identically.

Empty States: Setting Expectations

Empty states occupy a unique position in the loading pattern spectrum. They appear when no data exists yet—a new user's dashboard, a filtered view with no results, a feature awaiting first use. Unlike other loading patterns that indicate temporary waiting, empty states signal absence while simultaneously teaching users what will eventually appear.

The most effective empty states serve multiple functions simultaneously. They confirm the system is working correctly, explain why nothing appears, preview what will appear once data exists, and often provide clear paths to populate the space. A well-designed empty state transforms a potentially confusing moment into an onboarding opportunity.

User Intuition research across 1,200+ customer interviews reveals distinct patterns in how users interpret empty states. When empty states include visual previews of the interface structure—showing where charts, tables, or content blocks will appear—users report 34% higher confidence that they're in the right place compared to generic "no data" messages. This structural preview functions as a promise: "This is what you'll see once you add data."

The language of empty states matters more than most teams realize. Generic messages like "No data available" leave users wondering whether they've done something wrong, whether the feature is broken, or whether they lack necessary permissions. Specific, actionable messages like "Your dashboard will show customer trends once you connect your CRM" simultaneously explain, reassure, and guide.

Empty states fail most often when they appear in contexts where users expect data to exist. A filtered search returning zero results needs different treatment than a brand new feature. The former suggests overly restrictive filters or a search problem; the latter represents normal first-use experience. Conflating these scenarios with identical empty state designs creates unnecessary confusion.

Skeleton Screens: Maintaining Context

Skeleton screens emerged as a response to the limitations of traditional loading indicators. Rather than showing a spinner while content loads, skeleton screens display a simplified version of the final layout—gray boxes and lines approximating where text, images, and interface elements will appear. The approach gained mainstream adoption after Facebook and LinkedIn implemented it in their mobile applications.

The core advantage of skeleton screens lies in context preservation. Users see the structure of what's loading, maintaining spatial awareness and reducing cognitive disruption. A skeleton screen for a product listing page shows rectangular placeholders for product images, horizontal lines for titles and descriptions, and button shapes for actions. Users immediately understand what type of content is loading and where their attention should focus once it appears.

Research comparing skeleton screens to traditional spinners consistently shows measurable differences in user perception. A study from the University of California, Berkeley found that skeleton screens reduced perceived load time by 22% even when actual load time remained constant. More significantly, task abandonment rates dropped by 18% when skeleton screens replaced spinners for loads exceeding 2 seconds.

The effectiveness of skeleton screens depends heavily on accuracy. When the skeleton closely matches the final layout, users experience smooth cognitive transitions. When the skeleton bears little resemblance to what eventually loads—wrong number of items, different layout structure, mismatched proportions—users report feeling disoriented. This mismatch effect can actually increase perceived load time compared to simple spinners.

Implementation challenges explain why skeleton screens remain less common than their benefits suggest they should be. Creating accurate skeletons requires predicting layout before data arrives, handling variable content lengths, and maintaining multiple skeleton variations for different viewport sizes. Teams often underestimate this complexity, leading to skeleton screens that work perfectly in design mockups but break down with real-world data variability.

Skeleton screens perform particularly well in list and feed contexts—scenarios where users expect to scroll through multiple similar items. The repetitive skeleton pattern reinforces expectations about content structure while providing clear visual feedback that loading is progressing. Conversely, skeleton screens add less value for single-item views or complex visualizations where the final layout doesn't follow predictable patterns.

Spinners: The Default That Persists

Despite growing awareness of alternatives, spinners remain the most common loading indicator across digital products. Their persistence stems partly from convenience—every major framework includes spinner components—and partly from organizational inertia. Teams keep using spinners because they've always used spinners.

Spinners do offer legitimate advantages in specific contexts. For very short waits (under 1 second), spinners provide adequate feedback without the complexity of skeleton screens or the layout considerations of empty states. For unpredictable processes where the system genuinely doesn't know what content will return, spinners avoid the false promises that inaccurate skeletons create.

The problems with spinners emerge at longer durations and in repeated contexts. A spinner appearing for 5 seconds provides no information about progress, offers no assurance the system is working, and gives users nothing to focus on except their growing impatience. When users encounter the same spinner dozens of times per session, it becomes associated with waiting rather than working, subtly eroding confidence in system performance.

User Intuition data from enterprise software evaluations shows that spinners contribute to a phenomenon we term "perceived fragility." When applications rely heavily on spinners, users begin assuming the system is slow or unreliable, even when objective performance metrics are acceptable. This perception persists even after performance improvements, suggesting that spinner overuse creates lasting negative associations.

The indeterminate nature of most spinners compounds these issues. Users can't distinguish between a process that will complete in 2 seconds versus 20 seconds, leading to premature abandonment. Research from the Journal of Usability Studies found that adding simple progress indication to spinners—even rough estimates like "This usually takes 3-5 seconds"—reduced abandonment by 31% for processes exceeding 4 seconds.

Context-aware spinner implementation can mitigate some limitations. Using different spinner styles or accompanying text for different process types helps users build mental models of system behavior. A spinner with "Analyzing data..." text communicates differently than one with "Loading..." text, even though both indicate waiting. These small differentiations help users calibrate expectations based on task type.

What the Research Actually Shows

Comparing loading patterns requires moving beyond general preferences to examine performance across specific contexts and user segments. The "best" loading pattern varies dramatically based on wait duration, content type, user expertise, and task urgency.

For waits under 1 second, research consistently shows that any loading indicator creates more disruption than value. Users perceive sub-second transitions as instantaneous when no indicator appears. Adding spinners or skeletons for these brief moments actually slows perceived performance by drawing attention to the wait. The optimal pattern for very short loads is no pattern at all—just direct transition from one state to the next.

Between 1-3 seconds, skeleton screens demonstrate clear advantages over spinners in user satisfaction metrics. A comprehensive study by the Interaction Design Foundation tested both patterns across 2,400 participants and found that skeleton screens resulted in 28% higher satisfaction ratings and 19% lower abandonment rates. The effect was particularly pronounced for returning users who had developed expectations about content structure.

At durations exceeding 3 seconds, the picture becomes more nuanced. Skeleton screens maintain their advantage for structured, predictable content—lists, feeds, dashboards with consistent layouts. However, for complex visualizations or highly variable content, users report that skeleton screens can feel misleading. In these scenarios, spinners with clear progress indication and estimated time remaining outperform skeleton screens in trust metrics.

Content type significantly influences pattern effectiveness. E-commerce product listings, social media feeds, and data tables benefit strongly from skeleton screens because users have clear expectations about layout. Search results, complex forms, and unique content pages see smaller benefits or even negative impacts from skeleton screens that don't accurately predict final layout.

User expertise introduces another variable that most teams overlook. First-time users benefit more from skeleton screens because they're still forming mental models of the interface. Skeleton screens accelerate this model building by showing structure before content. Experienced users who already understand the layout gain less from skeleton screens and sometimes prefer minimal indicators that don't distract from their workflow.

Task urgency shapes patience thresholds and pattern preferences. Users performing time-sensitive tasks report higher frustration with all loading patterns but particularly with indeterminate spinners that provide no progress feedback. For urgent tasks, any loading pattern that offers progress indication—skeleton screens filling in, progress bars advancing, or even rough time estimates—outperforms generic spinners.

The Hybrid Approach

The most sophisticated implementations don't choose a single loading pattern but instead deploy different patterns based on context. This hybrid approach requires more upfront design work but delivers measurably better user experience across diverse scenarios.

Progressive loading represents one effective hybrid pattern. Initial content appears immediately using skeleton screens or partial data, while remaining content loads in the background. Users can begin interacting with available content rather than waiting for complete data sets. This approach works particularly well for dashboards, where top-level metrics might load instantly while detailed breakdowns populate gradually.

Adaptive loading patterns adjust based on detected connection speed or system performance. On fast connections, the system might skip loading indicators for operations that complete in under 1 second. On slower connections, the same operations trigger skeleton screens or progress indicators. This responsiveness prevents the jarring experience of loading indicators flashing briefly on fast connections while ensuring adequate feedback on slower ones.

Context-specific patterns acknowledge that different features warrant different loading treatments. A critical workflow step might use detailed progress indication with time estimates, while a supplementary feature uses simple spinners. This differentiation helps users understand relative importance and set appropriate expectations.

User Intuition analysis of high-performing SaaS applications reveals that successful hybrid approaches share common characteristics. They establish clear rules for when each pattern applies, they maintain consistency within feature areas even while varying across features, and they prioritize the patterns that matter most for core workflows while accepting simpler patterns for edge cases.

Implementation Considerations

Choosing loading patterns represents only half the challenge. Implementation quality determines whether theoretical advantages translate to actual user experience improvements.

Skeleton screen accuracy requires tight coordination between design and engineering. Designers must create skeletons that accommodate content variability—different text lengths, varying numbers of items, optional elements. Engineers must implement logic that selects appropriate skeleton variations based on expected content. This coordination often breaks down in practice, resulting in skeleton screens that work for demo data but fail with real-world variability.

Performance considerations sometimes conflict with pattern preferences. Skeleton screens require additional rendering before actual content appears, potentially adding overhead to the loading process. If implementing skeleton screens adds 200 milliseconds to load time, the perceived performance benefit may disappear. Successful implementations optimize skeleton rendering separately from content loading, ensuring the skeleton appears nearly instantly even while content fetches.

Accessibility requirements shape loading pattern implementation in ways that visual-first design often overlooks. Screen reader users need clear announcements when loading begins and ends, regardless of visual pattern. Skeleton screens that look smooth visually can create confusing experiences for screen readers if not properly announced. Spinners need appropriate ARIA labels that communicate both loading state and expected duration.

Animation quality significantly impacts user perception of loading patterns. Poorly implemented skeleton animations—ones that stutter, animate too quickly, or use jarring transitions—actually increase perceived load time compared to static indicators. Research from the Journal of Visual Communication suggests that smooth, consistent animations at 60fps reduce perceived wait time by 15-20% compared to choppy animations of identical duration.

Error handling represents a critical but often neglected aspect of loading pattern implementation. When loads fail, users need clear communication about what went wrong and what actions they can take. A skeleton screen that never resolves creates more confusion than a spinner with an error message. Effective implementations set maximum timeouts for all loading patterns, transitioning to explicit error states rather than leaving users in perpetual loading.

Measuring What Matters

Evaluating loading pattern effectiveness requires metrics that capture both objective performance and subjective experience. Many teams measure only technical load times while ignoring user perception and behavior.

Perceived performance metrics matter more than actual load times for user satisfaction. Tools like SpeedCurve and Lighthouse can measure when content becomes visible and interactive, but these technical metrics don't capture whether users feel the system is responsive. Combining technical metrics with user research provides a complete picture.

Task completion rates reveal how loading patterns impact user behavior. Comparing completion rates across different loading patterns for the same feature isolates the pattern's effect. A 12% difference in completion rates between skeleton screens and spinners, holding all other variables constant, provides clear evidence of pattern impact.

Time-on-page metrics can indicate whether loading patterns affect user engagement. If users spend significantly less time on pages with certain loading patterns, it suggests either faster task completion (positive) or increased abandonment (negative). Combining time metrics with completion rates disambiguates these interpretations.

User Intuition research methodology for evaluating loading patterns involves showing participants identical content with different loading treatments, then measuring both objective behaviors (task completion, time to completion, error rates) and subjective responses (perceived speed, confidence, frustration). This mixed-methods approach reveals patterns that purely quantitative or qualitative research might miss.

Longitudinal measurement captures how user perceptions evolve with repeated exposure. A loading pattern that delights on first use might become annoying after 100 exposures. Conversely, patterns that seem unremarkable initially might build trust over time through consistency. Measuring the same users across multiple sessions reveals these temporal dynamics.

Future Considerations

The landscape of loading patterns continues evolving as technology capabilities and user expectations shift. Several emerging trends warrant attention from teams making current implementation decisions.

Predictive preloading reduces the need for loading indicators by fetching content before users request it. Machine learning models can predict likely next actions based on usage patterns, loading content speculatively. When predictions are accurate, users experience instant transitions. When predictions miss, traditional loading patterns serve as fallbacks. This approach requires sophisticated infrastructure but delivers measurably better perceived performance.

Optimistic UI patterns assume operations will succeed and update interfaces immediately, rolling back only if operations fail. This inverts traditional loading patterns—instead of showing loading then success, optimistic UIs show success immediately then handle the rare failure cases. For operations with high success rates (>95%), optimistic UI dramatically improves perceived responsiveness.

Progressive web app capabilities enable more sophisticated caching strategies that reduce loading frequency. Service workers can cache skeleton screens, common content patterns, and frequently accessed data, making subsequent loads nearly instant. These capabilities blur the line between initial loads and cached loads, requiring new patterns that communicate data freshness rather than simple loading state.

The increasing sophistication of user expectations means that patterns that satisfied users five years ago may frustrate them today. Users now expect instant responsiveness across all digital products, making careful loading pattern selection increasingly important for competitive differentiation.

Practical Recommendations

Teams looking to improve their loading patterns should start with systematic evaluation of current implementations. Audit every loading state in your product, documenting which pattern appears, for how long, and in what contexts. This inventory reveals inconsistencies and identifies high-impact opportunities for improvement.

Prioritize loading patterns for your most frequent workflows first. A loading pattern that appears 50 times per user session warrants more attention than one appearing once per month. Calculate the cumulative time users spend waiting across all sessions to identify where pattern improvements will deliver the greatest aggregate benefit.

Test loading patterns with real users performing actual tasks rather than relying on internal opinions. What feels fast to your team—who knows exactly what will load—may feel slow to users encountering the interface for the first time. User research platforms like User Intuition enable rapid testing of different loading patterns with your actual customer base, providing evidence-based guidance for implementation decisions.

Implement progressive enhancement for loading patterns. Start with functional spinners that work everywhere, then layer in skeleton screens or more sophisticated patterns for contexts where they deliver clear value. This approach ensures acceptable experience across all scenarios while optimizing high-impact moments.

Document your loading pattern decisions and the reasoning behind them. As teams grow and change, this documentation prevents regression to default patterns and helps new team members understand the intentionality behind current implementations. Include specific metrics that justify pattern choices—"We use skeleton screens for the dashboard because testing showed 28% higher task completion versus spinners."

The difference between empty states, skeleton screens, and spinners extends far beyond visual aesthetics. These patterns shape how users perceive system performance, build mental models of your product, and ultimately decide whether to persist through challenging moments or abandon tasks. Teams that treat loading patterns as strategic design decisions rather than technical defaults create measurably better user experiences. The research is clear: the right loading pattern, implemented well, can transform waiting from frustration into confidence.