The visual condition of an interface element or screen while data is being fetched or a process is running. Well-designed loading states provide honest feedback about what's happening — through a spinner, progress bar, skeleton screen, or animated placeholder — so users know the system is working and aren't left wondering if something has gone wrong.
Common contexts
- Designing a skeleton screen for a content feed that appears during initial page load to reduce perceived wait time
- Adding a progress indicator to a multi-file upload process so users know the operation hasn't stalled
- Documenting all loading state variants in a design system so engineers apply them consistently across components
Use when
Design loading states for every async operation that takes longer than 300ms — at that threshold, users begin questioning whether their action registered, and unaddressed uncertainty leads to repeated clicks and errors.
Avoid when
Don't show a loading spinner for near-instant operations under 100ms — flashing a spinner for a fast response makes the product feel slower than it is, creating a perception problem that didn't exist.
Perceived performance often matters more than actual performance — a skeleton screen that loads in 1.5 seconds feels faster than a blank screen that loads in 1 second.
Real-world examples
- Facebook introduced skeleton screens in 2017 to replace blank white loading states; perceived load time dropped by 15% in A/B tests because users saw structural progress rather than uncertainty.
- YouTube shows a thin red progress bar at the top of each page during navigation, a micro-interaction that eliminates user anxiety about whether a click registered during a slow load.
- Airbnb's search results use a card-by-card shimmer skeleton that populates progressively, letting users start scanning the first 3 results while remaining cards load — reducing abandonment on 3G connections.