What information does a reviewer need to make a good decision quickly?

Fennimore Electronics, an online retailer, runs an AI model that flags orders likely to be fraudulent before they ship. Perpetua Voskuijlen reviews every flagged order on a laptop with a cracked hinge at the edge of the warehouse floor, deciding whether to hold, cancel, or release it.

How to answer this, stage by stage

Nobody is grading whether you can name four fields. They're grading whether the fields you'd add actually earn back the seconds a fast reviewer doesn't have to spare.

Let's learn

Picture eleven hundred flagged orders a week, and a screen that shows exactly one thing about each: a percentage.

Fennimore's fraud model reads an order, the shipping address, the device, the payment method, the account history, and produces a single fraud-risk score. Before the model, a reviewer had to check all of that by hand, slower, but she always knew exactly what she was looking at.

Same order, same model, two completely different amounts of usable information.

Now the model does most of that checking itself, and Perpetua just sees the result: a number between zero and a hundred. She still has to decide hold, cancel, or release, in about the same time she used to spend just reading the order.

Here's the turn: the model wasn't withholding anything on purpose. It had already found the reasons, the specific signals, the similar past cases. The screen just never showed them, so every fast decision Perpetua made was really a guess dressed up in a number that looked precise.

At its worst, a whole review shift makes calls it can't explain to anyone, including itself, and a genuinely wrong decision has no visible reason attached to it when someone asks why later.

Four fields. Every one of them was already sitting inside the model, unused.

What I would leave alone: orders under the model's lowest risk band, with no flagged signals at all, don't need any of this. They should never reach a reviewer's screen in the first place.

The lesson: a number that looks precise isn't the same thing as a reason. A reviewer needs the second one to decide fast and defend the decision later.

Now here is the same thing as a story

The short version above is what you'd say pitching this redesign to Fennimore's head of trust and safety. Read this one for the question that actually broke the old screen.

Perpetua Voskuijlen has reviewed flagged orders for four years, and she's the one other analysts ask when an order looks strange but the number alone doesn't explain why.

A new hire named Dov, three weeks into the job, pulled up two orders side by side one afternoon. "This one got flagged and this one didn't," he said, "and they look identical to me. Why?" Perpetua looked at both scores, 84 percent and 81 percent, and realized she genuinely couldn't tell him. She'd been deciding off a number for months without ever really knowing what it meant.

The fields worth building sit in the cheap-and-valuable corner. A raw score is cheap but nearly worthless on its own.

That question sat with her for a week. She raised it with the product team, not as a complaint, but as a specific gap: the model clearly knew more than the screen was telling anyone.

One honest question from a new hire moved faster than a year of reviewers quietly guessing.

The redesigned card shipped four weeks later: matched signals named in plain words, a confidence range instead of a decimal, and two similar past cases a click away. Perpetua opened the same kind of pair of orders Dov had asked about, and this time the screen told her plainly: one had a new device and a billing mismatch, the other had neither. Same rough score. Completely different reasons.

With reasons on the screen, decision time dropped from three and a half minutes to under a minute, and escalations to a senior analyst for "why did it flag this" dropped alongside it, because reviewers could now answer that question themselves, on the spot.

The old card asked "do you trust this number." The new one asks "do these specific facts add up."

I built the single score first because it was the simplest thing to ship. It took one new hire's honest question to see that simple and useful were never the same thing.

SPARK, in one screenNot a feature wish list. SPARK is what forces the information to survive a real fast decision.

Leaving these off the card is as much a design decision as adding the four fields that stayed on.

The recap, one line per letter: situation is a single unexplained score, payoff is independent, confident decisions instead of escalations, anchor is signals, a confidence range, and similar cases, risk is a shown reason that's wrong or incomplete, and keep out is the raw model internals nobody reviewing an order in under a minute actually needs.

The whole redesign, in one image: a guess dressed as a number, next to an actual reason.

And if you want to be sure it really works, try it somewhere elseSame five letters, a pet insurance claims queue instead of a fraud desk. A completely different industry, the same missing reasons.

Cloverleaf Pet Insurance runs a model that flags veterinary claims likely to be exaggerated or miscoded. Halvard Mbeki reviews flagged claims and, before a redesign, saw only a single "claim risk" score with no supporting detail.

Mapped onto SPARK: situation is Halvard deciding to approve, deny, or request more documentation off one number alone; payoff is deciding confidently without pulling a veterinarian on the phone for every uncertain case; anchor is showing which specific coding patterns triggered the flag, plus two similar past claims and how they resolved, instead of the bare score; risk is a shown pattern that's misleading, since a legitimate emergency surgery can share billing codes with a genuinely inflated claim, caught by logging every case where Halvard's final call disagrees with the flagged reason.

Swap "order" for "claim," and the exact same missing reasons show up in a completely different queue.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "swap the single risk score for named signals, a confidence range, and similar past cases," and stop.
Cost: there's no engineering time this quarter for a full redesign. Say so honestly, and start with just naming the top two matched signals in plain words, since that alone beats a bare percentage.
The model gets better, for real: even if the underlying model's accuracy keeps improving, the reasons still matter, because a more accurate model that can't explain itself just produces confident-sounding guesses instead of uncertain ones.

Where people run it wrong.
They add more numbers to the screen, a second score, a third metric, instead of asking what a person can actually act on in the time they have.
They show the model's raw feature weights, mistaking transparency for usefulness, when nobody reviewing an order in under a minute can read a weight table.
They never log when a reviewer disagrees with the shown reasons, so a wrong or misleading signal keeps quietly steering decisions unnoticed.

How to use it live. When someone asks what a reviewer needs to decide fast, ask one question first: what does the model already know that the screen isn't telling anyone? Design the card around answering that, not around adding more numbers.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0