Loading State UX: Share the Wait in Your Public SaaS Demo

To get useful feedback on loading state UX, show the wait in your public SaaS demo. Show what starts the request, what the interface says while work is pending, what the person can safely do next, and how completion appears.

Ask reviewers to explain that sequence before asking whether the spinner looks good. A polished recording can accidentally skip the part that needs review. The founder clicks a button, cuts the wait, and shows a finished report. Viewers see the result but have no way to judge whether the real interface would leave them wondering if the request worked.

The workflow below uses a fictional report-generation tool. It is a proposed review exercise for developers building in public, not a benchmark or a report of product testing. The aim is to make the pending experience inspectable without presenting simulated behavior as production performance.

Choose one request and name its states

Suppose a customer selects a date range and requests a report. Before recording anything, write down the states that actually exist in the implementation. A request might be accepted, wait in a queue, begin processing, and finish with a downloadable file. Those distinctions should come from the product's behavior.

If the system only knows that work is pending, don't add a “processing” label that suggests knowledge it does not have. If the frontend cannot tell whether the request was accepted, that uncertainty deserves attention before decorative animation.

For this hypothetical tool, assume the server supplies accepted, queued, running, and complete states. The developer can now ask whether the interface communicates those states accurately. That is a narrower and more useful question than whether the whole application feels fast.

Also identify the boundary with failure. This exercise concerns pending work. A failed request needs a separate response and recovery path. Don't leave an endless spinner in place simply because failure handling is outside today's recording.

Show what the first click actually means

Start the demo before the request. Include the selected date range and the button that begins report generation. The viewer needs enough context to know which job the pending message belongs to.

After the click, show an acknowledgment tied to that request. In the example, the interface could say that the report request was accepted and is waiting to start. Whether this exact wording is appropriate depends on what the backend can confirm.

Ask a reviewer what they think happened at that moment:

• Did the click save a request?
• Did it start downloading a file?
• Would they click again?

Their answer can reveal a mismatch between the system's state and the meaning the interface communicates.

This is also a good place to inspect repeated actions. If the button becomes unavailable, make its state understandable. If another request is allowed, explain whether it creates separate work. Don't rely on a recording cut to hide a duplicate action that a real person could attempt.

Make the wait honest and reproducible

For a controlled demo, a developer may use a test environment or a simulated delay. Label it clearly in the public update and on the recording when possible. “Controlled demo with a simulated wait” is different from evidence of normal production latency. Keep the chosen delay consistent between the versions you want peers to compare.

The purpose is to inspect the messages and actions during a wait, not to prove a speed improvement from two recordings made under unknown conditions.

A real recording has limits too. One successful request does not establish typical response time or reliability. If you are sharing an actual run, describe it as that run and keep performance claims separate from the review question.

Avoid fake progress percentages. A rising number may look reassuring, but it communicates measurement. If the system cannot estimate completion, show a truthful state instead. A queue position, estimated time, or progress bar also needs a sound basis before it belongs in the demo.

Review what remains possible while work is pending

A waiting screen needs a clear answer to “What can I do now?” In the fictional tool, perhaps the report continues if the customer visits another page, but stopping the browser session changes how they can find the result. The interface should reflect the actual behavior.

Write the expected action beside each state:

• Can the person change the requested dates?
• Leave the page?
• Cancel the job?
• Submit another report?

If an action is unsupported, don't suggest it in explanatory text just to make the screen feel more complete.

Record one safe action during the wait. For example, navigate to the report list and show that the pending job remains identifiable there. This gives peers an artifact they can inspect, rather than asking them to imagine what navigation might do.

If the current implementation requires staying on the page, be candid about that limitation. Then ask whether the message explains it clearly. A review can expose an awkward constraint without pretending the constraint has already been removed.

Check status messages beyond their visual appearance

The W3C explanation of status messages covers updates such as waiting, progress, results, and errors that appear without a change of context. It explains how relevant messages can be made available to assistive technology without moving focus.

That guidance makes a useful distinction for this demo: seeing a status update in a video does not establish that someone using a screen reader receives it appropriately. A visual recording cannot verify announcements, timing, or focus behavior by itself.

Keep an accessibility check alongside the public artifact. Inspect whether the pending and completion messages are exposed as intended, whether focus remains sensible, and whether updates become unnecessarily repetitive. Report only the checks you actually performed. This is a focused review, not a claim that the whole product meets an accessibility standard.

If the public demo omits keyboard or assistive-technology behavior, state that limit and leave the related question open for a suitable check.

Ask peers to describe the sequence

Post the demo with one concrete request: “After the report is accepted, what do you think is happening, and what would you do while waiting?” Add a second question only if it addresses a different uncertainty, such as finding the finished file after leaving the page.

Buildside is the founder-community context for this article. Its About page identifies Uriel Bitton as the builder and operator; that is the publisher relationship. Wherever the demo is shared, the request should give readers enough context to review the work without assuming they know the code.

Don't begin by teaching reviewers the intended answer. If the post explains every state before they watch, their response may reflect the explanation rather than the interface. Put essential demo limitations up front, then ask what the screen itself communicates.

A developer peer can inspect implementation choices. A prospective customer may be better placed to explain whether the waiting options fit their task. Keep those perspectives distinct in your notes.

Turn a response into a specific next check

Imagine a reviewer says they would press the button again because the first click seemed to do nothing. Record the point in the demo they mean. Check whether acknowledgment appeared, whether it named the request, and whether the button's state made sense. That observation does not automatically prove you need a different spinner. The cause could be missing acknowledgment, unclear wording, a stale screen, or a misunderstanding of the task. Change the part for which you have a reason, then show the same sequence again.

If another reviewer expects an email on completion, inspect whether the interface implied one. Don't add a promise of email delivery unless the product supports it. You can instead clarify where the report will appear and ask whether that fits the customer's workflow.

Publish the revised wait with its limits

The follow-up update should show the original question, the changed state, and the behavior you verified. A concise explanation might say that accepted requests now remain visible in the report list while work is pending. Keep the claim at that level. Clearer pending text is not evidence that customers will retain better or that reports finish faster.

A controlled demo can help people understand and critique the interaction; it cannot answer every question about production use. Save the demo conditions and reviewed version with your development notes. The next time report generation changes, you will have a concrete sequence to revisit: request, acknowledgment, waiting options, and completion. That makes public feedback part of maintaining the workflow, rather than a reaction to a spinner in isolation.

Hey I'm Uriel Bitton. I write 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
• Buildside: about the product and its builder