Role
Sole Product Designer
Team
1 PM, 2 Engineers
Timeline
2023 - 2024 (1 year)
TL;DRPager's virtual care platform was built for one insurance client. When two more clients came on board, the system didn't scale: nurses juggled multiple tools mid-consultation, and engineering rebuilt the product from scratch for every new client. I redesigned the platform end-to-end, solo, inside a waterfall org with minimal research access.
IMPACTEnterprise client renewal: Contingent on this redesign, renewed
New payers onboarded: 3 (Pacific Northwest health plan, Puerto Rico insurer, Latin American health system)
Covered lives: 23M on one platform, no per-payer rebuilds
Enterprise users: 20 to 6,000
Cost savings: $210 per clinical chat (actuarially verified)
Usability (SUS): 64 to 88 over 5 months
PROBLEMEvery new insurance client meant a separate engineering build. Nurses serving multiple payers kept several systems open at once, switching between them mid-consultation, creating inefficiencies and patient safety risks.
The business needed a platform that could scale across clients without rebuilding each time. Nurses needed a system that didn't actively work against them. Those turned out to be the same problem, and solving it became the foundation of the redesign.
CONSTRAINTSThis was solo IC design work inside a waterfall engineering organization with limited research access, pre-signed client deals, and a culture that required justifying the existence of user research at each step. No design team. Stakeholder alignment happened through documentation and evidence, not consensus.
My approach: Build a product vision document ("north star") early for engineering estimation and shared direction, then keep feature-level designs revisable until the last responsible moment, updated with real usability findings as they came in.
CORE DESIGN DECISIONS1. Modular Information Architecture: Making Multi-Payer Possible
Nobody had ever documented how nurses naturally think about their own work. The product had been organized around how engineers built it, not around how nurses actually do their jobs. Before we could design something that scales, we needed to understand the people using it.
I ran a card sorting exercise and a first click test with 15 nurses to learn how they naturally group their tasks and tools. This let us compare how the product was organized against how nurses actually think.
What we learned from the card sort: Two things stood out. First, nurses almost always grouped "transfer encounter" and "end encounter" together (80 percent agreement or higher). But in the existing product, these two tasks were buried in one long list with everything else. Second, nurses consistently grouped live chat, voice calls, video calls, and file sharing together as "communication." The existing product only grouped live chat this way and scattered the rest.
Testing the new structure: Next we ran a tree test with 30 people on each version, to check whether the new grouping actually helped people find things faster, not just whether it matched their instincts in a card sort.
Next we ran a tree test with 30 people on each version, to check whether the new grouping actually helped people find things faster, not just whether it matched their instincts in a card sort.
- Old, flat menu: ~65% average task success, ~71% directness
- New, grouped menu: ~87% average task success, ~90% directness
The new, grouped structure performed better across almost every task, with the biggest improvements on the Communication and Workflow Action tasks. This mattered because it confirmed the groupings from the card sort were not just a fluke. They actually helped people complete tasks faster and with fewer wrong turns.
Turning a Design Insight Into a Platform Strategy
The card sort revealed how content should be grouped for one nurse supporting one payer, but I still needed to solve for the dynamic content involved for one nurse working with multiple payers.
So I asked a follow up question with 10 more nurses: which of these groups stay exactly the same no matter which client you're helping, and which ones need to change based on the client's specific rules?
Rather than thinking of this as one product with one fixed layout, having multiple client organizations sit at the top level, so the system knows which client a patient belongs to and adjust the tools, information, and workflow shown underneath automatically.
The resulting two part structure
Core (the same for every client): patient encounters, messaging between agents, patient profile, and tasks.
Configurable (turned on or off depending on the client): support tools and workflow steps that match each client's specific rules.
This is the key idea behind the whole project: the four groups nurses agreed on in the card sort became the actual blueprint for what can be customized. Communication and the core workflow steps never change. Support tools, and some workflow steps, are the parts that flex depending on which client a nurse is working with.
A Latin American client's admin panel stayed off until their backend integration was ready, then activated with zero engineering sprint.
Result: One codebase serves all payers. Four previously separate engineering builds became one platform while retaining the same user experience.
2. Side Panel Over Modal: Keeping Context Visible
Actions like transferring or ending an encounter opened as modals that blocked the chat history. Nurses needed the conversation visible while documenting. 56% of nurses built their own workaround: drafting notes in a separate app with the chat visible, then pasting into the modal. In moderated usability testing with our own nurses, 4 of 10 nurses documented incorrect information in the modal condition, a systematic error, not an edge case.
I replaced all modals with a full-height contextual side panel, so nurses could reference and document at the same time instead of sequentially.
To validate the fix at scale, I ran a second, unmoderated study through Maze (N=30 per variant) directly comparing the modal against the side panel on the same documentation task. The modal's own fields tested fine on their own; the failure was structural. Because it covered the transcript, 9 of 30 participants had to close or reposition the window mid-task just to re-read what the patient said before writing their note, a workaround the interface never intended to require. The side panel avoided this entirely by keeping the conversation visible the whole time.
What went wrong: Testing confirmed this after engineers were already halfway through building the modal. The design and testing sequence had slipped past the point where changes were cheap. Revising mid-build was disruptive, but a 40%+ documentation error rate wasn't a tradeoff anyone would accept. Engineering agreed to the revision.
Result: Zero documentation errors in post-launch testing, and the Maze study confirmed the mechanism: cutting time on task by 65% and nearly eliminating hesitation, not just closing the error gap.
Takeaway: The bigger failure wasn't the design gap. It was not having an explicit agreement upfront about when in the process changes were still acceptable.
3. Stacked Queue: Making Hidden Patients Visible
Nurses managed 5 to 6 concurrent chats spread across 3 tabs (Team Chats, My Chats, Follow-ups) with no new-message indicator. Finding a new message meant manually checking every tab.
12% of shadowing session debriefs cited a missed patient response due to lack of signals.
I redesigned the interface so every open chat surfaces in a single queue, ordered by wait time. Nothing sits hidden.
What launch revealed: The new queue was more accurate, but not more familiar. Nurses had years of muscle memory built around tabs. Accuracy doesn't automatically become habit; that transition needed its own plan.
Course correction:
- 30-day fallback to classic tabbed mode, available on request
- Two weeks of 15-minute walkthroughs built into shifts
- A 4-week data collection window before drawing conclusions
Result: SUS score of 88 by month 5.
Takeaway: A more accurate design does not automatically guarantee an adopted one.
- Ship a fallback before you ship the change to create a bridge between existing muscle memory and new habits
- Put adoption support in place before problems surface rather than waiting for nurses to raise them
- Give behavior time to catch up before treating early data as a verdict
The Pattern Across All Three
These weren't three separate failures, but one failure appearing on three surfaces: treating implementation as something that happens after design is finished, rather than a constraint design has to account for from the start.
Modular IA: Component standards got negotiated under a client deadline instead of set upfront.
Side panel: Testing surfaced the right finding, after estimates were already locked.
Stacked queue: Adoption risk was visible in research, but transition design wasn't built until launch made it unavoidable.
In each case, the right problem was being solved. What wasn't being designed were the conditions under which the solution could actually land.
LEARNINGSWhat I'd do differently
Use the north star to set standards, not just direction
Component documentation, transition plans, and rollout structures belong in the vision doc from day one, not improvised under the next deadline.
Make the design and build sequencing agreement explicit
Document and get buy-in on when feature designs must be finalized relative to implementation, before a single estimate is committed.
Design adoption, not just the feature
For any change that disrupts existing habits, model the transition, build the fallback, and set stakeholder expectations on measurement timelines, in the same sprint as the feature itself.
Made with Bullet