Use a progress bar when system progress is measurable; use a spinner for a short unknown wait, a skeleton for predictable pending content layout, and step navigation for user-driven task milestones.
Use a progress bar when system progress is measurable; use a spinner for a short unknown wait, a skeleton for predictable pending content layout, and step navigation for user-driven task milestones.
Practice the judgment: Imagine this situation: An upload bar reaches 100% while server scanning is still running, so users leave before the attachment is accepted. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Progress bar | Loading spinner | Loading skeleton | Step navigation / step indicator |
|---|---|---|---|---|
| UI or UX | UI + UX - Measurable system-operation progress indicator | UI + UX - Bounded indeterminate wait indicator for a named action or region | UI + UX - Bounded content loading placeholder | UI + UX - Linear multistep task progress indicator |
| UI guidance | Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages. | Render a compact spinner only beside, inside, or over the affected action, component, or page region, and pair it with concise text that names what is loading or processing. | Keep skeleton dimensions stable, mark the affected region busy, and use subtle or reduced-motion-respecting animation only while loading is unresolved. | Show a compact ordered list of named steps near the task heading, with visually distinct completed, current, upcoming, optional, and error states. |
| UX guidance | Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later. | Prevent duplicate or conflicting actions while the operation is in flight, but keep context, status, safe cancellation, and timeout recovery available when the wait exceeds the expected threshold. | Reduce uncertainty and layout shift while predictable content loads, then resolve clearly to real content, empty state, or error state. | Use step navigation to reduce uncertainty in long linear tasks by showing where users are, what is done, and what remains. |
| Good UI | A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable. | A Pay invoice button becomes Processing payment with a small spinner, disables only duplicate payment actions, and leaves the invoice reference visible. | The interface shows a clear action and state. | A five-step application shows Eligibility complete, Contact details current, Documents upcoming, Review upcoming, and Submit upcoming, with the current step emphasized and a matching page heading. |
| Bad UI | A progress bar reads 100% complete while virus scanning and server acceptance are still pending. | A search results panel shows skeleton rows, a spinner, and a progress bar for the same request. | Skeleton rows look like clickable report cards and receive focus before content exists. | All future steps look clickable and complete even though required earlier fields are blank. |
| Good UX | A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds. | After submit, users see payment PAY-2048 processing, can tell the button is temporarily unavailable, and then get either success or retry guidance. | Users see that reports are pending, then can switch the demo to loaded, empty, or error outcomes on a bounded path. | After a user enters valid contact details and continues, Contact details becomes complete and Documents becomes current. |
| Bad UX | Users leave after 100% transfer even though server processing later rejects the file. | The spinner blocks the whole workspace for a small table refresh and prevents users from continuing other work. | Large layout shift after content arrives. | The indicator says Step 4 of 5 while the page content and route still show Step 2. |
| Best fit | A system operation has a measurable total or bounded progress value. | The operation has defined resolution, timeout, cancellation, or failure paths. | The content shape is predictable. | A linear form, application, checkout, or setup flow has three or more meaningful steps. |
| Avoid when | The wait is short and only needs scoped activity feedback. | The content layout is predictable and a skeleton would better preserve structure. | A specific progress indicator or blocking message is required. | The journey has only one or two screens. |
| Required state | Idle state before the operation starts. | Inline processing state for a button or small local action. | Initial skeleton placeholder state with region marked busy. | Default state with completed, current, and upcoming steps. |
| Accessibility burden | Provide an accessible name that identifies the operation and affected object. | Give the spinner or affected region an accessible name that identifies the operation. | Mark the loading region busy or provide concise status text. | Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states. |
| Common misuse | Fabricating progress values just to make users feel movement. | Showing an unlabeled spinner on a blank page. | Showing skeletons forever. | Using a step indicator as breadcrumbs, tabs, side navigation, or pagination. |