Designing the Waiting Experience for Asynchronous AI Generation: From Spinners to Task-Based Design

Title

Designing the Waiting Experience for Asynchronous AI Generation: From Spinners to Task-Based Design

Meta Description

Burning Bridges Studio's founder shares wait design patterns for slow AI generation products: model work as durable tasks, be honest about duration, design for the second visit, auto-refund on failure, deliver downloadable files, and prevent duplicate charges on interrupted submissions—applicable to image upscaling, voice cloning, and all slow tasks.

Article Content

A photo goes in, a video comes out, and in between there's about ten minutes of blank space. Those ten minutes are often where AI products lose users. The founder of Burning Bridges Studio shares how they designed the wait as part of the product rather than a spinning loading icon. These patterns apply to any slow AI task—image upscaling, voice cloning, long-form writing—far beyond video generation.

Why Slow Tasks Need a Redesigned Wait

A ten-minute HTTP request is extremely fragile: proxy timeouts, phone sleep, closed tabs—users have no idea whether the task is still running. Burning Bridges Studio's approach is to model work as a persistent task record rather than a pending request.

type GenerationTask = {
  id: string;
  status: "queued" | "running" | "ready" | "failed";
  createdAt: string;
  updatedAt: string;
  outputUrl?: string; // only when ready
  errorCode?: string; // only when failed
};

This brings two immediate benefits: the UI can poll or subscribe to status instead of holding a long-lived connection; and after users close the tab, the task still belongs to the account rather than the page, so it can be recovered later. If the product charges per use, associate the task ID with the billing record—this foreign key makes refunds, customer support, and duplicate detection possible.

The key point is that a task record is a more reliable abstraction than a request. Requests break; tasks don't.

Idempotency means that performing an operation once produces the same result as performing it multiple times. In the polling scenario of slow AI tasks, idempotency means that every status query does not change the task state or trigger new generation, so the client can safely refresh at high frequency. Conversely, if refreshing the page creates a new task, it not only wastes compute resources but may also cause duplicate charges. Implementing idempotency usually requires the server to assign a unique ID to each task and design status queries as read-only operations; for submission requests, a client-generated idempotency key can identify duplicate submissions, ensuring the same request is processed only once.

Be Honest About Time: No Fake Progress Bars

Never show a fake percentage. A meaningless moving progress bar is worse than a plain explanation, because users plan around it.

More effective: state the expected duration in plain language ("about 10 minutes, possibly longer during peak times"); show the current stage rather than a number (queued, generating, completed); display the task's last update time so stalls are visible rather than mysterious; keep polling cheap and idempotent so refreshing never creates a second task.

The honest version sets a low expectation that is usually exceeded; the optimistic version sets a high expectation that is usually betrayed. This trade-off is especially critical in slow-task scenarios.

Polling vs. Subscription are two common patterns for clients to obtain asynchronous task status. Polling has the client actively query the server for task status at fixed intervals (e.g., every 5 seconds). It is simple to implement and broadly compatible, but generates many unnecessary requests and incurs latency. Subscription uses WebSocket, Server-Sent Events, or push notifications so the server proactively notifies the client when status changes. It offers high real-time responsiveness and few requests, but requires maintaining long-lived connections, which is not friendly to mobile and weak-network environments. The article's recommendation to "keep polling cheap and idempotent" accounts for the fact that slow tasks may last over ten minutes, long-lived connections are prone to breaking, and lightweight polling combined with task persistence provides a more robust experience. In practice, designs often use polling as the primary mechanism, supplemented by backoff strategies (gradually lengthening intervals) to balance real-time responsiveness and server load.

Design for the Second Visit

Most of those ten minutes happen off-screen. This is the norm, not an edge case.

The UI needs to answer: can users find the task from a list rather than a bookmark? Does the list show enough information to identify which photo was used? Can completed or failed tasks be deleted without contacting support? Does the empty state explain what will appear here?

The task list also naturally carries failure explanations. "Failed" with no reason is a support ticket; "Failed—credits refunded" is a resolved moment.

Regarding the failure contract, the original article gives three explicit rules:

• When a task fails, credits or quota are automatically refunded.
• The task remains visible with a clear reason rather than silently disappearing.
• Retrying creates a new task rather than modifying the failed task.

The third point matters for auditing. If a failed task can be edited into a successful one, you lose the record of what actually happened. Slow tasks have higher failure rates than fast ones because there are more moving parts and a longer window for things to go wrong, so the failure contract must be settled before launch.

Deliver Files, Not Walled Gardens

For any product with visible output, let users take the result with them. In Burning Bridges Studio's case, the result is a 15-second, 16:9 MP4 that users preview and then download. Preview before download matters: it lets people decide whether the result is worth keeping without leaving the product.

If the result can only be viewed in-app, you're competing with screenshots. A downloadable file is a small feature that changes how the product spreads.

Handling Interrupted Submissions

There's a tricky situation between "task created" and "response received": if the network drops after the server accepts the work, the client can't tell whether to retry. Two rules prevent double charging: give the client a short recovery window (the original uses 20 minutes) during which it can look up the existing task rather than resubmit; and explicitly tell users not to resubmit while recovery is running.

This requires tracking a small amount of state but avoids the most expensive support category: "I paid twice and only got one video."

Recovery Window is a short period after the client submits a task during which it waits for a response. If a network interruption prevents the client from receiving the "task created" confirmation, it can use the same request identifier (such as a client-generated UUID) to query the server for a corresponding task during the window instead of immediately resubmitting. This requires the server to record a mapping between each submission request's identifier and task ID, and to retain that mapping during the window. After the window expires, if confirmation still hasn't arrived, it can safely be treated as not created, allowing the user to resubmit. The length of the recovery window must balance user experience and resource usage: too short and it won't cover common network jitter; too long and users wait too much while the server retains more temporary state. The original uses 20 minutes, a product decision based on the average duration of video generation tasks and user patience.

Pre-Launch Checklist

Before launching a slow AI feature, confirm: work is stored as tasks with explicit states; expected duration is honestly stated; tasks survive page refreshes and can be found somewhere; failures automatically refund user credits or quota; results can be previewed and downloaded; interrupted submissions don't create duplicate charges.

None of this is novel. It's just easy to skip when a model demo succeeds once—and demos never wait ten minutes.

The original author discloses: he built Burning Bridges Studio, so he is describing his own product rather than providing an independent review. The ten minutes and 15 seconds in the article are estimates stated by the product, not measured benchmarks.

One-line Summary

Design the wait for slow AI tasks as part of the product experience, reducing user churn through persistent tasks, honest time communication, and failure contracts.

Paragraph Summary

The founder of Burning Bridges Studio shares how to design the waiting experience for AI video generation tasks that take about ten minutes. The core idea is to model work as persistent task records rather than long HTTP requests, so tasks belong to accounts, survive across pages, and support polling. Products should reject fake progress bars, honestly state expected duration and current stage, and set low expectations that will be exceeded. The failure contract must be settled before launch: automatic refunds, visible reasons retained, and retries creating new tasks to preserve audit records. Recovery windows and clear prompts prevent duplicate submissions and double charges caused by network interruptions. Make results previewable and downloadable to change how the product spreads. These patterns apply to any slow AI task.