Why modernization projects get burned

The typical legacy device story is familiar. The product was cleared years ago. It still sells, clinicians still trust it, and the install base is healthy. But the display components are approaching end of life, the embedded operating system is out of support, and the interface looks like 2012 because it shipped in 2012. Someone writes a business case for a refresh. The scope sounds cosmetic: cleaner screens, updated branding, improved hierarchy, maybe a move from buttons to touch.

Then the project starts, and small design decisions begin to accumulate. A control moves because the new display is a different size. A confirmation step disappears because the old sequence felt clumsy. An alarm banner gets restyled. Each decision seems reasonable by itself. Months later, regulatory asks the question nobody built into the plan: did any of this change a critical task?

When the team cannot answer with evidence, the possibility of new human factors validation becomes much harder to dismiss. The budget can jump, the timeline can stretch, and a project that was sold internally as a refresh turns into a much larger program. I have seen this happen to well-run teams. The design work was rarely the problem. The problem was that nobody maintained a running answer to the critical-task question as the design changed.

What the May 2026 guidance actually changed

The final guidance organizes recommended submission content into three Human Factors Submission Categories. The categories are useful, but they are easy to oversimplify.

One distinction matters: this guidance addresses the human factors information recommended in a marketing submission. It does not decide whether a device modification requires a new marketing submission, and it does not remove design verification, validation, or documentation obligations.

A UI change does not lead to one automatic outcome

The evidence determines which path the submission follows.

Decision Point D is where legacy history becomes useful

For teams updating an established device, Decision Point D may be the most consequential part of the framework. It applies when the use-related risk analysis identifies a new or affected critical task. FDA then considers three factors: the interface’s history of use with the intended users and environments, the complexity of the interface, and the adequacy of existing risk controls.

That gives an established device something a new product may not have: years of relevant field experience. Complaint data, MDR trends, support records, CAPA activity, training history, and prior human factors work may all support the rationale when they are tied to the affected tasks and risks. But none of this is automatic grandfathering. An absence of complaints alone does not prove that validation data are unnecessary.

The history becomes useful when the evidence is connected: the task, the risk, the control, the amount of field exposure, and the relevant complaint or formative findings. That traceability is what turns records into objective evidence.

The real question is which changes touch critical tasks

A critical task is one in which a use error could cause or contribute to serious harm. The category framework depends heavily on whether a modernization introduces a new critical task or impacts an existing one. That means the project needs an honest critical-task inventory before the visual redesign begins.

This is where design judgment earns its keep, because the line between changing the interface and changing the task is not obvious from a redline. Updating typography, contrast, and visual hierarchy may leave the interaction intact, but it should be evaluated rather than assumed. A new hierarchy can change what users notice first. A smaller label can slow recognition. A new color system can change the apparent urgency of an alarm.

Replacing a physical knob with a touch slider changes the physical interaction. Collapsing a two-step confirmation into one changes the sequence. Moving a stop control to another corner can matter to a nurse who has reached for it from muscle memory for eight years. Rehosting the same interface on new hardware may change nothing, or it may introduce latency, glare, touch sensitivity, or viewing-angle problems that affect how a critical task is performed.

The safest teams classify each proposed change while it is still being designed. Some changes do not affect human factors considerations. Some alter the interface but leave critical tasks intact. Others genuinely impact a critical task and need to move through Decision Point D. The important part is that the category becomes a deliberate decision, not a surprise at the end.

A paper trail is not paperwork. It is the strategy.

A current use-related risk analysis is the backbone of the argument. It should reflect the device as it actually ships, not the version described in an old design-history file. The critical-task inventory should include upstream and downstream effects, because a change in one screen can influence a later task even when the later screen did not change.

Focused formative evaluation is equally important. The goal is not to run broad usability sessions simply to say that testing occurred. Each study should answer a specific question. Did moving the stop control affect recognition under time pressure? Did the new touch target work with gloves? Did the simplified confirmation sequence increase accidental acceptance? Did the redesigned alarm hierarchy change response?

When those questions are documented as the design evolves, the Category 2 rationale becomes a byproduct of good product development. When formative work is treated as optional polish, the rationale has to be reconstructed from memory at the end, and it is usually much thinner.

The strongest rationale is built change by change, while there is still time to adjust the design or release plan.

Plan the project so validation is a decision, not an ambush

A practical modernization sequence looks like this:

1. Baseline the current device. Pull the current use specification, use-related risk analysis, known use problems, complaint trends, and prior human factors evidence.

2. Rebuild the critical-task inventory. Confirm which tasks are still current and identify any upstream or downstream dependencies.

3. Define the constraints. Decide which interactions must remain stable and give that list to the design team just as you would give them hardware or software constraints.

4. Map each design change. Record whether it influences perception, cognition, physical interaction, task sequence, training, labeling, or a risk control.

5. Run focused formative evaluations. Test the changes that carry uncertainty while the design can still move.

6. Sequence the releases. Keep lower-risk modernization changes together. Put changes that genuinely alter critical tasks into a release where the validation work is intentionally scoped, budgeted, and scheduled.

7. Ask FDA when the evidence is genuinely unclear. The final guidance specifically points submitters toward a Pre-Submission when they are uncertain whether a rationale is appropriate.

The honest caveat

If the modernization exists because the current interface is producing use errors in the field, the goal should never be to engineer around a study. A well-planned validation study on a redesigned workflow that addresses a known use-error pattern is money well spent. The same field history that reveals the problem can help define the scenarios, users, and conditions that matter most.

The value of the new framework is not that it makes validation disappear. It makes the decision more explicit. Teams can understand which changes are likely to need new validation evidence and attach the budget and schedule to those changes from the beginning, rather than discovering the answer in month nine.

The August deadline matters. The discipline matters more.

The August 1 transition has received much of the industry attention, especially for submissions already in flight. The durable change is the logic behind it. FDA has now published the decision points, category definitions, recommended content, and examples a reviewer can use when evaluating a modernization submission.

That transparency favors teams that do the upstream work: a current risk analysis, a maintained critical-task inventory, targeted formative evaluations, and a change log that maps design decisions to task impact.

A device that looks like 2012 can look like 2026 without automatically requiring a new human factors validation study. But that conclusion has to be earned, change by change, with evidence. The new guidance did not make the claim easier to make. It made the evidence behind the claim much clearer.

Planning a legacy medical device modernization? A short discovery phase can clarify which workflows can be refreshed safely, which changes need focused formative testing, and where validation risk belongs in the release plan. Areteworks offers a free 30-minute medical device UX review.  Contact Areteworks

About the author

Steven Liu has designed FDA-regulated medical device interfaces for more than 25 years, including systems used in critical care, imaging, therapy, and scientific instrumentation. Areteworks specializes in user research, workflow design, interface development, formative usability evaluation, and human factors documentation for medical devices and scientific instruments.

Primary regulatory sources

FDA final guidance landing page  |  Final guidance PDF  |  eSTAR August 1, 2026 update  |  July 22, 2026 FDA town hall

Editorial note: This article is educational and reflects a UX and human factors perspective. Device-specific regulatory decisions should be made with the appropriate regulatory and quality teams