articles — studio notes

Usability evidence: designing the file, not just the device.

For regulated devices, "users like it" isn't a finding — it's a liability. The human-factors work has to produce evidence a submission can stand on, and that changes how the work is run.

skeelx — 24 aug 2026 · 4 min read

Two processes, or one

The common failure pattern in device programs: design runs on taste and iteration, and then — months later — a usability-engineering file is reverse-engineered for the submission, reconstructing rationale nobody wrote down. It's slow, it's expensive, and it shows: retrofitted files read like alibis. The alternative is structural: run the human-factors work so its natural exhaust is the evidence — use-related risks identified up front, design decisions traceable to them, evaluations documented as they happen with protocols, participants and findings.

two processes — the retrofit Design on taste & iteration rationale lives in conversation Device done The file, reverse-engineered reconstructing what nobody wrote down months later rationale reconstructed backwards — retrofitted files read like alibis one loop — the exhaust is the evidence Use-risk first Requirements trace to risks Formatives — small, frequent Summative confirms stressed, gloved, interrupted — what goes wrong? each decision answers a risk dated: tested · found · changed well-evidenced, not a gamble the usability file — assembled as it happened: risk analysis · trace · protocols & findings · the summative record the device and its file come out of the same loop — cheaper, faster, and considerably more convincing
the retrofit reads like an alibi — the loop's exhaust reads like evidence

What evidence-grade HF work looks like

It starts from use-error thinking rather than preference: what could a stressed, gloved, interrupted user do wrong with this device, and how badly would it matter? Those risks drive the design requirements. Formative evaluations along the way are small, frequent and documented — each one a dated record of what was tested, what was found, what changed in response. By the time a summative evaluation arrives, it's confirming a well-evidenced design, not gambling the program on a first real test. The same rigs and trials that make the product fit real hands produce the paper trail, because they were designed to.

What this asks of your design partner

Documentation discipline that survives audit, protocols written before sessions rather than after, and comfort working alongside your regulatory and quality people — their process is the destination, and the design work should drop into it cleanly. It's the standing philosophy of our medical device work: the device and its file come out of the same loop, which is cheaper, faster and considerably more convincing than either done alone. If your program already has the device but not the file, closing evidence gaps before a submission window is common, unglamorous work — the earlier it starts, the less archaeology it involves.

The wider method behind this is our evidence-loop process — regulated usability is simply the version where the evidence has a second customer.

next

One loop. Device and file together.

Start a project