Explain when to move work to the background and notify the user later.
Latency budgets and UX tradeoffs
A blocking wait that outlives someone's patience does not feel slow. It feels broken, and the workaround a person invents to cope with that feeling can end up teaching your own fraud model the wrong lesson.
The direct answer
Move a step to the background and notify the person later only when it depends on a system outside your own control, or when that step's own measured p95 time crosses about forty five seconds, whichever trips first. Below that line, and fully inside your own systems, keep it blocking: the person is about to move to their next task within a minute anyway, and a notify-later ping only costs them a switch they did not need. Give every blocking wait its own escape hatch too, so one that quietly runs long can turn into a background job with one click, instead of trapping the person watching it.
Do this, in order
Background a step only when it depends on a system you do not control, or its own measured p95 crosses about forty five seconds.Why: below that line the person is opening their next task within a minute anyway, so blocking costs them nothing extra.
Measure p95 per step, never the average, before setting any threshold.Why: a friendly-looking average hides the one call in twenty that runs four minutes, and that is the exact call that breaks someone's trust.
Give every blocking wait an escape hatch that fires once it overruns its own threshold.Why: a threshold that is right ninety five times out of a hundred still fails the other five, and a locked screen with no way out is worse than the wait itself.
Keep the fast, fully internal path blocking, on purpose.Why: routing an eight second lookup through a notify-later flow adds a check-the-bell step nobody asked for.
Send the notification to the place the person already watches, not a new one.Why: a notify system nobody checks is just a slower, quieter way of losing the claim entirely.
Leave the threshold itself alone until real volume proves it wrong.Why: guessing a stricter number before the data exists just moves the guessing somewhere harder to catch.
How to answer this, stage by stage
Nobody is grading whether you know what a notification badge is. They are grading whether you can turn "when should this go to the background" into an actual rule instead of a gut feeling about what counts as too long.
1
Scope it to one real product and a real pair of tasks
Say it like this
"Let's use Claimwright. It sits inside Northmere Mutual's claims system and reads whatever a policyholder submits, photos of the damage, a repair estimate, a medical bill, and pulls out the claim number, the VIN, and the line items, then checks them against the policy and a fraud pattern. Some of that finishes in under ten seconds. Some of it takes over a minute. Solvej Halstrand is the PM who owns it."
Why this works
A generic "when should something run in the background" answer turns into loading-icon trivia fast. One real feature with two genuinely different speeds gives you an actual decision to design, not a preference to state.
2
Name what a bad answer looks like, before giving the good one
Say it like this
"The easy answer is background anything past some fixed number, like ten seconds, and it's wrong. A fast, fully internal lookup that just happens to take twelve seconds does not need a notify-later flow. It needs the person to wait three more seconds and move on."
Why this works
Naming the lazy fixed-number answer first shows you know the real question is not "how long is too long," it's "what kind of wait is this."
3
Lay out the two things that actually decide it
Say it like this
"There are really two questions worth asking about any step. One, does it depend on something outside your own systems, a vendor, a third party check, something you cannot bound yourself. Two, what does that step's own p95 actually run, not the average, the ninety fifth percentile, the one call in twenty. If either answer says it's out of your hands or past about forty five seconds, background it. If both answers say fast and fully yours, block."
Why this works
The question asked for the "when," not a single rule of thumb. Naming both dimensions before picking a cutoff proves you separated the two things people usually mix together: how long a step takes, and who controls how long it takes.
4
Give the anchor, the actual design decision
Say it like this
"Route every Claimwright step through those two checks before it starts. A single estimate photo, claim number, VIN, line items, stays inside our own OCR model, p95 under eleven seconds, so it blocks. The parts-pricing consortium check calls a vendor we do not control, and a full medical file review can run past a minute once a claim has thirty or forty pages. Both of those go to the background the moment they start, with the claim folder showing 'checking now' and a notify badge that lights up the second it's done, so Solvej's adjusters can open the next claim instead of watching this one finish."
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. Before the redesign, every step blocked, no matter who controlled it. When the consortium check ran long during a vendor slowdown, adjusters started re-clicking the claim to see if it had frozen, which fired a second consortium lookup for the same claim. That looked, to the fraud model, exactly like someone resubmitting a claim twice on purpose, and nine real claims a month got flagged as possible duplicates, each one waiting four extra days for a payout that was never actually in question."
Why this works
Shows the real cost landed on a customer's payout, not just on a server bill, which is the part interviewers remember.
6
Say what happens when the anchor itself is wrong
Say it like this
"The forty five second cutoff has to survive being wrong too. If the consortium goes down hard and a call that usually finishes in twenty seconds is still running at sixty, the claim doesn't just sit there. Past its own threshold, it flips itself to background automatically and tells the adjuster, still checking, we'll notify you, instead of leaving a spinner running with no way out."
Why this works
Shows you're designing the rule to survive the day it's wrong, not just describing the day everything goes to plan.
7
Close on the decision, not the story
Say it like this
"So: background it when it's outside your control or past its own measured forty five second p95, keep it blocking when it's fast and fully yours, and give every blocking wait an escape hatch for the day it runs long anyway. That's the actual rule, not a fixed number picked because it sounded reasonable."
Why this works
Ending on the rule, not the anecdote, is what makes this reusable for the next slow feature instead of a story you told once.
Let's learn
Claimwright sits inside Northmere Mutual's claims system. A policyholder submits photos of the damage, a repair estimate, sometimes a police report or a stack of medical bills, and Claimwright reads all of it, pulls out the claim number, the VIN, the itemized costs, and checks them against the policy and a fraud pattern.
Before Claimwright, an adjuster opened each document by hand: read the estimate, typed the VIN into a lookup tool, called around for a parts price if one looked off, and wrote up the check herself. About twenty five minutes a claim. On a heavy Monday, thirty or more claims land per adjuster, more than one person can get through by hand before the day is over.
Knowledge spark: what is a p95?
Line up every time a step has run this month, fastest to slowest. The one in the ninety fifth spot out of a hundred is the p95. It is not the normal case, it is the slow case worth designing for, because that is the one that actually traps someone.
Claimwright reads the same documents in seconds to a couple of minutes. A single repair estimate, claim number, VIN, line items, finishes in under eleven seconds nearly every time. A claim that needs the parts-pricing consortium checked, or a full medical file read page by page, can run past a minute, sometimes two.
The mistake worth worrying about was never that the slow claims took a minute instead of ten seconds. It was that every one of those minutes looked exactly like nothing on screen, so adjusters filled the silence with their own guess: click it again, just in case.
We did not just pay for the same lookup twice. We taught the fraud model that our own impatience looked like a customer gaming the system.
Claimwright step time, p50 vs p95, by step type
p50, typical runp95, the slow one in twentythe background cutoff
Only OCR extraction stays under the cutoff on its own p95. The consortium check crosses it on p50 already. Ownership decides the medical review even though its p50 sits close to the line.
At its worst, that re-clicking habit turned nine real claims a month into false duplicate-submission flags, each one held for a human fraud reviewer to clear, adding an average four days to a payout that was never actually in question. Northmere's claims satisfaction score dropped hardest in exactly the accounts where nothing had gone wrong with the claim itself.
The audit that found the pattern nobody had gone looking for.
Duplicate re-check requests per week, before and after the redesign shipped
Before, everything blockedAfter, background plus notify
Nothing about the consortium vendor changed across these eight weeks. Only the wait did. Every one of those duplicate re-checks was a second consortium call, billed again, and a second entry the fraud model had to read as normal.
The decision that mattered
Claimwright launched with every step blocking, because at launch every step was Claimwright's own OCR model, fast and fully inside our own systems. Nobody revisited that default once the parts-pricing consortium check and the full medical file review got added months later. A rule that was right on day one quietly became wrong the day the first slow, outside-controlled step shipped next to it.
What I'd leave alone: the single-estimate path, claim number, VIN, line items, entirely our own model, finishing in eleven seconds nearly every time. Backgrounding that step would trade an eleven second wait for a badge someone has to remember to check later, which is a worse deal for something already that fast.
The lesson: a blocking wait isn't wrong because it's slow. It's wrong when the person watching it has no way to tell a wait that's working from a wait that's stuck, and they will always find their own way to check, even when that way costs more than the wait ever did.
Now here is the same thing as a story
Read the story below when you want to feel why a wait needs to know its own limits, not just be told that it does. The short version is above. This is the long one.
For the first year Claimwright ran at Northmere Mutual, the best part of Solvej Halstrand's week was a claims queue that emptied itself.
Solvej had run product for Northmere's claims tools for six years, long enough to remember when every claim meant a phone call to a parts supplier and a legal pad full of numbers. She knew the queue better than anyone on the floor, and adjusters trusted her calls about what to build next because she'd earned it, one small fix at a time.
Claimwright shipped quiet and steady. The first version only did what its own OCR model could do alone, reading a photo, pulling a VIN, matching a policy number. Every step blocked, and every step finished in under fifteen seconds, so nobody ever noticed there was a design decision hiding inside "just wait for it."
Then Northmere added the parts-pricing consortium check, a call out to an industry database that priced repair line items against real market rates, and a full medical file review for injury claims. Both stayed just as blocking as everything else, because that's how Claimwright had always worked, and the team was moving fast toward a release date.
For a few months, that was fine. Claim volume was light, the consortium answered quickly most days, and a minute-long wait now and then barely registered. The habit thinned out slowly after that: a slow Tuesday here, an adjuster muttering "is this thing stuck," a second adjuster doing the same thing the following week without telling anyone. Nobody wrote a ticket. Re-clicking a claim felt like nothing, the kind of thing you do without thinking about it twice.
The trigger was Northmere's monthly claims audit, a routine pull of ten random claims that a fraud-ops lead ran every few weeks out of habit, not suspicion. Two of the ten that month showed the same claim getting checked against the consortium twice, ninety seconds apart, same adjuster, same claim number. On its own, a curiosity. Across the full month's logs, it wasn't rare at all.
The ninety cents was nothing. What we actually lost was nine real families waiting four extra days for money they were always going to get.
The real cost wasn't the second consortium call itself. It was that the fraud model, built to flag a claim getting resubmitted twice as a possible scam, had no way to tell an adjuster's nervous re-click from an actual attempt to game the system. Nine claims a month were getting quietly held for a human reviewer to clear, adding days to payouts that had done nothing wrong.
The decision Solvej would take back happened in a release-readiness meeting, more than a year before the audit. Someone asked, almost in passing, whether the new consortium step should work differently from the rest of the pipeline now that it called an outside vendor. "It's one more check," Solvej said. "Block like everything else, we don't have time to design two different loading states before the date." Nobody pushed back. It made complete sense in that room, for a step that, on its best days, still finished in under twenty seconds.
Run that Monday over again the old way, and it repeats: a slow consortium response, a nervous re-click, a false duplicate flag, four extra days on a real payout. Run it the new way: the consortium check and the medical file review both start in the background the moment a claim comes in, the folder shows checking now, and a badge lights up the second either one finishes. Solvej's adjusters open the next claim instead of watching this one. By week eight, duplicate re-check requests had fallen from sixty five a week to four. False duplicate-submission flags dropped from nine a month to one, and that one turned out to be a real duplicate, not Claimwright's own hesitation.
One design trusted that a universal loading pattern needs no more thought once it's already working for the fast steps. The other trusted that a wait's meaning changes the moment it stops being fully yours to control, and built the rule around that instead of around a habit that happened to work at launch.
What I'd tell myself, back in that release-readiness meeting: "block like everything else" sounds like consistency, but consistency in the interface and consistency in who actually controls the clock are two different promises, and only one of them is yours to keep.
SPARK, for a wait that isn't always the same wait
Not a checklist to recite. Each letter has to survive the same audit the story just walked through, ten claims pulled at random on an ordinary Monday.
SSituation. Who is this person, and how does the job get done today, without you?
Before Claimwright existed at all, an adjuster at Northmere Mutual opened every document by hand: read the estimate, typed the VIN into a lookup tool, called around for a parts price, wrote up the check herself. About twenty five minutes a claim, entirely on paper and a phone, no AI step 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 Claimwright or any background rule existed at all.
PPayoff. What habit do you want this to build?
Not "adjusters feel less annoyed while waiting." Specifically: an adjuster opens a claim, sees Claimwright start working, and moves straight to the next claim in her queue, trusting that the badge will tell her when the first one is ready instead of needing to check on it herself.
A named habit, open the next one and trust the badge, produces a specific design. A vague goal like "make the wait feel better" produces nothing anyone can actually build on a Tuesday.
AAnchor. The one design decision everything else hangs on.
Route every step through two checks before it starts: does it call a system Claimwright does not control, and does its own measured p95 cross about forty five seconds. Either answer sends it to the background, with a notify badge that lights up the moment it finishes. Both answers coming back no keeps it blocking, since the person is about to open her next claim within a minute regardless.
This is the actual design decision. If it doesn't visibly survive the next letter, it's a slogan, not an anchor.
Two questions, asked before any step starts, decide the lane it runs in.
RRisk. What breaks the first time you're wrong?
A vendor slowdown can push the consortium check well past its usual p95 without warning. If a claim is kept blocking because its history said forty seconds, and this one instance runs six minutes, the adjuster is trapped mid-claim with nothing to look at and no way to leave.
A rule that only works when every call behaves like the average call isn't a design. It's the old spinner wearing a threshold instead of a number.
The anchor is allowed to be wrong once, as long as it says so within its own forty five seconds instead of staying quiet for six minutes.
KKeep out. What do you deliberately not build?
No SMS or email push on day one, only an in-app badge, since Northmere's compliance team has not cleared sending claim status to a personal phone. No user-set timeout preference, there is not enough real volume yet to know what number to offer. No streaming of partial extracted fields while the medical review is still running, since an adjuster acting on half a record before the fraud pattern check finishes is worse than a person simply waiting.
A wait design that shows more certainty than the system actually has doesn't build trust. It borrows it, and the bill comes due the first time someone acts on an unfinished answer.
What stayed off the day one build, and the reason each one waits.
Three things worth stating directly, since this is where the real judgment sits. The alternative Solvej rejected was backgrounding every step past a single fixed number, ten seconds, no matter who controlled it. It lost because a fast, fully internal eleven second lookup does not need a notify-later flow, it needs three more seconds, and forcing a check-the-badge habit onto something that quick just adds friction nobody asked for. The AI specific failure worth naming by name is a feedback loop: an adjuster's own re-click, an entirely human workaround for an honest wait, became a timing pattern that looked to the fraud model exactly like a customer resubmitting a claim to game it, since duplicate-submission timing is one of that model's real signals. The guardrail is two-part: the p95-based routing stops most re-clicks from ever happening, and any request tagged as a client-side retry gets excluded from the fraud model's own feature set, so a person's impatience can no longer quietly become the model's training signal. And the quality, latency, and cost trade-off worth naming too: holding back streaming on the medical file review means an adjuster waits the full review instead of watching fields fill in one at a time, but a partially extracted medical claim is exactly the kind of record nobody should act on early, so Claimwright accepts a slightly longer felt wait to keep every number checked before anyone reads it.
And if you want to be sure it really works, try it somewhere else
Same five letters, a building permit instead of an insurance claim, and this time the reversal is a merged step, not a default nobody revisited.
Permitloom is a permit-review assistant built for Marwood County. It reads a submitted building permit application, an address, a project type, a contractor license number, and checks it against the county's own building code. Cyrenne Ansgar is the engineer who led its wait design after residents started complaining that every permit, even a simple fence, took just as long as a full remodel.
S, situation: before Permitloom, a permit clerk read every application by hand, checking the code manually and mailing a paper approval, often two weeks for something as small as a backyard deck.
P, payoff: the habit worth building is not "residents feel patient while it processes." It is a clerk seeing simple permits clear themselves same day, and only opening the ones that genuinely need a person.
A, anchor: an internal code check runs first and blocks, since it is fully Marwood County's own system and finishes in under ten seconds. A historic-district review, which calls the state's own zoning registry, a system the county does not control and that can take anywhere from thirty seconds to several minutes, always goes to the background, with a notify badge for the applicant.
R, risk: the state zoning registry goes down for maintenance most Sunday nights, and a historic-district permit filed then would have blocked for hours under the old design, with nothing on screen to explain why.
K, keep out: no automatic approval for historic-district permits even when the state registry comes back clean, a person still signs off; and no per-parcel live map showing every neighbor's permit status, that is a feature for later, not for the wait itself.
The decision Cyrenne would take back
Permitloom's first version merged the internal code check and the external zoning lookup into a single call, so even a simple backyard deck, fully inside the county's own system, waited on the state registry every time, because the two checks had never been split apart.
Same two questions as Claimwright's anchor, applied to a permit instead of a claim.
Same method, a different weak spot: Claimwright's slow step is a vendor's response time. Permitloom's slow step only shows up for one kind of application, a historic-district permit, so the fix was not just picking a threshold, it was noticing that two genuinely different checks had been bundled into one blocking call that always waited for the slower of the two.
Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the anchor, background it when it is outside your control or past its own measured p95, block when it is fast and fully yours, and give the one number, duplicate re-checks fell from sixty five a week to four.
Cost: there is no budget this quarter for a fancy live status page. Build the plainest version, a folder that says checking now and a badge that lights up, it costs almost nothing and it is the part that actually earns the trust.
The model got better, for real: say the consortium API gets twice as fast next quarter. That is not a reason to make everything block again. A fifteen second external call is still a call you do not control, so it still belongs in the background, it will just finish faster once it gets there.
Where people run it wrong.
They background everything past one fixed number, and a fast internal step ends up behind a notify flow it never needed.
They set the threshold off the average instead of the p95, so the rule looks right for months right up until the one call in twenty traps someone.
They never build the escape hatch, so a wait that runs long for a genuine reason, not a design flaw, still leaves the person stuck with no way out.
How to use it live. Name the real split before answering: "is this asking me how long is too long, or asking me who controls the clock." Say that out loud, and it buys a beat while making clear you are not just going to suggest a bigger number.
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 background-or-block rule to survive the day a slow step's own threshold gets blown past.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Solvej Halstrand, PM at Northmere Mutual, owns Claimwright, an AI tool that reads and validates submitted claim documents.
3 · THE HABIT
What habit did the redesign have to build in adjusters?
Tap to flip
ANSWER
Open the next claim and trust the notify badge, instead of re-clicking or watching the current one to see if it is stuck.
4 · THE ANCHOR
What's the one design decision the whole rule hangs on?
Tap to flip
ANSWER
Background a step when it depends on a system you do not control or its own p95 crosses about forty five seconds. Block it when both answers are no.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Keeping every step blocking by default after the outside-controlled consortium check and the long medical file review were added, without ever revisiting the rule that had only ever been tested on fast, fully internal steps.
6 · THE NUMBER
Fill in the blank: false duplicate-submission flags fell from ___ a month to ___ a month after the redesign shipped.
Tap to flip
ANSWER
Nine a month, down to one, and that one turned out to be a real duplicate, not an adjuster's own re-click.
7 · THE REPLAY
Same audit Monday, new design, what changes?
Tap to flip
ANSWER
The slow steps start in the background the moment a claim arrives, a badge lights up on finish, and duplicate re-check requests fall from 65 a week to 4 by week eight.
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
Permitloom, a permit-review assistant at Marwood County. Same anchor: control plus measured p95 decide the lane, this time splitting an internal code check from an external zoning lookup instead of an insurance claim's steps.
Check yourself Score: 0 / 0
Multiple choice
1. Claimwright's single-estimate OCR extraction has a p95 of eleven seconds and calls no outside system. What should happen to it?
A. Background it anyway, since any wait over five seconds should get a notify flow.
B. Keep it blocking, since it is fully inside Claimwright's own systems and well under the forty five second cutoff.
C. Background it only on Mondays, when claim volume is highest.
D. Ask the adjuster to choose blocking or background every time.
Show hint
Check the anchor step and what happens when both of its two questions come back no.
Show answer
B. Fast and fully owned stays blocking on purpose. Routing an eleven second lookup through a notify-later flow adds a check-the-badge step the adjuster never needed.
True or false
2. True or false: the redesign set its background threshold using the average time each step took, not the p95.
True
False
Show hint
Look at the knowledge spark right after the "how it went before" paragraph in Let's learn.
Show answer
False. The rule uses p95, the slow case one call in twenty actually hits, not the average. An average hides exactly the long-tail call that traps someone.
Fill in the blank
3. Duplicate re-check requests fell from ___ a week in week one to ___ a week by week eight, after the background-and-notify redesign shipped.
Show hint
Look at the line chart in Let's learn, right after the audit diagram.
Show answer
Sixty five a week, down to four. Nothing about the consortium vendor changed in those eight weeks. Only the wait's design did.
Short answer, name the rejected alternative
4. What alternative did Solvej reject for deciding what goes to the background, 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: Backgrounding every step past a single fixed number, like ten seconds, no matter who controlled it. It lost because a fast, fully internal step that happens to run a little over that number does not need a notify-later flow, it just needs a few more seconds, and forcing the flow on it adds friction nobody asked for.
Multiple choice
5. Permitloom's first version merged the internal code check and the external zoning lookup into one blocking call. What does that reveal?
A. Background processing does not work for government systems, only for private companies.
B. Bundling a fast, fully owned check together with a slow, externally controlled one forces the fast one to wait for the slow one every time.
C. Permitloom should remove the historic-district review entirely since it is too slow.
D. Marwood County should go back to mailing paper approvals for every permit.
Show hint
Read the key point block right under Permitloom's R and K steps, "the decision Cyrenne would take back."
Show answer
B. Merging the two checks meant even a simple backyard deck, fully inside the county's own system, waited on the state zoning registry every time, since the checks had never been split apart.
Short answer, apply it yourself
6. Pick an AI product you use yourself. Name one step in it that calls an outside system or runs long sometimes, and say whether it should block or background.
Show hint
Think about whether the slow step is something the company itself runs, or something it is waiting on from somewhere else.
Show answer
Model answer: A travel app's AI trip planner checks live flight prices from several airlines before finishing an itinerary. That check depends on airline systems the app does not control and can run past a minute during a fare sale. It should background the price check and notify once the itinerary is ready, while the fast part, reading the traveler's own saved preferences, stays blocking since it is instant and fully the app's own.
Before you close the answer
Why this works
Tests whether you can turn "background it if it feels slow" into an actual, measurable rule, and whether you know a person's own workaround for a bad wait can quietly leak into a model that reads behavior as a signal. Most candidates pick a number. Few tie it to who controls the clock, and fewer still connect a bad wait to a real fraud-model failure.
Follow-up traps
"Why forty five seconds specifically, and not thirty or sixty?" Response: it is not a fixed law, it comes from where Claimwright's own p95s actually land, close to the OCR extraction's own ceiling and well below the consortium check's typical run, and it gets revisited once real volume changes those numbers, not guessed a second time from a desk.
"Couldn't you just make the consortium check faster instead of backgrounding it?" Response: worth pursuing in parallel, but Claimwright does not control the vendor's own response time, so the design has to survive that vendor being slow on any given day, not assume it will always improve.
If pressed
Every re-check that Claimwright's own p95-based routing fails to prevent gets tagged as a client-side retry at the request level, and that tag excludes it from the fraud model's duplicate-submission feature, so even a rare re-click can no longer quietly train the model to treat impatience as fraud.
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.
