How would you design an interface that encourages verification without being annoying?

Fentridge Pharmacy is a busy retail pharmacy. Naomi Petrosyan is the pharmacist on duty most afternoons, fourteen years behind the counter. InteractGuard is the AI tool built into the dispensing terminal that flags possible drug interactions before a prescription gets filled.

How to answer this, stage by stage

Nobody's grading whether you can list ten notification patterns. They're grading whether your design has a way to know it's failing before a real miss proves it.

Let's learn

Here is what happens when every safety alert asks for the exact same amount of attention.

Before InteractGuard, Naomi's team checked interactions by hand, cross-referencing a printed reference guide, taking about ninety seconds per prescription. InteractGuard now checks every prescription in real time, cutting that to under five seconds when nothing's flagged.

The third box is where this whole answer lives. Before the redesign, every prescription landed in the same identical box there.

Here's the turn: the extra speed was never the risk. The risk showed up the day every flagged interaction, trivial or genuinely dangerous, produced the exact same one-click box, and nothing about the screen told anyone which ones actually mattered.

Four parts. Before the redesign, every severity got the same second part, and nothing at all like the fourth.

At its worst, an identical alert box for every severity doesn't just get annoying. It trains a careful person to stop reading any of them, right up until the one time that costs a patient something real.

What I would leave alone: the plain informational notes InteractGuard shows for routine dosage reminders, like "take with food," don't need any friction at all. Adding a click requirement there would just be more noise with nothing gained.

The lesson: an alert that asks for the same attention every time isn't really asking for attention at all, it's asking to be dismissed.

Now here is the same thing as a story

The short version above is what you'd say pitching this redesign to Fentridge's pharmacy director. Read this one for how close the near miss actually came.

Naomi Petrosyan had worked the counter at Fentridge for fourteen years, and could spot a risky drug combination from memory before InteractGuard ever existed. A new pharmacy tech, a few weeks into the job, asked her one afternoon why everyone clicked through the safety pop-ups so quickly. Naomi didn't have a good answer, and the question stuck with her.

That same week, a prescription came through for a patient already on a blood thinner, paired with a new antibiotic known to raise bleeding risk when combined. InteractGuard flagged it, the exact same one-click box it used for thirty routine reminders that shift, "take with food," "avoid alcohol," "may cause drowsiness."

Naomi dismissed it in under a second, the same reflex she'd built over months of identical boxes. A tech, double-checking a different detail on the same order twenty minutes later, happened to notice the interaction listed in the chart and flagged it before the prescription left the pharmacy.

Seventeen minutes between the reflex click and the accidental catch. Nothing in the design made that catch anything but luck.

Fentridge's redesign tiered the alerts by real severity, and added a mandatory read-time lock with a chosen reason for anything genuinely serious. A comparable case the following month triggered the locked screen, and Naomi caught it herself, on the first pass, no lucky double-check required.

Three tiers, not one box for everything. The friction now matches what's actually at stake.

LEAD, in one screenNot a UX checklist for reducing pop-up fatigue. LEAD is what tells you the design is failing before a real miss proves it.

The fast-dismiss rate was ringing for months. Nobody had built a way to hear it.

Any one of these three quietly makes the numbers look better while making the pharmacy less safe.

The recap, one line per letter: link is real interactions caught, not fewer complaints, early signal is the fast-dismiss rate climbing for months before the near miss, abuse is a team quietly raising the alert threshold to look less annoying, and decision is a real, pre-agreed trigger on the fast-dismiss rate, not a vague promise to watch it.

And if you want to be sure it really works, try it somewhere elseSame four letters, a legal translation firm's clause-review flag instead of a pharmacy terminal. A different abuse breaks the second story.

Pemberton Language Services uses ClauseFlag, an AI tool that flags contract clauses where a translation carries real ambiguity, nudging a human reviewer to verify before a translated contract ships to a client. Grant Sutherland is the reviewer who checks flagged clauses each day. Mapped onto LEAD: link is mistranslations that actually cause a contract dispute later, not a lower count of flagged clauses; early signal is the share of flagged clauses approved in under one second, without the reviewer opening the original text to compare.

The abuse here works differently than at Fentridge. Instead of a reviewer clicking through fast, the team under deadline pressure quietly started suppressing flags on clauses matching common boilerplate language, on the theory that boilerplate is rarely ambiguous. That "improved" the flag count and the fast-approval rate at the same time, while hiding the rare case where boilerplate-looking language actually carried a real, contract-specific ambiguity.

Same four parts. "Severity" here means how much a mistranslation could actually cost in a dispute, not a drug interaction's harm.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "tier the friction by real severity, and track how fast alerts get dismissed as the early warning," and stop.
Cost: there's no engineering time this sprint to build a full read-time lock. Say so honestly, and ship the dismiss-speed logging first, since knowing the problem exists costs far less than fixing it, and it's the prerequisite for fixing it at all.
The model gets better, for real: if InteractGuard's accuracy genuinely improves and false alarms drop, that's still not a reason to loosen the read-time lock on severe cases, a better model still occasionally flags something serious, and that case still deserves the friction it's earned.

Where people run it wrong.
They treat every flagged item as equally worth interrupting someone for, instead of tiering by what's actually at stake.
They measure success by fewer complaints about annoying alerts, instead of by real incidents actually caught.
They never log how fast something gets dismissed, so the reflex has nowhere to show up until it's already cost someone something.

How to use it live. When someone asks for verification without annoyance, ask yourself: what's the number that would show people clicking through on reflex, weeks before that reflex costs anyone anything? Build that number in from day one.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0