What happens when the system is busy waiting for a response is an often overlooked aspect of user experience. This article tells you why it deserves more love, and how it might be the missing ingredient to make a truly brilliant user experience.

Loading states, as well as errors, are a design opportunity. This article will leave you with a framework for when to use which loading pattern.

Understanding the User Journey

Loading states do not exist in empty space; they are embedded into a chain of events.

This chart shows that different states that can exist before and after a loading state.

• Layout initialises: interface starts loading, yet there is nothing to display. In some cases, pre-loaded logos or spinners may appear at this stage
• Blank slate: some interfaces require user input before being able to display data, e.g., search terms. The term has become widely accepted in user experience and product design to describe a state where there is no or little data to display, and only parts of the interface may be present. To guide users, it makes sense to provide suggestions how to proceed.
• Loading: when the interface loads, you often will see nothing, or hopefully some type of indicator, a spinner, or skeleton. If this stage takes too long, users are likely to abandon.
• Data displayed: This is the happy path – interface and data are fully loaded and displayed.
• Empty state: the interface has been fully loaded, but there is no data to display. This can happen after a user interaction, or a page loads with preset filters, e.g., location. Guide users by offering possible next steps to resolve this state and continue with the main task. Remember that this is not an error, so consider the design and tone of voice when designing this state.
• Partial Failure: Parts of the interface could not be loaded for whichever reason. A partial recovery may be possible in this state.
• Network/Server Error: Depending on the type of failure, different recovery strategies are applicable. Client-side network errors need different communication to the user (“no internet…”) compared to server-side errors (“something went wrong on our side..”).

Understanding these states helps you choose loading patterns that smooth transitions and maintain user confidence during each phase. Let’s now look into some design patterns, and when to use them.

Theoretical Foundations

Instead of leaving users guessing about what the system is doing, loading states can significantly improve the experience. Consider these two key concepts:

A rule of thumb for reaction times includes three key thresholds: 0.2 seconds for immediate response, 1.0 second for uninterrupted user flow, and 10 seconds as the maximum timespan users can maintain focus on the task (Nielsen Norman). Design your loading states around these recommendations.

So the idea is to divide and conquer to reduce perceived waiting times and the cognitive load. Let’s examine now how we can achieve this.

Design Patterns

When the expected loading time is short

When to use

• the loading time is short (under a few seconds)
• the exact length of the loading time is indeterminate

More recommendations

As Luke Wroblewski explains, spinners can have negative side effects when loading states take too long. Users start “watching the clock tick”, worsening the perceived performance.

• update them after max. 20 seconds, e.g., add a label (“taking longer than usual…) (Baymard)
• choose the right animation speed – too slow worsens the perceived performance, too fast makes it seem too busy (You don’t need animations)
• not too fancy – use a familiar visualisation, make them easy to recognise

Spinners are also used by AI applications to indicate an ongoing “thought” process.

Some LLM interfaces use the typing fingers metaphor to simulate the ongoing thought and response process, again anthropomorphizing the interaction.

• the exact duration length of the response process is indeterminate
• however, this is a bit different, as we can start reading before the output has finished (no obstruction to the main task)

When loading visual content

Keep in mind that you do not have to use spinners – in fact, they can become a bit tiring if overused. There are alternatives, like in these examples: Instagram displays a simple gradient preview of the image loading, whereas Pinterest uses coloured rectangles during lazy loading.

When to use

• the loading time is short (under a few seconds)
• the exact length of the loading time is indeterminate
• the content is visual

When the expected loading time is longer than a few seconds

Whereas you can use spinners even for longer loading times with some caveats as mentioned above, consider more advanced options like the skeleton.

The term skeleton was first mentioned by Luke Wroblewski in his blog post from 2013. They have gained widespread acceptance as a UX pattern for loading states. On of the reasons for their popularity is their flexibility. Check out these wireframe examples below:

Research provides valuable insights for the design of skeleton states, as they can be tricky to implement, and eventually even worsen the experience.

When to use

• the loading time is a bit longer (more than a few seconds)
• the exact length of the loading time is indeterminate
• Use for content- and image-heavy pages with lists or grids of items

Recommendations for skeletons

• Animations can positively influence perceived loading times. Research has shown that left-to-right animations perform better than others (UX Collective).

Best practice: Meetup employs a multi-tier startup sequence, where a mix of patterns indicate its various loading states during startup. After displaying an initial logo, the app shows its native controls at the top and bottom, whereas the content area is an animated skeleton. Once prioritised data like event titles and descriptions load, it is replaced by an advanced skeleton view. In this stage, users can already interact with the app, as the missing information is not that important.

Best practice: Perplexity is also using a multi-tier approach to visualise its thought and response process. Note the combination of a tiny spinner, a skeleton, and the animated text fading in like a curtain.

Typing animations are typically used by LLM’s to visualise a typing process, thus giving us the impression of someone actually talking to us. It serves two purposes:

• anthropomorphisation
• reducing subjective waiting time

Progress Bars

