Notes from
the work.

Your model will change.
Plan the change control now.

The most expensive sentence in a machine learning submission is the one you did not write eighteen months earlier.

Teams building AI into regulated products tend to treat the model as a component that gets finished. It does not get finished. Data distributions move, the population using the product widens, a supplier changes a sensor, and the model that was validated in year one is quietly wrong in year two.

The mechanism that exists for this is a predetermined change control plan, a description, written before authorisation, of the modifications you anticipate making, how you will validate them, and the limits within which you will stay. Get it right and a retrained model ships under an existing authorisation. Get it wrong, or skip it, and every meaningful improvement becomes a new regulatory event.

What teams get wrong

Writing it too narrowly. A plan that only covers retraining on more of the same data will not cover the change you actually want to make, which is usually a new input modality or a widened indication.

Writing it too broadly. A plan that reserves the right to change anything is not a plan, and reviewers read it as one.

Writing it last. By then the architecture has already made some changes impossible, most often because the evaluation pipeline cannot be re-run reproducibly on demand.

What to do instead

Decide, during architecture, what you expect to change and build the machinery for it: a versioned evaluation set, a reproducible retraining pipeline, and performance monitoring in production with a defined trigger. The regulatory artefact then describes something that genuinely exists, which is a much easier conversation than describing something you intend to build.

The engineering cost of this is real but modest, and it is dramatically lower than the cost of discovering, two years in, that your improvement path requires a new submission each time.

Related: Applied AI · Digital health

Usability engineering is not
usability testing.

Most teams discover the difference during a summative study, which is the most expensive possible moment to find out.

Usability testing is an activity: you put a prototype in front of people and watch. Usability engineering is a process that starts before there is anything to test, and it produces inputs the rest of the design is obliged to respect.

The distinction matters because a summative validation study is not really a test of whether users like your product. It is a test of whether you correctly identified the tasks where use error could cause harm, and whether you designed those tasks so the error does not occur. If that analysis was never done properly, the study does not tell you that: it just fails, late, with tooling committed.

The order that works

Use-related risk analysis comes first, and it comes from watching the real environment rather than from a workshop. It identifies critical tasks, the ones where getting it wrong hurts someone. Those tasks then drive the design, and formative studies through development check whether the mitigations actually work on people who are not you.

Summative validation, at the end, should be a confirmation of something you already have strong evidence for. If your summative study is where you learn something surprising, the process ran backwards.

The cheapest change

Almost every use error we see in formative work is fixable in a week if it is found during development, and fixable in a quarter if it is found afterwards. The economics are not subtle. What makes teams skip it is that early human factors work feels like it is slowing down a phase where everyone wants visible progress.

It is worth being blunt with stakeholders about this: the schedule risk is not in the two weeks of research. It is in the six months of rework that the research prevents.

Related: Product research · Product design

Decentralised trials fail on
logistics, not technology.

The platform is rarely the bottleneck. Device provisioning, connectivity and site burden usually are.

When a decentralised study underperforms, the instinct is to look at the software. The app gets a redesign, features are added, and retention moves very little, because the places participants are actually lost were never in the app.

They are in the gap between consent and first data. A device arrives in a box with instructions written for someone who already knows what it is. Pairing fails once and there is no obvious next step at nine in the evening. A wearable stops syncing on a Saturday and the participant concludes, reasonably, that they have done something wrong. None of these appear in platform analytics as a failure. They appear as a participant who gradually stops.

Where to look first

Map the participant path end to end, including the physical parts. In most studies the losses concentrate in two or three specific moments, and they are almost always the same categories: unboxing and setup, the first connectivity failure, and the first week where the burden becomes concrete rather than theoretical.

Then look at the site side. Coordinators absorb an enormous amount of hidden work in decentralised designs: chasing devices, resolving data queries, explaining technology. Site burden functions as a ceiling on recruitment that no amount of participant demand can lift.

The uncomfortable implication

Fixing this is unglamorous. Better packaging. A support path that works out of hours. Fewer required interactions in week one. A provisioning process that assumes something will go wrong. None of it demos well, and all of it moves retention more than another feature will.

Related: Clinical trials & evidence · Life sciences

Fidelity is a budget.
Spend it in three places.

Realism does not produce learning. Specific realism, in the moments that carry the decision, produces learning.

The default failure in XR training is spreading fidelity evenly. Everything looks quite good, nothing is exact, and the simulation trains a general impression of a procedure rather than the judgement it actually requires.

Fidelity is better understood as a fixed budget spent against a performance target. In our experience it belongs in three places, and almost nowhere else.

One: the cue the decision depends on

Every procedure has a small number of moments where an expert notices something a novice does not. Whatever carries that signal (tissue behaviour, an audible change, a resistance profile) needs to be right. This is usually a narrow, expensive slice of the build and it is the slice that determines whether the training transfers.

Two: the consequence of getting it wrong

Learners need to see failure play out. Simulations that quietly correct mistakes, or end the scenario when one occurs, remove the most valuable part of the experience.

Three: the interaction that would otherwise break immersion

Not visual realism, interaction plausibility. If picking up an instrument requires a fight with the controller, cognitive load goes into the interface instead of the procedure.

Everything else, background geometry, ambient detail, the rest of the room, can be stylised without measurable cost to outcomes. Teams find this hard to accept, because the parts you deliberately under-build are exactly the parts that show up in a demo.

Related: Spatial computing & XR · Training & simulation

Design the recovery,
not just the cycle.

Nobody specifies what happens after a fault, which is why the specialist ends up living next to the machine.

Automation specifications describe the nominal cycle in great detail and the fault path in a sentence. In deployment the ratio inverts: the nominal cycle takes care of itself, and the economics of the cell are decided by how quickly an ordinary operator can get it running again.

This shows up as a gap between modelled and actual throughput that nobody can explain. The cycle time is correct. The uptime assumption was not, because it was calculated from mean time between failures without ever measuring mean time to recovery.

Two questions worth asking early

Who recovers this? If the answer is a specialist, the machine has a hidden staffing requirement. Design so a trained operator can clear the common faults without opening anything that needs realignment afterwards.

How does it know where it is? Recovery is mostly a state problem. A cell that can determine its own state after an unexpected stop can resume. One that cannot needs a human to reason about it, every time.

Measure the right number

Run the rig long enough and with real consumables to produce a fault rate and a recovery time, both distributions, not averages. Throughput models built on those two numbers survive contact with a customer site. Models built on nominal cycles do not, and the difference is usually discovered after a purchase order.

Related: Physical AI & robotics · Industrial automation

Nobody decides to become
a medical device.

It happens one feature request at a time, and it is usually marketing copy that finishes the job.

A wellness product tracks a signal. Then it flags an unusual reading. Then it suggests the user might want to speak to someone. Each step is small, each is reasonable, and somewhere in that sequence the product started making a claim that requires evidence and, quite possibly, authorisation.

What makes this dangerous is that it rarely arrives as a decision. No meeting is held about becoming a regulated product. The feature is prioritised, the copy is written, and the position is discovered later, often by someone outside the company.

A practical test

Write down, in one sentence, what the product tells the user and what you expect them to do about it. If that sentence implies detecting, diagnosing, or influencing treatment of a condition, you are in regulated territory regardless of what the marketing site says. Intent counts, and so does what a reasonable user would infer.

Deciding on purpose

The regulated path is often the right choice. It creates defensibility, opens reimbursement conversations and raises the barrier for competitors. What is never right is arriving there by accident, with an architecture built for a wellness product and a launch date already announced.

Have the conversation early, while the claim is still a choice rather than a consequence.

Related: Digital health · Consumer health