Design the experience for a partial result rather than a failure.

ClearRecord redacts and extracts records for Alder Bluff County Clerk's Office when someone files a public-records request. Here is the batch that beat Marcus Fennimore's afternoon, and the design that would have given nine of his twelve files back in the first twenty minutes.

How to answer this, stage by stage

Nobody is grading whether you know the words "partial result." They're grading whether you can say what happens to the files that were never actually broken.

Let's learn

ClearRecord is an AI tool Alder Bluff County Clerk's Office uses to pull requested records out of a stack of scanned files and redact private information before a public-records response goes out.

Before ClearRecord, a records officer read and redacted every page by hand, about twenty-five minutes a file, with a multi-file request often taking days to turn around.

Now ClearRecord processes a whole batch automatically, most files finishing in under a minute each.

Four steps, and the third one quietly erases whatever the first two got right.

Here's the turn: the extra speed was never the problem. The real cost showed up the moment a batch of twelve files had even one file the tool couldn't finish, a bad scan, handwriting, a foreign-language page, because the whole batch got marked failed, hiding the nine files that were already done and fine.

At its worst, a rushed team ships a "done" file with a redaction the model missed, and something that should have stayed private goes out with the response.

What I would leave alone: a single-file, one-page request doesn't need this treatment. There's no batch to split, so the current all-at-once handling is already fine there.

The lesson: a status that only ever says "done" or "failed" is a coin flip wearing the costume of information. The real question was always which nine, and which three, and why.

Now here is the same thing as a story

The short version above is what you'd say defending this redesign to Alder Bluff's county records board. Read this one for how the trust actually built up.

Marcus Fennimore has worked as a records officer for three years, and he knows exactly which fields state law requires redacted on a given record type without ever needing to look it up.

ClearRecord launched and the first months were good. Most requests turned around the same day instead of the same week, and Marcus's backlog dropped fast.

Month one, Marcus reviewed every file's redactions personally, regardless of what the batch status said. By month three he only reviewed files ClearRecord flagged as uncertain. By month five he stopped opening "done" batches at all, trusting the "Batch complete" banner on its face.

This is what the redesigned screen shows Marcus. The old one only ever showed one word.

A batch of fourteen files came in for a routine zoning-dispute request. One file, a scan creased hard down the middle, came back unreadable. The screen said only "Batch failed." Marcus, reasonably, from five months of experience with that message, assumed all fourteen needed his attention.

He opened all fourteen files by hand that afternoon, confirming that thirteen of them had, in fact, been right the whole time, and losing most of the afternoon to work that never needed doing.

The failure this design actually has to survive isn't a broken file. It's a done file that's confidently wrong.

It wasn't really about the lost afternoon. It was that "failed" meant nothing specific, so every batch failure from then on cost Marcus a full manual re-check of every file in it, exactly the habit ClearRecord was supposed to end.

With the redesigned screen, the same fourteen-file batch shows thirteen files landing in "Done, ready to send" the moment each finishes. One file lands in "Needs you: page torn, text unreadable" within the first four minutes. Marcus reviews just that one file, confirms the highlighted redaction sample-check on the thirteen in under ten minutes total, and sends the full response by early afternoon instead of losing it.

The old design asked Marcus to trust a single word for the whole batch. The new one tells him exactly which files earned that trust and which one didn't.

I built the batch job to report status once, at the end, because that's the simplest thing to build and test batches almost always passed. It took one creased scan, and an entire wasted afternoon confirming work that was already right, to see that "simple to build" and "tells the truth" were never the same thing.

The anchor, and what protects itNot a lecture on staying calm about failures. SPARK is what tells you which decision the whole screen actually hangs on.

The recap, one line per letter: situation is a batch that fails as one unit and a wasted afternoon, payoff is teaching Marcus to trust "done" without re-checking it, anchor is the three-bucket screen with a mandatory redaction pass, risk is a confidently wrong redaction on a file marked done, and keep out is holding back a diff viewer and auto root-cause tagging on day one.

The redaction pass isn't just for the files ClearRecord admits it's unsure about. The top-right corner is exactly where a confident miss does the most damage.

Each of these is a real feature someone will ask for eventually. None of them belongs in the first version.

Twenty minutes after starting, Marcus already has nine files he can act on.

And if you want to be sure it really works, try it somewhere elseSame five letters, a hospital discharge-translation batch instead of a records office. A different risk, the same three buckets.

Kestrel Valley Medical Center uses Transcura, an AI tool that translates multi-page discharge instructions for patients who don't read English as a first language. Wren Oduya, a discharge coordinator, runs it on a patient's twenty-two page instruction packet before they leave the hospital. Mapped onto SPARK: situation is a coordinator today, printing instructions in English and waiting on a staff interpreter's availability, sometimes hours, before a patient can safely leave; payoff is the habit to build, trusting that translated pages already marked done are safe to hand over immediately, instead of holding the entire packet until every page clears.

The anchor here is structurally the same idea, aimed at a sharper risk: pages ship per file into the same three buckets, with medication dosage and timing instructions specifically highlighted for a human bilingual staff member's pass before any page counts as done, regardless of how confident Transcura's translation model reads. The risk Kestrel Valley's team designed against was a confidently wrong dosage translation on a page marked done, since a missed decimal point in a medication instruction is a materially different kind of harm than a missed comma in a public-records redaction, and needed its own dedicated check rather than the general sample nudge alone.

Same shape of rule as ClearRecord's buckets, tuned for a different kind of page that can't afford to be wrong.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "ship per file into done, needs you, and still working, with a mandatory check on every done file before it counts as safe," and stop.
Cost: there's no time to build the full three-bucket UI this sprint. Say so honestly, and ship the plain per-file reason text first, since that alone stops the worst of the wasted re-checking.
The model gets better, for real: if ClearRecord's redaction accuracy genuinely climbs to near perfect, that's still not a reason to drop the mandatory human pass on done files, the one confident miss is exactly as costly as it ever was, however rare it becomes.

Where people run it wrong.
They build a progress bar for the whole batch and call partial visibility solved, without ever splitting out which specific files are actually usable.
They only apply a human check to files the model flagged as uncertain, missing the confidently wrong ones entirely.
They assume "processing" is informative, when it hides the one decision the person actually needs to make right now.

How to use it live. When someone asks you to design a partial-result experience instead of a failure, ask yourself one question before sketching a single screen: if this batch had ten good files and one bad one right now, would the person in front of it be able to tell which is which? If the honest answer is no, you haven't designed a partial result, you've just relabeled a failure screen.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0