Summarize with AI
Good AI loading state design replaces the spinner with the real work: the steps the model is running, a live count, and a frame shaped like the result that fills in as each piece is ready. Any AI wait longer than about two seconds should show what is happening, and a generic label like Processing or Thinking is worse than nothing at all.
This matters because the wait is often the first thing a new user watches your product do. You built the pipeline, so you know what is behind the spinner. The person who just signed up does not, and to them half a minute of spinning looks like a product that froze.
Twenty-five seconds of Processing on a stack of 48 resumes
Picture an AI screening tool for in-house recruiters. A recruiter opens a role called Senior Backend Engineer. On the left are six criteria she set up earlier, such as Go or Rust in production and has led a migration. She drags 48 PDF resumes onto a panel that says Drop resumes here and clicks a green button labelled Screen candidates.
The panel goes grey. A spinner appears in the middle with one word under it: Processing. Nothing else moves for 25 seconds. Then the whole ranked list lands at once, 48 rows, each with a score out of 100 and three skill tags. The list is good. The top five are the people she would have picked by hand.
Now look at what she did during the wait. A few seconds in she clicked Screen candidates again, because nothing told her the first click had worked. Then she switched to her email tab. The list was ready long before she came back, and the second click had started a second full run of the same 48 resumes.
The redesigned version runs the same model at the same speed. The difference is what the panel says while it works. A short list of steps appears under the button, and each one ticks off when the backend finishes it:
- Reading 48 resumes. The count climbs as each file is parsed, and a file that fails shows its name in amber: alex_cv_final.pdf could not be read.
- Pulling out skills and experience, 31 of 48. This is the slow step, so it gets the live counter.
- Scoring against your 6 criteria. The six criteria names light up one by one.
- Ranking. The table below sorts itself, top score first.
Under the steps sits the shortlist table, already drawn before any data exists: column headers, a row height, a grey bar where the score will go and three grey chips where the tags will go. The first scored candidate fills the top row a few seconds in, long before the batch is done. The button now reads Screening 48 candidates and cannot be clicked twice.
Why Processing is worse than a blank screen
The standard advice on progress indicators says a looping animation is fine for waits of about 2 to 10 seconds, and that past 10 seconds you should switch to something that shows how far along the task is. That guidance, set out by Nielsen Norman Group, was written for software that fetches a page or saves a file. The user already knows what is happening. Only the timing is unknown.
An AI product breaks that assumption. The user does not know what the model is doing or whether 25 seconds is normal for this job. So Processing reassures nobody. It says the product has nothing to show, and it invites the two worst responses: a second click, or a new tab. Some designers will disagree, but for AI work the spinner limit should be two seconds, not ten.
The same research makes the case for doing it. In the study that article cites, people who saw a moving progress indicator were willing to wait about three times longer than people who saw none. That was a plain bar. A list of steps that names the work also teaches the user what the product does.
Honest steps versus theatre messages
The easy fix for a spinner is a rotating line of text. Warming up the model. Reading between the lines. Almost there. The lines change on a timer and none of them is connected to anything the backend does. This is theatre, and users catch it fast. The third time Almost there shows up and the result does not, the product has told them a small lie, and they discount every status message after it.
An honest step is tied to a real event. When the parser finishes a file, the count goes up. When scoring starts, that step lights up. The rule for the team is simple: if the system cannot report it, the screen cannot say it. That usually means one short engineering task: send a progress event from each stage of the pipeline. Founders skip it because it feels like plumbing. It is the whole design.
A frame shaped like the shortlist, and the first row early
A skeleton screen only helps when it has the shape of the real output. A generic block of grey lines tells the user something is coming. A table with the right columns, a score bar and tag chips tells her what is coming, so she can already decide where to look first. When the data arrives it lands in place, and nothing on the page jumps.
The bigger change is showing the first result as soon as it exists. Most AI features are built to finish the whole job and then render. But a batch of 48 resumes is 48 small jobs, and the first finished one is useful on its own. If the top row fills with a real candidate while the rest are still scoring, the recruiter is reading within seconds instead of waiting for all of them. The wait is the same length. She just spends it working.
This is not the same as streaming a chat reply word by word, which our post on streaming UI for LLM responses covers. Here the unit is a finished item, such as a scored candidate or a generated file. In our work on Dualite, an AI app builder, the build view says Generating, then lists each file with a check mark as it is written, and marks steps like yarn install as Completed.
What the founder hears, and what it costs
In this example the founder runs the demo himself. He drops in a sample batch, clicks Screen candidates, and while the spinner turns he explains the two-pass scoring model and how the evals were built. There is nothing on screen to point at. The head of talent he is pitching looks down at her phone somewhere in the middle of it.
The follow-up email is polite: the team likes the direction, and the product feels early. He forwards it to engineering with a request to make screening faster. They spend two sprints and shave a few seconds off. The session recordings still show new users clicking the button twice on their first batch, then leaving the tab. Nobody files a ticket about a loading state, so the fix keeps landing on the model.
The first cost is activation. Here a fair activation event is the first shortlist a recruiter acts on. A wait that sends her to another tab delays that moment, or loses it. Product-led SaaS benchmarks put activation at 20 to 40 percent for most products, and a ten point improvement typically drives a 15 to 25 percent increase in free-to-paid conversion. The first wait is one of the cheapest places to find those points.
The second cost is margin. Every double click on Screen candidates runs the full batch again, and you pay for both runs. AI product builders average around 52 percent gross margin against 70 to 80 percent for traditional software, because inference sits in cost of goods. A button that locks and a screen that shows progress stop paying twice for work nobody will read.
The third cost is the raise. The Series A bar for AI startups is now around 3.5 million in ARR, up from roughly one million three years earlier (Carta, Q1 2026). A demo that reads as early gets a come back later, not a no. And the founder never sees why, because he knows what happens behind the spinner. He is the one person who does not need to see the work.
Copy for each stage of the wait
Most of this is writing, not motion. The rules, in order:
- Name the object and the count. Reading 48 resumes, not Processing. Checking 6 criteria, not Analysing. The user should recognise their own input in the label.
- Use a plain verb in the present tense. Reading, Scoring, Ranking. Never a word about the model itself, such as Thinking or Reasoning, which describes the product instead of the job.
- Change the label only when the work changes. No timers, no rotating jokes. If a step takes long, add a counter to it instead of a new line of text.
- Lock the button and rename it. Screen candidates becomes Screening 48 candidates. That one change stops most double runs.
- Give a time estimate once the wait passes ten seconds, and base it on the batch size: Usually under a minute for 50 resumes.
- Offer an exit for long jobs. Past a minute, show Email me when it is done, and keep any finished results when the user comes back.
- Keep what finished if something fails. If resume 40 breaks the run, show the 39 scored candidates and one line about the file that failed. Our post on designing for AI errors covers the failure path in full.
To find where you need this, open your product as a new user, run the three things people do first, and time every wait. Any wait over two seconds with one word on screen goes on the list, and the longest one in the first session goes first.
When a spinner is still the right call
A spinner is not always wrong. Under about one second, show nothing at all, because a flash of animation is more distracting than the wait. Between one and two seconds, a small spinner inside the button that was pressed is enough. The user knows what they asked for, and the answer will be there before they wonder.
The spinner also fits a single call with no parts to report, such as rewriting one sentence. Do not invent steps to fill that space. That is theatre again. The test is whether the system has something true to say. If it does not, keep the wait short and the spinner small.
Agents that run for minutes, with approvals and pauses, are a different case, covered in our post on designing for AI agents. To hire this out, our ranking of design agencies for agentic UI patterns compares teams that design these states.
The wait only the builder never sits through
Studio Maydit is a product and web design studio for AI founders in the US, UK and Europe. Most of our product work sits in the first session: onboarding, the first run, and the waits where a new user decides whether the tool is working or stuck. Our fixed-scope projects take three to four weeks and end with a diagnosis of where the product is losing people. If your model is good and new users still leave during the first wait, book a 30-minute call with Studio Maydit.
