Walk me through the failure states you would design for a feature I name.

Fernbrook Veterinary Network runs a telehealth app for rural mobile clinics. DoseGuide is the feature inside it: type in an animal's weight and species, and it calculates a medication dose during a live call. Ingrid Falk is a vet tech who runs a mobile clinic van across three counties.

How to answer this, stage by stage

Nobody is grading whether you picked a clever feature. They're grading whether you can walk through more than one way it actually breaks.

Let's learn

Here is what happens when a feature works fine for months, then fails in a way nobody actually designed for.

DoseGuide is a small piece of Fernbrook's telehealth app: a vet tech types in an animal's weight and species, and it returns a dose for whatever medication a remote veterinarian just prescribed on the call. Before it, that math happened by hand, off a printed formulary card, checked twice against a chart taped inside the van's glove box.

Slow, but every step forced a person to look at the number twice before it reached an animal.

Now the calculation takes about three seconds, and most calls never touch a failure state at all.

Here's the turn: the failure states were never really one thing called "an error." They're four different situations, each needing a genuinely different response, and treating them all the same, one generic warning banner, is itself a design decision that will eventually let the worst one through quietly.

At its worst, a vet tech reads a dose meant for kilograms as pounds, or the reverse, and administers a dose off by a factor of more than two, with nothing on screen ever having looked uncertain.

Four states, four different jobs. None of them should get the same response as any other.

What I would leave alone: the underlying dosage formula for a known species, well inside its verified weight range, doesn't need touching. This design is entirely about the edges around it.

The lesson: a single "error" state is a lie about how many different ways a feature actually breaks, and each one deserves its own honest response.

Now here is the same thing as a story

The short version above is what you'd say defending this design to Fernbrook's clinical safety board. Read this one for how close the near miss actually came.

Ingrid Falk drives a mobile vet clinic across three rural counties, and by her fourth year she could estimate a goat's weight within five pounds just by looking at it. DoseGuide had been solid for her for months, instant, and matching the printed chart every time she'd checked it against one.

On a rushed farm call, juggling a clipboard and a squirming terrier, Ingrid skipped the weight field entirely, planning to fill it in after the call. DoseGuide silently used a breed-average placeholder weight instead, one built for a mid-sized dog, not a small terrier under ten pounds.

Any one of these four points could have been the moment something went quietly wrong. The unit point is the one with no visible seam.

The remote veterinarian on the call, reading the dose off her own screen, paused: "wait, that seems high for a dog this size, did you weigh her?" Ingrid checked, found the terrier weighed six pounds against the placeholder's estimated thirty, and recalculated by hand before administering anything.

Nobody filed an incident report, since nothing was actually given. But the near miss reached Fernbrook's product team through the veterinarian mentioning it on a routine call review, and an audit of recent sessions found the same silent placeholder had quietly stood in for a real weight eleven other times that month.

Same design mistake, one field over. A silent assumption anywhere in this feature carries the same risk.

The most common failure isn't the most dangerous one. The rarest one is.

With the redesigned states, a blank weight field blocks the calculation outright instead of filling in a placeholder, and the unit is printed large next to every dose and requires a tap to confirm, every single time, regardless of how many times that tech has done it before. Run the same farm call forward: Ingrid can't get a number at all until she weighs the terrier, and the whole near miss never has anywhere to happen.

The old design asked DoseGuide to always have an answer. The new one lets it say plainly when it doesn't have enough to give one.

I let the weight field default to a placeholder because a blocked calculation felt like a worse experience than a fast, if occasionally wrong, one. It took a veterinarian's offhand question to see that a fast wrong number is exactly the kind of thing this feature exists to prevent.

SPARK, in one screenNot a single design trick. SPARK is what tells you why four failure states, not one, is the actual answer.

Each of these is a real, larger feature. None of them fixes the failure states this answer is actually about.

The recap, one line per letter: situation is a vet tech doing the math by hand off a printed card, payoff is trusting the common case while genuinely pausing on a flagged one, anchor is four states with four distinct responses, risk is the silent unit mix-up, and keep out is holding back on interaction checking and chart sync until this scope is solid.

And if you want to be sure it really works, try it somewhere elseSame five letters, a school attendance-pattern assistant instead of a dosage calculator. A completely different feature, the same four-state shape.

AttendWell is a feature inside Alcove ISD's student-information system that flags attendance patterns worth a counselor's attention, missed days clustering in a way that might signal a problem at home rather than ordinary absences. Odalys Kern is the attendance clerk who reviews AttendWell's flags each morning.

Mapped onto SPARK: situation is a clerk today, scanning a spreadsheet by eye for patterns, easy to miss on a busy Monday; payoff is trusting flagged patterns enough to act quickly, without tapping through every flag the same distracted way. The anchor is structurally the same four-state idea, aimed at a different failure: missing attendance data for a transferred student blocks a pattern read entirely instead of assuming zero absences, a pattern that's genuinely unusual for that student's history gets a loud flag needing a counselor's confirmation, a sync failure from the district's central system shows a dated "last synced" banner instead of silently reusing stale records, and which category a pattern falls into, truancy risk versus a family emergency versus a medical leave, is never auto-assigned without a person confirming it.

Swap "dosage" for "attendance pattern," and the same four-state shape holds up in a school office instead of a vet van.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "name every failure state separately, and give the rarest, most dangerous one the loudest response," and stop.
Cost: there's no time to build all four states with equal polish this sprint. Say so honestly, and build the unit-confirmation state first, since it's the one with the least visible warning if it's missed.
The model gets better, for real: if DoseGuide's underlying dosage model gets more accurate across common cases, that's still not a reason to relax the unit-confirmation requirement, an accurate calculation against the wrong unit is still exactly as wrong.

Where people run it wrong.
They build one generic error state and assume it covers every kind of failure equally well.
They let the rarest failure state get the least design attention, when rare and dangerous often go together.
They wait for an actual incident to design around a failure state, instead of asking upfront what the quietest possible version of it would look like.

How to use it live. When someone hands you a feature and asks you to walk through its failure states, ask yourself one question first: which of these failures would look exactly like success on screen? Design that one loudest of all.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0