Critique a design that shows a spinner for an unbounded amount of time.

A bare spinner says one thing, forever: "something is happening." It never says how much, how long, or whether it is still true. For fifteen seconds that is a fine thing to say. Past about ninety seconds it stops being reassurance and starts being a screen that looks exactly the same whether the job is nearly done or already dead.

How to answer this, stage by stage

Nobody is grading whether you know what a spinner is. They're grading whether you can name the exact moment a "still working" signal stops being believable, and fix that moment instead of just making the job faster.

Let's learn

What does a screen actually tell you when nothing on it has changed for ninety seconds?

Palimpsest is the AI document and PDF summarizer built into Greywolde Research, an advisory firm. Analysts upload a report, a filing, a diligence pack, and Palimpsest hands back a structured summary: key points, flagged risks, open questions, in about the time it takes to pour a coffee.

At first, almost every upload was a five to fifteen page memo. Palimpsest read it in one pass, no splitting required, and had a summary back in twelve to eighteen seconds. Nobody noticed the wait. You uploaded, you glanced away, it was done.

Then Greywolde's diligence team started uploading the real thing: eighty to a hundred and sixty page vendor packs, sometimes with scanned appendices bolted on. Typical time to a finished summary went from twelve seconds to somewhere between three and six minutes, depending on how busy the queue was.

Six minutes doesn't sound like a disaster next to a ten minute budget the team had set for "acceptable." Every dashboard said the product was healthy. Jobs completed per week kept climbing.

Here's the turn: the extra minutes were never really the problem. The problem is what a person does with a spinner that gives off exactly the same signal whether it's on chunk two of fourteen or stuck on chunk one forever.

The wait growing from twelve seconds to ninety does not feel proportionally worse. It feels fine, then it feels broken, with almost nothing in between.

Nothing told the backend to stop job A. It kept running, unseen, while job B started fresh on the exact same file.

At its worst, this trains an entire team to distrust a working feature, quietly, with no ticket ever landing to say so. And it isn't just a cost line. Two runs of the same document, sampled independently, do not always land on the same wording in the risk section. When both summaries showed up, Zara had no way to know which one to trust before a call, and once, the version she skimmed first was the one that hadn't caught a capped-indemnity clause the other version had flagged.

This is the whole answer to what an unbounded spinner gets wrong. Trust does not fade a little at a time as the wait grows. It holds, then it flips, at one point nobody had marked on purpose.

Before landing on real per-chunk progress, the team considered a cheaper fix first: a hard ninety-second timeout that showed an error and a retry button. It was rejected. A timeout kills jobs that are genuinely still working, just slow because the queue is backed up, and it moves the exact same duplicate-job problem onto a button the product itself is now telling people to press.

What I'd leave alone: the plain spinner on a one or two page memo. Those finish in well under fifteen seconds. Nobody watching one that short has time to doubt it, so building progress UI for it spends effort where trust was never actually at risk.

The lesson: a spinner isn't slow or fast. It's legible or it isn't. The wait can stay exactly as long as the job genuinely takes, and the product can still flip from feeling broken to feeling handled, purely from whether the screen shows any real sign of the work underneath it.

Now here is the same thing as a story

Read the short version above when you're in the room. Read this one when you want to feel why a healthy-looking usage chart can sit directly on top of a real, growing waste of money.

Zara Kildare spent four years as a research analyst before she became the PM who owns Palimpsest. Back then, handed a hundred page filing an hour before a client call, she could find the one liability clause that actually mattered in under three minutes, by eye, while everyone else in the room was still finding the table of contents. That instinct is why she was the obvious pick to own the tool built to do a version of that job automatically, and she still uses Palimpsest herself most mornings, partly because it's genuinely faster and partly because a PM who never opens her own product stops noticing what's actually true about it.

For months, Palimpsest was the easy part of her morning. Upload a memo, glance at her inbox, look back twelve seconds later to a finished summary. She never thought about the spinner. There was nothing to think about.

The trust didn't survive on patience alone. It survived on the wait staying short enough that patience was never actually tested.

Then the diligence team started uploading the real packs, and Zara, like everyone else, kept tapping upload without a second thought. Most of those still finished inside two or three minutes. Long enough to notice, short enough to wait out.

On a Wednesday, with a partner call in twenty minutes, she uploaded a hundred and forty-five page vendor pack with two flagged appendices. She opened her notes app to start prepping talking points and glanced back at ninety seconds. The spinner was exactly the same as it had been at second one. No percentage, no line of text, nothing. She'd never had a reason to count seconds against Palimpsest before, so she wasn't really counting now either, she just felt the specific wrongness of a screen that hadn't changed in a minute and a half.

She opened a new tab, found the same PDF in her downloads folder, and uploaded it again. Just in case the first one had died.

Both jobs finished, four minutes apart. Two summary cards sat in her workspace for the same file. She skimmed the first one, built her talking points around it, and walked into the call. It was only that evening, cleaning up her workspace, that she opened the second card and found a line the first one didn't have: a cap on the vendor's indemnification clause, flagged clearly, sitting in the summary she never read before the meeting.

Eight months earlier, in the frontend spec meeting for Palimpsest's very first version, an engineer had proposed showing which chunk was being summarized as it happened. It got cut. Exposing internal chunking felt like clutter on a clean screen, and back then almost every document was one chunk, done in under twenty seconds. Nobody in that room was thinking about a hundred and forty page filing. Nobody had reason to yet.

