Explain the UX options available when a response will take 30 seconds.
Latency budgets and UX tradeoffs
A blank spinner for thirty seconds does not feel slow. It feels broken. And a person who thinks a tool is broken clicks it again, which is how one honest wait quietly becomes three.
The direct answer
Do not show one spinner for thirty seconds. Break the wait into real backend stages and tick each one only when that exact step finishes. Fill in whatever you already know, the headers and any pulled numbers, in the first two seconds, before the model has written a sentence. And let the person leave: a notify option instead of a screen that traps them. Set a hard timeout with an honest failure message, never a silent stall.
Do this, in order
Break the thirty seconds into real stages, tied to the actual pipeline, and only tick one when it truly finishes.Why: a person doesn't need speed, they need proof something is happening, and a fake stage that ticks on a timer breaks that proof the first time the real work runs long.
Fill in the skeleton immediately with whatever you already know, before the model writes a single sentence.Why: two seconds of real content beats thirty seconds of nothing, even if the hardest part isn't done yet.
Let the person leave and come back, with a notify option, instead of trapping them on a loading screen.Why: a person who can only stare at a spinner will refresh it or click it again, and every extra click is a second, full-price model call.
Set a hard timeout with an honest failure message and a real recovery path.Why: a stage that can silently hang for six minutes teaches people to stop trusting the wait entirely, even on the days it's working fine.
Hold back full token-by-token streaming until the source-check pass can run on a finished draft.Why: showing unchecked numbers arrive live trades a few felt seconds for a wrong figure a reader sees before anyone catches it.
Never show a percentage bar that isn't tied to real progress.Why: a bar that sits at forty percent for ten seconds then jumps to ninety in one looks broken even while it's working exactly as designed.
How to answer this, stage by stage
Nobody is grading whether you know what a spinner is. They're grading whether you know a thirty second wait is itself a design surface, not a gap between two real screens.
1
Ground it in one real product, not "an AI feature"
Say it like this
"Let's use Ledgerhill. It sits inside Kestrelbank Research's platform and drafts an earnings summary straight from a company's raw filing, the 10-Q or the 8-K, once it's filed. Reading the filing, pulling the numbers, and writing the draft takes about thirty seconds. Quintessa Waldstrom is the PM who owns it."
Why this works
A generic "when a response is slow" answer turns into a list of loading-icon trivia fast. One real feature with a real thirty seconds gives you an actual design problem to solve.
2
Name what a bad answer looks like, before giving the good one
Say it like this
"The easy answer is just show a spinner, and it's wrong. Thirty seconds is long enough that a person needs proof something is happening, not just a promise that it will eventually stop moving."
Why this works
Naming the lazy answer first shows you know the bar is higher than "add a loading icon," before you spend your real answer clearing it.
3
Lay out the UX options, not just the one you'd pick
Say it like this
"There are really four moves available here. One, stage the wait into real steps instead of one spinner. Two, show whatever you already know immediately, a skeleton, instead of a blank screen. Three, let the person leave and get notified instead of trapping them. Four, stream the actual output live as it's written. I'd use the first three together, and I'd hold the fourth one back, and I can say exactly why."
Why this works
The question asked for the options, plural. Naming all four before picking proves you actually surveyed the space instead of jumping to your favorite one.
4
Give the anchor, the actual design decision
Say it like this
"Break the thirty seconds into four real stages tied to Ledgerhill's own pipeline: reading the filing, pulling the segment numbers, drafting the narrative, checking every number against the source. Each one only ticks when that exact backend step finishes, never on a timer. At the same time, fill in the summary's headers, Revenue, Guidance, Segments, Risks, in the first two seconds, using the structured numbers Ledgerhill already pulled before the model writes one sentence of narrative. And add a notify toggle so the analyst can go start the next filing instead of watching this one."
Why this works
This is the actual answer to the question. Everything else in the walkthrough defends it.
5
Prove it with the failure, cut to four sentences
Say it like this
"Here's what happens without this. Ledgerhill launched with just a spinner for six weeks. Analysts, unsure if it was frozen, started re-clicking Draft or opening a second tab, and duplicate requests hit thirty four a week, each one a full model run billed again. Kestrelbank's model bill nearly tripled that month, and nothing about the model itself had gotten worse."
Why this works
Shows the real cost of an honest wait dressed up as a possible freeze, not just the mechanism behind fixing it.
6
Say what happens when the wait itself breaks
Say it like this
"The staged checklist has to survive its own failure too. If a filing's table won't extract cleanly, the pulling segment numbers stage would sit stuck forever with no signal, which is worse than a plain spinner because now it looks precise and broken at once. So it gets a forty five second timeout, an honest message, this filing's tables didn't extract cleanly, and a one-click way to start from last quarter's structure instead."
Why this works
Shows you're designing the wait to survive being wrong, not just describing it when everything goes right.
7
Close on the decision, not the story
Say it like this
"So: real stages tied to the real pipeline, a skeleton that fills in before the hard part finishes, a way to leave without losing your place, and an honest timeout instead of a silent stall. That's what a thirty second wait actually needs, not a nicer spinner."
Why this works
Ending on the method, not the anecdote, is what makes this sound like something you'd reuse for the next slow feature, not a story you told once.
Let's learn
Ledgerhill sits inside Kestrelbank Research's platform. A company files a 10-Q or an 8-K, and Ledgerhill reads it and drafts a plain-language earnings summary for the research desk, the kind an analyst used to write by hand after every filing.
Before Ledgerhill, a research associate read the whole filing, forty pages or more, pulled the revenue numbers by segment, compared this quarter's guidance wording to last quarter's, and wrote a three hundred word summary. About forty five minutes a company. On a heavy earnings morning, twelve to fourteen companies file before the market opens, more than one associate can cover by hand before the seven a.m. note goes out.
Knowledge spark: what actually takes thirty seconds?
Ledgerhill isn't one instant answer. It reads the filing, pulls the numbers a computer can extract directly, writes the narrative in full sentences, and then checks every number it wrote against where that number appears in the source. All four steps together land around thirty seconds. Skipping the last one would make it faster and far less safe to trust.
Ledgerhill's first version shipped with a single spinner, nothing else on the screen, for the first six weeks. Quintessa built it that way to hit the launch date before earnings season started, reasoning that everyone already knows what a spinner means.
A wait with nothing on it doesn't feel fast or slow. It feels broken, and a person who thinks something is broken clicks it again.
The turn is this: the mistake worth worrying about was never that Ledgerhill sometimes drafted a slightly wrong sentence. It was that thirty honest seconds, with no proof anything was happening, taught analysts to stop trusting the wait itself. During a busy earnings morning, they started re-clicking Draft, or opening a second tab and clicking it there too, just in case the first one had silently died.
Duplicate draft requests per week, before and after the staged wait shipped
Nothing about the model changed between the two weeks. Only the wait did. Every duplicate request was a full thirty second model run, billed twice for one summary.
At its worst, that cost showed up as a model bill that nearly tripled in month two, with finance asking what usage spike had caused it, when no such spike existed. Worse than the money: a support desk full of tickets calling Ledgerhill unreliable, when the drafts underneath were fine the whole time.
The choice that mattered
Shipping the bare spinner to hit the launch date, on the assumption that a universal loading icon needed no more explaining. It needed real stage information the whole time, and nobody built it until the bill made the gap impossible to ignore.
What I'd leave alone: a quick lookup, like fetching a single stock's current price, that returns in under two seconds, doesn't need any of this. There's nothing meaningfully to stage, and building a four step checklist for a wait nobody notices is effort spent solving a problem that was never there.
The lesson: a wait isn't neutral time. It's a screen with nothing honest on it, and a person will fill that gap with their own guess about what's wrong, usually by clicking again. Design the wait, or the person designs their own workaround for it.
Now here is the same thing as a story
Read the story below when you want to feel why a checklist that ticks in real time earns more trust than a spinner that just spins, not just be told that it does.
Quintessa Waldstrom had run product for Kestrelbank Research's editorial tools for four years, mostly the unglamorous plumbing behind the research platform, the kind of work analysts only notice when it breaks.
Ledgerhill was her biggest launch yet, timed to land right before earnings season. Two weeks out, in a review with engineering, someone asked what the loading state should look like. "A spinner," Quintessa said. "It's thirty seconds, that's normal, everyone knows what a spinner means." Someone half raised a hand about building real progress instead, and she said there wasn't time before the date, and the meeting moved on.
The first two weeks were quiet, and good. It was the slow part of the quarter, one or two filings a day, and Ledgerhill drafted each summary in about thirty seconds while the analyst got coffee or answered an email. Nobody complained. The spinner did its job because nobody was watching it closely enough to doubt it.
Then earnings season actually started. Twelve companies filed before the open on a single Tuesday. Analysts queued up filing after filing, watching the spinner spin on each one, and by the third or fourth filing of the morning, the waiting started to feel different. Someone clicked Draft a second time on a filing that seemed stuck. It wasn't stuck, it finished a second later, but now there were two drafts running for one filing. By the end of the week, that had become a habit across the desk: click, wait a beat, click again just in case.
The trigger wasn't a customer complaint. It was a finance ops email, three weeks into earnings season, flagging that Kestrelbank's model spend for the month was almost triple what the usage dashboard would have predicted, with no matching jump in the number of filings covered. Quintessa pulled the request logs herself. Same filing, same analyst, two or three requests inside ninety seconds of each other, over and over, all across the busiest mornings.
We didn't lose that money to a wrong number in a draft. We lost it to thirty honest seconds that looked exactly like nothing was happening.
The real cost wasn't the extra model spend by itself. It was that the support queue had filled with tickets calling Ledgerhill slow and unreliable, from analysts who had never actually seen it fail, only seen it think for thirty seconds with nothing to look at while it did.
The decision Quintessa would take back was that two-week-out meeting. Not choosing the spinner out of laziness, she chose it because the date was close and a spinner is what every app already has. It made sense in the room. It stopped making sense the first Tuesday twelve filings landed at once.
Run earnings season the old way again, and it repeats: a busy morning, a blank wait, duplicate clicks, a bill nobody can explain. Run it the new way: the checklist ticks through reading the filing, pulling the numbers, drafting the narrative, checking the numbers, each one lighting up only when that real step finishes, while the summary's headers fill in underneath within two seconds. An analyst can flip a notify toggle and go start the next filing instead of watching this one. Duplicate requests drop from thirty four a week to three. The support tickets calling it unreliable stop showing up, not because Ledgerhill got faster, but because the wait finally told the truth about what it was doing.
One design trusted that a spinner needs no explaining. The other trusted that thirty seconds of silence reads as broken no matter how good the spinner looks, and built the wait to say something true the entire time.
What I'd tell myself, back in that two-week-out meeting: "everyone knows what a spinner means" is true and useless at once. Everyone also knows what a stuck one looks like, and they can't tell the difference between the two until it's already cost you the trust.
SPARK, in one screen
Not a checklist to recite. Each letter has to survive the same busy Tuesday the story just walked through, twelve filings landing before the market opens.
SSituation. Who is this person, and how does the job get done today, without you?
Before Ledgerhill existed at all, a research associate at Kestrelbank read a filing by hand: forty pages, a highlighter, a legal pad, about forty five minutes per company, entirely on paper and in a browser tab, no AI draft anywhere in the loop.
Ground the anchor in the real workflow it eventually sits next to, or the design floats free of any actual person's morning.
The whole job, done by hand, before Ledgerhill or any wait design existed at all.
PPayoff. What habit do you want this to build?
Not "analysts feel less annoyed while waiting." Specifically: an analyst clicks Draft once, keeps working through the rest of the filing queue, and trusts that when Ledgerhill is ready, it will say so, instead of clicking again to check.
A named habit, click once and trust it, produces a specific wait design. A vague goal like "make the loading state nicer" produces nothing anyone can actually build on a Tuesday.
AAnchor. The one design decision everything else hangs on.
Break the thirty seconds into four stages tied to Ledgerhill's real pipeline, reading the filing, pulling segment numbers, drafting the narrative, checking every number against the source, and tick each one only when that exact backend step finishes. Fill the summary's headers with real pulled numbers in the first two seconds, before the narrative exists. Add a notify toggle so the analyst can leave.
This is the actual design decision. If it doesn't visibly survive the next letter, it's a slogan, not an anchor.
Five real stages, each tied to a real backend event, not a timer.
RRisk. What breaks the first time you're wrong?
A filing with a badly scanned segment table can fail the extraction step silently. Without a limit, the checklist would sit on pulling segment numbers forever with nothing wrong showing on screen, which is worse than a plain spinner because it now looks precise while being just as stuck.
A checklist that only works when the pipeline never fails isn't a design. It's the old spinner wearing a nicer coat.
The anchor is allowed to fail once, as long as it says so within forty five seconds instead of staying quiet for six minutes.
KKeep out. What do you deliberately not build?
No fake "thinking out loud" bubbles pretending to show live reasoning, Ledgerhill's draft is one batch call underneath, not a visible chain of thought, and a research desk that has to trust these numbers doesn't get a performance of thinking instead of the real thing. No token-by-token streaming on day one either. No more than one filing drafting at a time per analyst, until concurrent generation cost is proven safe.
A wait design that fakes more certainty than the system actually has doesn't build trust. It borrows it, and the bill comes due the first time someone checks.
Three things worth stating directly, since this is where the real judgment sits. The alternative Quintessa rejected was a percentage bar climbing from zero to a hundred. It lost because Ledgerhill's real time varies with how long the filing is, so the bar would sit near forty percent for ten seconds and then jump to ninety in one, looking broken even on a run that worked perfectly. The AI specific failure worth naming by name is a hallucinated number slipping into a draft a person trusts because it arrived looking finished. The guardrail is the fourth stage itself: every number in the draft carries a small source tag, page and paragraph, checked against the filing before the draft is ever shown, so a wrong figure is a five second click to catch, not a hidden guess dressed up as fact. And the quality, latency, and cost trade-off worth naming too: live token streaming would make the wait feel shorter, but the source-check pass needs the full draft before it can run, so Ledgerhill accepts a few more felt seconds of staged waiting to keep every number checked before an analyst ever reads one, rather than show unchecked text arriving live.
And if you want to be sure it really works, try it somewhere else
Same five letters, a pull request instead of a filing, and this time the person waiting is an engineer, not an analyst.
Deepscan is a code review assistant built by Roskilde Labs. It reads a pull request, traces how the changed code connects to the rest of the codebase, and drafts a written review. On a large diff, that takes about thirty seconds too. Ymke Quist is the engineer who led its wait design after a rough first launch.
S, situation: before Deepscan, a senior engineer reviewed a large pull request by hand, opening every changed file, checking who called each function, and writing comments, often twenty minutes for a diff touching a dozen files.
P, payoff: the habit worth building isn't "engineers feel patient while it loads." It's an engineer opening the pull request, seeing real progress immediately, and trusting that clicking away to answer a message won't lose their place.
A, anchor: stage the wait as cloning the branch, tracing the call graph, drafting the review, each ticking on a real event, and show a skeleton, files changed and lines touched, the moment the pull request opens, before the call graph trace even starts.
R, risk: a pull request touching a generated file with tens of thousands of lines can make the call graph trace run long past thirty seconds, and without a limit, that stage would sit lit but unmoving with no sense of whether it's working or stuck.
K, keep out: no live streaming of review comments as they're written, since a half-formed comment about code that turns out fine on the next line reads as a false flag; and no per-file progress bar, since file count doesn't track with how hard any one file is to trace.
The decision Ymke would take back
Deepscan's first version treated every pull request as roughly the same size for timeout purposes. A generated file with no real logic in it could stall the trace stage exactly like a genuinely huge diff would, with no way to tell the two apart from the screen alone.
Same anchor, a different desk. The filing's four stages become a pull request's four stages.
Same method, a different weak spot: Ledgerhill's slow stage is almost always the source-check, a fixed cost per number. Deepscan's slow stage is the call graph trace, which balloons on files that are large but not actually complex, so the timeout logic needed a size check the filing-based design never had to think about.
Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the anchor, real stages tied to the pipeline, a skeleton that fills in first, a notify option, and name the one number, duplicate requests fell from thirty four a week to three.
Cost: there's no engineering time this quarter for a fancy animated checklist. Build the plainest version, four lines of text that turn from grey to a checkmark, it costs almost nothing and it's the part that actually earns the trust.
The model got better, for real: say Ledgerhill's drafting step gets twice as fast next quarter. That's not a reason to drop the staged design. A fifteen second wait still benefits from an honest skeleton on screen, it just means the stages tick faster, not that the wait stops needing a body.
Where people run it wrong.
They build a progress bar with a percentage, which looks more precise than a staged checklist but lies harder the moment real time varies.
They stream raw model output live to feel fast, without checking it first, and a wrong number gets read before anyone catches it.
They set no timeout at all on the honest version, so a genuinely stuck stage just sits there forever, looking trustworthy right up until someone waits six minutes and gives up.
How to use it live. Name the real question before answering it: "is this asking me to make thirty seconds feel shorter, or to make it feel honest." Say that out loud, and it buys a beat while making clear you're not just going to suggest a nicer spinner.
Flashcards (tap any card to flip it)
1 · THE FRAMEWORK
What framework is this, and what's its one job?
Tap to flip
ANSWER
SPARK: design against the failure before you build. Here, that means designing the thirty second wait to survive the day the pipeline actually stalls, not just the days it works fine.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Quintessa Waldstrom, PM at Kestrelbank Research, owns Ledgerhill, an AI feature that drafts earnings summaries straight from a company's raw filing.
3 · THE HABIT
What habit did the redesign have to build in analysts?
Tap to flip
ANSWER
Click Draft once, keep working, and trust that Ledgerhill will say so when it's ready, instead of re-clicking or opening a second tab to check.
4 · THE ANCHOR
What's the one design decision the whole wait hangs on?
Tap to flip
ANSWER
Break the thirty seconds into four real stages that tick only on real backend events, and fill the summary's skeleton with real numbers in the first two seconds, before the narrative exists.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Shipping a bare spinner to hit the launch date, on the assumption that a universal loading icon needed no more explaining than that.
6 · THE NUMBER
Fill in the blank: duplicate draft requests fell from ___ a week to ___ a week after the staged wait shipped.
Tap to flip
ANSWER
Thirty four a week, down to three a week. Nothing about the model changed between those two weeks, only the wait did.
7 · THE REPLAY
Same busy Tuesday, new wait design, what changes?
Tap to flip
ANSWER
The checklist ticks through four real stages while the headers fill in within two seconds, an analyst flips notify and moves to the next filing, and duplicate requests fall from 34 a week to 3.
8 · CROSS-PRODUCT TRANSFER
Section 4 answers this same question again for a different product. Which product, and what's the shared anchor?
Tap to flip
ANSWER
Deepscan, a code review assistant at Roskilde Labs. Same anchor: real staged progress tied to the pipeline, plus a skeleton that fills in first, this time for a pull request instead of a filing.
Check yourself Score: 0 / 0
True or false
1. True or false: Ledgerhill's redesigned wait shows generation progress as a single percentage bar climbing steadily from zero to a hundred.
True
False
Show hint
Look at the alternative Quintessa considered and rejected, in the paragraph right after the K step.
Show answer
False. A percentage bar was the rejected alternative. Real generation time varies with filing length, so the bar would sit still for ten seconds and then jump, looking broken even while working correctly. Ledgerhill uses a four stage checklist tied to real backend events instead.
Multiple choice
2. A filing's segment table fails to extract cleanly, and the checklist's second stage can't finish. What should the design do?
A. Leave the stage showing as in progress indefinitely, since showing an error might worry the analyst.
B. Silently skip that stage and show the rest of the draft as if nothing happened.
C. Time it out at a fixed point, show an honest message naming what failed, and offer a real recovery path.
D. Restart the whole draft automatically without telling the analyst anything changed.
Show hint
Check the R step, and what the anchor has to survive the first time it's wrong.
Show answer
C. A staged wait that can silently hang is worse than a plain spinner, because it looks precise while being just as stuck. The design needs a timeout, an honest message, and a way to recover, like starting from last quarter's structure.
Fill in the blank
3. Ledgerhill's skeleton fills in the headers ___, ___, ___, and ___ using structured numbers pulled in the first two seconds, before the model writes any narrative.
Show hint
Look at the anchor step, right where the four checklist stages are named.
Show answer
Revenue, Guidance, Segments, and Risks. These come straight from numbers Ledgerhill already pulled during the second stage, before the narrative-writing stage has produced a single sentence.
Short answer, name the rejected alternative
4. What alternative did Quintessa reject for the thirty second wait, and why did it lose?
Show hint
Look at the paragraph right after the K step in the framework recap, where the three closing points are stated directly.
Show answer
Model answer: A percentage bar climbing from zero to a hundred. It lost because Ledgerhill's real generation time varies with how long the filing is, so the bar would sit near forty percent for ten seconds and then jump to ninety in one, looking broken even on a run that worked perfectly.
Multiple choice
5. Deepscan's first version could stall on a pull request touching a huge generated file with no real logic in it. What does that reveal?
A. Staged progress doesn't work for code review, only for text summaries.
B. A single timeout based on file count can't tell a genuinely complex diff from a large but simple one, so the timeout needs to account for size differently.
C. Deepscan should show a plain spinner instead, since staging didn't fully solve the problem.
D. The skeleton preview should be removed since it can't predict how long the trace will take.
Show hint
Read the key point block right under Deepscan's R and K steps, "the decision Ymke would take back."
Show answer
B. Treating every pull request as roughly the same size let a generated file with no real logic stall the trace stage exactly like a genuinely huge diff would, with no way to tell them apart from the screen.
Short answer, apply it yourself
6. Pick an AI product you use yourself that has a wait of ten seconds or more. What would you show during that wait, and why?
Show hint
Think about what the tool actually knows early versus late in its own process, and what it could show you before the final answer exists.
Show answer
Model answer: A photo app's AI background removal takes about twelve seconds on a large image. Instead of a spinner, it could show the image immediately with a rough, fast-guess outline of the subject, then sharpen that outline as the real model finishes, so something usable is on screen from the first second instead of only at the end.
Before you close the answer
Why this works
Tests whether you treat a long wait as a real design surface with its own failure modes, not a gap to paper over with a nicer icon. Most candidates name one loading pattern. Few design the wait to survive the day it stalls, and fewer still connect a bad wait to real wasted model spend.
Follow-up traps
"Why not just make it faster instead of designing around the wait?" Response: worth doing in parallel, but the source-check pass is a genuine cost, not a shortcut waiting to be found, so the wait needs its own design regardless of how much the thirty seconds eventually shrinks.
"Isn't a notify toggle just hiding the problem instead of fixing it?" Response: no, because the staged checklist and skeleton already make the wait honest for anyone watching it. Notify is for the person who has better use of the next thirty seconds than watching a truthful checklist finish.
If pressed
Ledgerhill's source-check stage matches each number in the drafted narrative against the exact page and paragraph it came from in the filing, and attaches that location as a clickable tag. A number with no match above a set confidence gets flagged in the draft itself, rather than shown as if it were checked and clean.
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
