SaaS Loading States: Telling Users When Work Is Truly Complete

A useful SaaS loading state tells people what is happening, whether they can leave, and what they can do next. Success should only be shown when the promised result is ready. Accepting a request and finishing the work are different events. Consider a fictional app that imports a contact list. While the browser can finish uploading the file, the server may still be checking rows. A cheerful "Done" at that point would make the screen describe a result the app hasn't produced yet. Each stage the user waits for should have a plain label. For this import, those labels might be "Uploading file," "Checking rows," and "Adding contacts." The label should stay close to the action or result it describes. Percentages should only be shown when they represent measured work - for example, if 80 of 200 rows have been checked, that count can be reported. If a job is waiting to start, "Waiting to start" is more honest than a slowly moving bar. MDN's progressbar reference notes that an indeterminate progress bar has no current numeric value and recommends native HTML progress elements where suitable. The accessible value must match the progress that can actually be measured.

Defining What "Finished" Means

Before choosing an animation, write the success condition in a single sentence. For the import example: "The accepted contacts are saved and available in the contact list." This clarity guides the visual feedback and ensures the user understands what "finished" truly means.

When describing a partial result, show both counts and provide a way to inspect rejected rows. For instance, if 190 rows were added and 10 need changes, display both numbers and include an option to review the rejected entries. Labeling the entire job as successful would hide work the person still needs to do. Instead, treat related states separately in the product design:

• Waiting for work to begin
• Work in progress
• Finished with the full result
• Finished with items that need attention
• Failed, with a clear next action

These states vary by task - a payment, file upload, and report build each require their own distinct outcome description.

Safe Exit Decisions

Only say "You can close this page" if the job will continue and the user has a reliable way to find the result later. In the import example, this could be an import history page that shows the same job and its latest status. If closing the page cancels an upload, clarify that the upload is still running. Once the server has accepted the file and taken over the job, update the message to reflect that change. A reload should restore the actual state when the product supports background work. Replacing an active job with an empty screen provides no useful account of what happened.

Accessibility for Screen Readers

W3C's guidance on status messages covers changes such as waiting, progress, success, and errors that do not move focus. These messages must be available to assistive technology through appropriate roles or properties. Announce meaningful changes and test the result with a screen reader. Avoid moving keyboard focus merely to point at an ordinary progress update, and avoid turning every tiny progress change into a stream of announcements.

Handling Edge Cases

Test the following scenarios to ensure the UI tells the truth and offers a safe next step:

• A slow connection
• A failed request
• A reload during processing
• A job containing some invalid rows

Also check what happens when a user clicks again because the first click appeared to do nothing. For each case, verify that the screen accurately reflects the situation and suggests a safe action. If a retry could repeat completed work, fix that behavior before presenting retry as the solution. The final message should name the result explicitly, such as "190 contacts added. Review 10 rows." This lets the user know where the work stands and what remains.

Author: Uriel Bitton writes about building in public strategies and growing startups. Subscribe for more stories on growing your audience by building in public. Join us on Buildside: the social network for founders building in public.

Sources:

• W3C: Understanding Status Messages
• WCAG 2.2
• MDN: ARIA progressbar role