Zara didn't find the duplicate-job problem on a dashboard. She found it by living it, then went looking, and learned that thirty-four percent of large-document jobs across the whole diligence team had been quietly doubling up for weeks, with not one support ticket to show for it, because nothing about it looked like an error. It looked like people working.

Run the same Wednesday again, with one change: the moment she uploads, the spinner is replaced by a real line, "Summarizing section 4 of 14, about 2 minutes left," pulled from chunks actually finished on the backend. She keeps typing her notes. At the ninety second mark it reads section 9 of 14. She never opens a second tab. The job finishes in three minutes and forty seconds, one summary, indemnification cap flagged and sitting right there before the call starts.

One design made the wait look identical whether it was working or dead. The other lets you watch it move.

What I'd tell myself, back in that first spec meeting: cutting the progress line wasn't wrong for the product that existed that day. It was wrong for the product everyone already knew they wanted to build next. Ask how long the real jobs will take before deciding the wait never needs a signal, not how long today's demo document takes.

FLIPS, and the one letter that has no middle setting

Not a list of reasons spinners are annoying. FLIPS names the exact moment "still working" stopped being believable, and asks which old choice made that moment the only option on the table.

Five steps. Only the I step has no middle setting once the spinner ran past where a job would normally already be done.

Three things worth stating directly, since this is where the real judgment sits. The rejected alternative was a hard ninety-second timeout with a retry button: cheaper to build, and wrong, because it kills jobs that are genuinely still working during a busy queue, and hands the exact same duplicate-job problem to a button the product itself now tells people to press. The AI-specific failure worth naming is that two runs of the identical document are not guaranteed to produce the identical summary, since the model samples with real randomness and a duplicate job is a full second inference pass, not a cache hit, so the reduce step can word or even weight the risk section differently between two runs of one unchanged file. The guardrail is content-hash dedupe on upload: a second submission of the same file reattaches to the one canonical running job, or the one canonical finished result, instead of ever producing two outputs of the same input that can quietly disagree with each other. And the trade-off is real, not free: hashing uploads and streaming per-chunk progress cost engineering time a bare spinner never needed, accepted on purpose because duplicate waste on the most expensive class of jobs was running higher every week than the whole fix cost to build once.

And if you want to be sure it really works, try it somewhere else

Same five letters, an industry with no PDFs and no chunking at all, and this time the person doesn't work around the wait. She stops showing up for it.

Same unbounded spinner, same missing signal. One person routes around it. The other one stops showing up for the tool at all, which is worse.

Wrenholt Radiology Partners runs Corvei, an AI assistant that pre-reads chest and abdominal CT scans and drafts preliminary findings while the on-call radiologist works through the rest of the overnight queue. Dr. Frankie Herron covers ER overflow reads at Wrenholt from midnight to eight, and can spot a subtle bleed on a scan most residents would need a second look to catch.

The case for trusting it as built: a routine chest scan, a handful of slices, gets Corvei's draft back in five or six seconds. Frankie glances at it, agrees or flags it, and moves to the next case in the queue.

The case against it: a large, multi-phase abdominal study with hundreds of slices can genuinely take Corvei sixty to ninety seconds to process. The screen shows the same bare spinner either way. No slice count, no estimate, nothing.

Frankie didn't start duplicating requests, the way Zara did. She did something quieter and worse: on the busiest nights, when a scan sat spinning past the point where routine ones already had an answer, she stopped opening Corvei for that case at all and just read the raw images cold, the way she always used to. It cost her nothing to skip a tool that gave her no way to tell if it was still coming. Within a few months, her open rate on Corvei for the urgent, multi-phase reads, exactly the cases where a second read matters most, had fallen to about 40 percent, while her open rate on routine scans stayed near 95 percent.

The fix that reached her wasn't a faster model. It was Palimpsest's fix, run again: an expected-range indicator built from study type and slice count, "Large study, usually 60 to 90 seconds," plus a note past that range, "Still working, unusually large study," so a long wait and a dead one stopped looking identical. Her open rate on urgent multi-phase reads climbed back to 91 percent within six weeks, because the tool was finally telling her something true while it worked.

Same rank as before, different family: a silent wait doesn't just get worked around, it can train someone to quietly stop trusting the tool at all for exactly the cases where the second read was worth the most.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the fix: real progress plus a cancel button, no bare spinner past ten or fifteen seconds.
Cost: there's no engineering budget this quarter for full per-chunk streaming. Ship a rough time estimate alone first, "usually 3 to 5 minutes for a document this size," pulled from historical job data. Most of the trust-repair for a fraction of the build.
The model got better, for real: say inference gets twice as fast, so the worst case drops from six minutes to three. Still bound the spinner. Three minutes of nothing on screen still reads as broken to plenty of people. The threshold moves. The mechanism, no visible signal reads as no progress, doesn't disappear just because the model improved.

Where people run it wrong.
They measure total job time against a budget and call the product healthy, without ever separately measuring the duplicate-submission rate or the abandon rate on the waiting screen itself.
They "fix" the silence with a generic loading animation or a rotating tip, instead of a signal tied to real, actual progress, which buys a few extra seconds of patience and nothing more.
They bound every spinner in the product, including the ones that already finish in five seconds, and spend engineering effort where trust was never actually at risk.

How to use it live. Say the split out loud before answering: "is the wait actually too long, or does it just look identical to broken." Naming that split buys you a beat, and signals you won't reach for "make it faster" as the only lever in the room.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0