With analogue roots still in the 19th century, progress bars are digital offspring of Gantt charts. In 1985, grad student Brad Myers presented his research about digital progress bars where 86% of participants stated that they liked the progress bars. They have popularized, and come in various shapes since, but the horizontal form remains the most common. Its success can be attributed to the historical roots, and the similarity to a thermometer, as also stated by Myers.

They can be used to indicate progress in two situations: where users actively step through a process (e.g., wizards or assistants), or when waiting passively for a system response to complete. We will look at the latter.

In a 2022 study, Wang et al found that animation speed has a profound impact on the perception of duration. They tested three scenarios with determinate progress bar animations with 40 subjects each.

• constant speed
• slow-to-fast (accelerating)
• fast-to-slow (decelerating)

They determined that the slow-to-fast version was perceived to be shortest, followed by the constant rate progress bar. The version with the animation slowing down was perceived the longest.

When to use

• the loading time is longer (more than 10 seconds)
• the exact length of the loading time is determinate
• use a familiar visual metaphor to ensure quick recognition

More recommendations for progress bars

User research has shown that the design of progress bars can influence the user’s perception of duration. Research shows that fast-to-slow progress bars can reduce perceived duration by up to 11% and lower abandonment rates (Magic of Slow-to-Fast or Constant).

• avoid jumps, or freezes in the progress, as it undermines user trust
• use fast-to-slow progress
• use circular design when space constraints apply, or when an indeterminate spinner turns into a determinate progress circle

Accessibility considerations

Loading and waiting indicators make heave use of static or animated visuals. This leads to the question whether all of these states are accessible. Let’s review a few of the most important considerations:

Screen Reader Support

• Use aria-live=”polite” or aria-live=”assertive” regions to announce loading status changes
• Provide meaningful text alternatives like “Content is loading” rather than just visual indicators
• Announce completion: “Content has loaded” or “Search results: 15 items found”

ARIA Labels and Roles

• role=”progressbar” for progress indicators with aria-valuenow, aria-valuemin, and aria-valuemax
• aria-label or aria-labelledby to describe what’s loading (“Loading search results”)
• aria-busy=”true” on containers while content loads

Motion and Animation

• Respect prefers-reduced-motion settings – provide static alternatives to spinning/pulsing animations
• Avoid rapid flashing that could trigger seizures (< 3 flashes per second)
• Consider users with vestibular disorders who may be sensitive to motion

Keyboard Navigation

• Ensure focus management during loading – don’t trap focus on loading elements
• Provide “Skip loading” or “Cancel” options where appropriate
• Maintain logical tab order when content appears

Timing Considerations

• Don’t rely solely on visual cues for timeout warnings
• Provide audio alerts or text announcements for important timing information
• Allow users to extend timeouts when possible

Skeleton Screens

• Use proper heading structure (h1, h2, etc.) in skeleton placeholders
• Ensure skeleton elements aren’t focusable or announced as interactive

Conclusion and Takeaways

Loading states represent one of the most underutilized opportunities in interface design. Rather than treating them as technical afterthoughts, the research demonstrates that thoughtful loading patterns can fundamentally alter user perception and behavior. Wang et al.’s findings on animation speed, combined with decades of research on cognitive load and perceived performance, provide a clear foundation for strategic decision-making.

A Framework for Loading Pattern Selection

• Immediate feedback (< 2 seconds): Use spinners for indeterminate processes, progressive loading for visual content. The goal is acknowledgment rather than entertainment—users need confirmation that their action registered, not elaborate animations that may actually worsen perceived performance.
• Short waits (2-10 seconds): Skeleton screens shine here, particularly for content-heavy interfaces. Luke Wroblewski’s research shows these reduce cognitive load by previewing structure, while the left-to-right animation studies confirm that directional movement improves perceived speed. This is where you can meaningfully reduce abandonment rates.
• Extended processes (> 10 seconds): Progress bars become essential, with the slow-to-fast animation pattern reducing perceived duration by up to 11%. The historical familiarity with thermometer-like progress indicators makes them immediately recognizable and trustworthy.

Implementation Strategy

Teams should approach loading states systematically rather than pattern by pattern. Consider the user’s mental model: are they waiting for a single result or browsing through content? Is the process time predictable or variable? The most effective implementations, like Meetup’s multi-tier startup sequence, combine patterns strategically rather than relying on a single approach.

Accessibility isn’t optional—it’s integral to effective loading states. Screen readers need meaningful announcements, progress indicators require proper ARIA labels, and motion-sensitive users need static alternatives. These considerations improve the experience for everyone, not just users with specific needs.

Thoughts Beyond

Loading states ultimately serve user confidence. They communicate system reliability, set appropriate expectations, and maintain engagement during necessary delays. The research consistently shows that uncertainty breeds abandonment more than actual wait time. Your loading patterns should answer three questions:

• Is something happening?
• What’s happening?
• How much longer?

This foundation enables more complex scenarios. While this article covers the fundamentals of loading patterns, real-world interfaces rarely follow the happy path consistently. Partial failures, network inconsistencies, and mixed content types require more nuanced approaches—territory we’ll explore in the next piece on progressive UI failure states.

The evidence is clear: loading states aren’t just functional necessities but active components of user experience. Implement them with the same strategic consideration you’d apply to any critical interface element, because that’s exactly what they are.