Design Leadership · Process
A shared language for building
The team kept jumping to solutions before it understood the problem. I built a phased framework with clear gates that gave everyone the same expectations for where a feature is — so a vague idea still counts as progress, and circular meetings became real decisions.
- Context
- I lead UX for navify Digital Pathology (Roche), where building a feature means business, engineering, and design agreeing — in a regulated, clinical product where getting it right matters.
- Problem
- We kept “rubber-banding”: designing before we understood the problem, hitting what we hadn’t considered, and backing up. Discovery was a hard sell, and feature meetings had become hour-long design-by-committee sessions that went nowhere.
- What I did
- Built a shared feature-development framework — Understand → Explore → Materialize → Develop → Validate — where each phase has one clear goal and a gate to pass, with explicit expectations for what to focus on (and what to ignore) at that stage.
- Outcome
- Progress is visible on every call; meetings became decision points instead of debates; and discovery is finally defensible, because everyone knows what each phase is for.
Role: UX Design Lead, navify Digital Pathology (Roche, via Concord).
The problem
Building a feature here means business, engineering, and design all agreeing — and we kept getting in our own way. We’d jump ahead to designing a solution before we actually understood the problem, then hit something we hadn’t considered and have to back up. Start, stall, restart.
The friction always showed up at discovery. Asking for time to understand a problem drew the same reactions every time: “Don’t we have enough research already?” “We know the problem — why aren’t we designing yet?” And every time we pushed ahead anyway, designing the solution surfaced how much about the problem we still didn’t know.
Meanwhile the meetings meant to move features forward had turned into hour-long design-by-committee sessions — stakeholders asking conflicting questions, no shared sense of what we were even trying to decide, everyone leaving without progress.
What I built
A shared framework for how a feature moves from idea to shipped — five phases, each with a single job and a gate it has to clear before the next begins:
- 01Understand
What problem are we solving? Not solutions yet — a clear, agreed problem statement worth solving.
- 02Explore
Co-create and test concepts with users. Is the idea feasible and worth doing? — not how every detail or edge case works.
- 03Materialize
Finalize the design and prepare it for development. Now the mechanics, states, and edge cases matter.
- 04Develop
Build and QA, with the problem and the design already settled behind it.
- 05Validate
Confirm it works as intended — summative testing — before it’s called done.
The point was never the diagram — it was the shared expectations the gates made explicit.
Each phase has one job, and the gate between it and the next is a goal the team agrees to reach before moving on — so “where are we” always has a concrete answer.
What made it work
Two things did the heavy lifting.
Each phase sets expectations — so a vague idea still counts as progress. When everyone knows we’re in Understand, no one’s frustrated that there’s no solution yet; that isn’t what the phase is for. In Explore, we don’t derail chasing edge cases. And because every phase has a gate — a clear goal we agree to reach before moving on — even fuzzy work is visibly advancing, and we can always name what “done” looks like for the stage we’re in.
We track our assumptions as we go — and back them with evidence. Through every phase we write down what we’re assuming. That makes visible what we actually know versus where we have a hunch but no data. Paired with the research repository, it’s the difference-maker: an assumption that used to be a shrug is now something we can check against real evidence — or flag as a gap worth a study. (That repository is its own story — Building the research memory.)
Outcome
- Progress on every call. Feature meetings went from hour-long design-by-committee sessions to updates on progress and moments to make decisions.
- Discovery is finally defensible. “We’re in Understand” is an answer the whole team accepts, because the framework makes clear why that phase earns its time.
- One shared language. Business, engineering, and design now agree on where a feature is and what happens next — which is what ended the rubber-banding. The framework is now the backbone the team’s broader product process is tracked against.
What I learned
The hard part of cross-functional work usually isn’t the work — it’s that everyone’s holding a different idea of what should be happening right now. Naming the phase, and the gate, fixed more than any single process step did. If I did it again, I’d introduce the assumption-tracking from day one; it’s the quiet piece that turned the framework from a nice diagram into something with teeth.
Some specifics are abstracted for confidentiality.