Some errors do not need to be discovered again. They need to be lifted from the past before they are rebuilt into the next system.

Concept of the week · Known errors are future requirements

The calmest risk control often starts with yesterday’s evidence.

Known use error analysis turns existing use errors, close calls, complaints, prior study findings, training workarounds, and similar-device problems into design input before the new user interface (UI) is locked.

Under pressure, teams often treat old problems as historical noise. But they are usually maps of attention cost, hidden checks, rework, and verification burden that the next design can either absorb or repeat.

Risk rule: A known use error is not processed until the team has mapped the task, the harm path, the design control, and the test method that will try to make the error visible again.

In a neonatal intensive care unit (NICU), a nurse replaces a transcutaneous gas measurement sensor during an unstable shift.

The new module inherits a known pattern from earlier devices: clinicians can miss a required site-time reset after moving the sensor, because the prompt looks like a status message and the previous value remains visible. Because transcutaneous sensors are heated, the site timer helps protect fragile skin from staying under the sensor too long. The harm path is not “missed reset” by itself; it is delayed site rotation, skin stress, and late recognition.

If the team treats this as a generic “incorrect setup” risk, the likely response is another warning, another instruction, or another training note. The burden stays with the nurse.

A calmer path starts earlier. The team reviews complaints, service notes, old formative sessions, training feedback, and comparable devices, then links the known use error to the exact task: move sensor, confirm site, reset timer, verify displayed status.

That changes the design conversation. The UI no longer relies on memory. It makes the state transition visible, removes stale values from the active display, and tests the scenario with NICU nurses during formative usability work.

The same pattern appears outside healthcare when an admin console preserves a dangerous previous environment, permission, or configuration after a context switch. The known error is not just a defect history. It is a design input waiting to be processed.

One thing to remember: Known use errors only reduce risk when they are lifted out of scattered evidence, translated into task-level failure paths, and processed into design controls that can be tested.

How teams ship this: Version a Known Use Error Register with five fields only: source, task step, harm path, design control, and formative test scenario.

Asset & resource

Known Use Error Review List. Use this short point list before design review:

  • Source: Where did the known use error appear?

  • Task step: Where exactly in the workflow did it happen?

  • Harm path: What could happen if this step fails again?

  • Design control: What change reduces memory load, hidden checks, or rework?

  • Test scenario: How will the team make this known error visible again before release?

Medical Device Use Error: Root Cause Analysis by Michael Wiklund, Andrea Dwyer, and Erin Davis.

Light wisdom & reflection

“Human error is not the conclusion of an investigation; it is the starting point.”

Sidney Dekker

Which known error in your product is still treated as background knowledge, when it should already be shaping the next design decision?

Mindful practice

For two minutes, think of a small repeated mistake at home: the key you misplace, the light you forget, the message you reread.

What condition makes it more likely?

What small cue, place, or boundary would make the right action easier without needing more discipline?

Next time it happens, notice the setup before you judge the person.

Bonus Chapter: Artificial intelligence (AI) • Lift the Evidence, Don’t Decide the Risk

Artificial intelligence (AI) can help teams lift known use errors out of scattered evidence before the next design repeats them.

A useful AI workflow starts with retrieval. The model can search complaints, prior usability findings, service notes, training feedback, release notes, and public databases, then cluster repeated patterns by task step, device state, user role, and possible harm.

This reduces manual lookups. It can also reveal patterns that are easy to miss when evidence sits in different folders, reports, spreadsheets, or complaint records.

But AI should not decide which errors matter. A model may merge unrelated events, miss rare but severe scenarios, or turn messy evidence into a clean summary that sounds more complete than it is.

The calm use of AI is to prepare the review, not replace it.

Let AI create a candidate Known Use Error Review List. Then require human review for source traceability, clinical plausibility, harm pathway, design control, and the formative usability scenario that will try to make the error visible before release.

Known errors are not old stories.

They are unfinished design inputs.

Best,
Andreas Walden

Share this with someone designing for clarity.