| 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. | Render neutral skeleton blocks that reserve the final content structure without fake readable text, fake controls, or focusable placeholder elements. | 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. | Use a loading spinner for short indeterminate waits where the system is actively working but cannot yet expose progress; resolve it quickly to content, success, cancellation, progress, or error. | 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. | Three report-card placeholders match the final card heights and are replaced by real cards without shifting the panel. | 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 blue bar fills across the top of the page with no label, no percent, and no affected object. | A blank page shows a large spinner with no text, no affected object, and no idea what is loading. | Skeleton rows look like clickable report cards and receive focus before content exists. | A two-page form adds a large stepper that consumes space without explaining meaningful progress. |
| 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 | A fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option. | The spinner blocks the whole workspace for a small table refresh and prevents users from continuing other work. | Skeleton never resolves. | Clicking Review skips Documents, clears the contact form, and then blocks final submission without explaining the skipped prerequisite. |
| Best fit | A system operation has a measurable total or bounded progress value. | A short action, request, save, submit, refresh, sync, or fetch is actively processing and progress cannot be meaningfully measured. | The content shape is predictable. | A linear form, application, checkout, or setup flow has three or more meaningful steps. |
| Avoid when | Progress cannot be measured or would be guessed. | The content layout is predictable and a skeleton would better preserve structure. | The system cannot predict the content layout. | The journey has only one or two screens. |
| Required state | Idle state before the operation starts. | Idle state with no spinner and the action or region ready. | 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. |