Design the review interface for a human checking 200 AI-generated outputs an hour.

Harborcrest Mutual Insurance runs TriageAI, a tool that drafts a settlement recommendation for property damage claims after a photo, an estimate, and adjuster notes come in. Noor Rasheed is a claims adjuster on Harborcrest's catastrophe response team, and after a regional hailstorm, she has to clear about 200 flagged claims an hour to keep the queue from burying the team.

How to answer this, stage by stage

Nobody is grading whether you can sketch a pretty screen. They're grading whether your screen survives the one hour a week it actually gets tested.

Let's learn

Say we build a screen that has eighteen seconds to earn a person's real attention, two thousand times over.

Before TriageAI, a Harborcrest adjuster reviewed a property damage claim from scratch: measuring damage from photos, pricing repairs against a materials guide, writing up a settlement recommendation by hand. A single claim took about twenty-two minutes, and a normal week's volume of around 1,800 claims spread across forty adjusters, comfortably.

Slow, but nothing ever waited in a queue long enough to need sorting.

Now TriageAI drafts a full settlement recommendation, photos, estimate, and reasoning, in under two seconds, and most weeks an adjuster reviews and confirms a batch in a normal, comfortable rhythm.

Here's the turn: the problem isn't a bad week where the model gets more wrong. The problem is a good tool meeting a genuinely enormous queue, where the interface itself, the plain order things appear in, quietly decides which claims a person actually gets to think about.

The queue doesn't wait for the interface to be ready. It just arrives.

At its worst, a genuinely large claim sits near the bottom of a two-thousand-item flat queue behind a wall of routine ones, and by the time anyone reaches it, the wrong number has already gone out in a settlement letter.

Most claims are small and easy. The ones that matter sit in the top-left corner, and a flat queue has no way to find them.

What I would leave alone: small, routine claims, a fence panel, a gutter, well inside TriageAI's tested range, don't need any of this. The whole design is aimed at the rare, large, uncertain claim sitting somewhere in a queue of two thousand.

The lesson: at real volume, the interface isn't a window onto the work. It is the work. The order is the decision.

Now here is the same thing as a story

The short version above is what you'd say defending this redesign to Harborcrest's claims operations lead. Read this one for how the old queue nearly let one slip through.

Noor Rasheed has adjusted property claims for six years, and she is the one people ask when a photo doesn't match the estimate, the kind of detail that saves the company real money on a claim nobody else double-checked.

After the hailstorm hit, TriageAI's queue filled with claims in arrival order, same as every ordinary week, just at fifteen times the volume. Noor and her CAT team started clearing the flat list top to bottom, fast, the way the screen had always worked.

The same claim, in two different queue designs, ends up in two very different places.

A colleague working the same queue leaned over around hour three and said, half-joking, "you've cleared ninety of these in the last twenty minutes, are you even reading the estimates?" Noor laughed, then actually checked her own pace. She had been.

Every claim showed the same four things. None of them told her which claim actually needed her attention first.

Deep in the flat queue, past hundreds of routine fence and siding claims, sat a roof-collapse claim TriageAI had flagged with unusually low confidence, forty thousand dollars, a genuinely uncertain read on structural damage from a partial photo set. Nothing about its position in the list made it look any different from the fence claim next to it.

Noor reached it with about forty minutes left in her shift, tired, and nearly approved the draft settlement as written. A habit from years of careful work made her open the photo set full-screen one more time, and she caught a support beam crack the draft estimate hadn't priced in at all.

With the redesigned queue, that same claim, low confidence and high dollar amount, would have surfaced first, not four hundred items in. Run the storm week forward: Noor sees it inside her first hour, fresh, not on the tail end of a long shift, and the crack gets caught before any settlement number is ever written down.

The old queue asked her to be equally careful about everything. The new one asks the queue itself to know which claims need that from her.

I built the queue in arrival order because it matched the paper system it replaced, and paper had never needed sorting. It took a colleague's offhand comment, and a roof claim I nearly missed at hour six, to see that speed alone was never the actual danger. Order was.

SPARK, in one screenNot a UI style guide. SPARK is what tells you the queue's order is the whole design.

Each of these would be a real feature someday. None of them fixes what today's flat queue actually gets wrong.

The recap, one line per letter: situation is a flat, arrival-order queue built for calm weeks, payoff is real attention on the rare hard claim instead of even attention on all of them, anchor is a risk-sorted single-claim card with a dollar floor, risk is a miscalibrated confidence score, and keep out is holding back on auto-approval, AI-written denials, and speed leaderboards.

And if you want to be sure it really works, try it somewhere elseSame five letters, an HVAC dispatch queue instead of an insurance claim. A different volume spike, the same order problem.

Cross-County Comfort runs a dispatch tool that reads a customer's service request and drafts a repair plan for a technician, ordinary filter swaps up through full system failures. Ezra Lindqvist dispatches technicians from a laptop with a cracked hinge in the back office, and during the first heat wave of the year, requests come in faster than any one dispatcher can read closely.

Mapped onto SPARK: situation is a flat dispatch queue in call order, payoff is real attention on the calls that are actually dangerous or unusual, anchor is a queue sorted so a reported gas smell or an active warranty claim always surfaces above routine filter swaps, regardless of how confident the draft plan sounds, risk is a technician getting sent alone to a job the draft plan underestimated, and keep out is holding off on fully automated scheduling for anything outside the routine tier.

Swap "claim" for "service call," and the same three warning conditions do the same job in a different queue.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "sort the queue by risk, not arrival time, and force a floor rule that ignores confidence past a certain size," and stop.
Cost: there's no engineering time to build risk scoring this quarter. Say so honestly, and start with the dollar floor alone, a single rule, before building the fuller sort.
The model gets better, for real: even if TriageAI's accuracy improves across the board, the dollar floor still earns its place, since the whole point was never trusting the score completely on the cases where being wrong costs the most.

Where people run it wrong.
They design the screen for a calm demo day, then ship it straight into a queue fifteen times that size with no changes.
They sort purely by the model's own confidence, which fails exactly when the model is confidently wrong about something specific.
They measure success by how fast the queue empties, which rewards exactly the rushed clicking this design is trying to prevent.

How to use it live. When someone hands you a review-interface question, ask the volume question before you draw anything: how many seconds does this person actually have per item? Design the sort order for that number, not for a demo.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0