Overview
How might we design processing time estimates so people can trust and act on AI output?
When this pattern fits
- Perfect for AI operations with variable processing times, image generation tools, and applications where wait time transparency improves user experience.
When to skip or lighten it
- Instant completions where estimates are noise.
- Tasks so unpredictable that any number would be dishonest (say “variable” and show progress instead).
- Background jobs already covered by notifications.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Exact clocks that constantly jump.
Underestimating so progress hits 99% forever.
No update when the plan adds long tool steps.
Hiding cancel while showing a long ETA.
How products use it
| Product | Implementation |
|---|---|
| Midjourney | Queue and render time expectations for images. |
| DALL·E / ChatGPT images | Wait states for image generations. |
| Adobe Firefly | Progress and timing cues for generative fills. |
| Claude | Long-run indicators for extended thinking or tools. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Processing Time Estimates" AI interface design pattern.
Pattern Definition:Frequently asked questions
How precise should ETAs be?
Use ranges (“about 30–60s”) and update on phase changes. Fake precision destroys trust.
ETA vs progress steps?
ETA answers “how long.” Progress steps answer “what is it doing.” Ship both for agent runs.
What if the estimate is wrong?
Recalculate openly when new work appears. Prefer honesty over a stuck percentage.
Should users be able to background the job?
Yes for multi-minute work, with a notification on completion.