Designing safely
under constraint.

A major overhaul. A regulated product. An immovable deadline.

navify® Digital Pathology (nDP) is a web-based slide image viewer and case management platform used by pathologists, histotechnicians, and lab administrators. It's part of an IVD system when paired with Roche scanners, which means usability isn't a nice-to-have. It's a regulatory requirement.

nDP 3.0 was a major application-wide UI overhaul. The scale of the changes had real usability implications. I transitioned into the UX lead role for this release in early 2025. This case study isn't about the redesign. It's about what happened when we tried to validate it.

Two locks. Neither moving.

Two things were fixed before I came into this role.

Roche's Blue Multiplier system tied the nDP 3.0 release to company-wide bonuses. There was no missing this milestone.

The development team had already planned and started the final product increment. Significant reductions had already happened to hit the deadline. Scope was changing week to week. There was no room left.

Validate safety and effectiveness. By end of 2025.

We reverse-engineered the validation activity timeline from the release date. Because there had been scope changes since our last study in mid-2024, we couldn't go straight to summative. We needed a formative to de-risk it first, then a pre-summative before we committed. Any risks we found would need mitigations. Any scope changes at that stage would almost certainly impact the release.

Six critical risks. Two that couldn't fit in scope.

We ran the formative and surfaced six critical use-related risks. Four could be addressed through UI enhancements, finding ways to remove features and add targeted scope back in. Advocating for any scope changes at this stage meant explaining risk in detail, in front of the right stakeholders, under immense pressure.

Eventually we hit a scope limit. Two critical risks couldn't fit. They'd need to be mitigated through training.

Here's where it got complicated.

The two training-mitigated risks meant we needed finalized training materials to test with in our summative. Per FDA guidelines, we needed to simulate realistic training conditions in a summative study. If training changed significantly after the summative, it would invalidate our results.

But per GCS's MQMS process, final training materials aren't delivered until Milestone D, a quarter into 2026. Three months after our summative needed to happen.

Get GCS in the room. Then build what didn't exist.

The first move was to get GCS in the room. We partnered with them to prioritize accelerated training storyboard content for the critical workflows. This required multiple meetings and escalations. We were asking GCS to start their work earlier than planned, with significant implications for their own planning. Project leadership, GCS stakeholders, and GCS leadership all agreed after some convincing.

But GCS could only commit to storyboards by our pre-summative. Not final materials.

The proposed plan, taken to Quality, Regulatory, Risk, Business, and Project Leadership for sign-off: UX would create representative high-fidelity prototypes of the critical training flows. Those prototypes would go to the vendor alongside the storyboards. GCS and the vendor would check final materials against our prototypes at the end, ensuring alignment.

Everyone signed off. GCS still owned final training. We just inserted a reference standard they'd build to. That guarantee was what made everything that followed possible.

No model to copy. Under a month to build.

Before we could build the prototypes, we had to understand what we were actually building. nDP 3.0 training didn't exist yet. We researched existing nDP training on Cornerstone, got demos from GCS on Synthesia's functionalities and format requirements, and defined what the new training would need to look like to be testable in a study.

A bonus: going through this process meant we could push the training toward the best possible solution, not just an adequate one.

Working in parallel with storyboards as they were completed, we built Figma prototypes, iterating through internal review and stress testing before anything went near a study participant. The storyboard defined the content. The prototype made it testable.

Pre-summative. Then summative. Both passed.

We ran the pre-summative with the prototype training materials. Eight use errors, all non-critical. That was the first signal the mitigations were holding. Root cause analysis with Risk and Medical SMEs informed final updates to the training prototypes. We communicated changes to GCS and locked the summative plan.

What I learned.

The lesson on formative timing isn't "run studies earlier" in the abstract. It's that formative research needs to be scoped into the release plan before scope is locked, not treated as something that fits into available capacity. For 2026 I built a UX roadmap that did exactly that: formative testing locked into budget and timeline before scope was planned.

Separately, I escalated the MQMS process gap itself to my manager, who took it to GCS functional leadership. They're actively working on a resolution. The brokered solution we built for this project may end up not being necessary for future ones.