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 came on board, it split into three separate systems instead of one. I redesigned it solo, inside a waterfall org with minimal research resources, into a single modular platform that scales across clients without a rebuild each time.
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
PROBLEMPager's platform was built to work for one big client at a time. When two more clients came on board, the system didn't grow into a shared platform. Each client got its own fully separate version of Pager, with its own command center, workflows, tools, patient data, and configuration. Every new client meant another full engineering build from scratch.
For nurses, that meant logging into multiple platforms at once, usually in separate browser tabs, each with its own command center, patient queue, chat tools, and way of doing things. When a new patient request came in, a nurse had to switch between platforms just to figure out which client it belonged to before they could even start providing care.
It was closer to working in three different hospitals at once, each with its own software, rules, and patients, and constantly switching between them. That made the job slow, exhausting, and error-prone, and it put patients at risk.
The business needed a platform that could scale across clients without a rebuild each time. Nurses needed a system that didn't work against them. Those were 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 (a "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 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.
I ran a card sorting exercise and a first click test with 15 nurses to see how they naturally group their tasks and tools, and compared that against how the product was actually organized.
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.
To check whether the new grouping actually helped people find things faster, and not just whether it matched their instincts in a card sort, I ran a tree test with 30 people on each version.
- Old, flat menu: ~65% average task success, ~71% directness
- New, grouped menu: ~87% average task success, ~90% directness
The new structure performed better across almost every task, with the biggest gains on the Communication and Workflow Action tasks. That confirmed the card sort groupings weren't a fluke, they held up under a harder test.
Turning a Design Insight Into a Platform Strategy
The card sort showed how content should be grouped for one nurse supporting one payer. I still needed to solve for a nurse working with multiple payers at once, 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 need to change based on the client's rules?
That reframed the problem. Instead of one product with one fixed layout, client organizations sit at the top level, and the system uses that to know which client a patient belongs to and adjusts the tools, information, and workflow underneath automatically.
The resulting structure has two parts:
- Core (same for every client): patient encounters, messaging between agents, patient profile, tasks
- Configurable (on or off per client): support tools and workflow steps that match each client's specific rules
This is the core idea behind the project: the four groups nurses agreed on in the card sort became the actual blueprint for what could be customized. Communication and the core workflow never change. Support tools, and some workflow steps, are what flex depending on the client.
A Latin American client's admin panel stayed off until their backend integration was ready, then turned on with zero engineering sprint.
Result: one codebase serves all payers. Four separate engineering builds became one platform, with the same user experience preserved for each client.
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% had built their own workaround: drafting notes in a separate app with the chat visible, then pasting into the modal. In moderated usability testing, 4 of 10 nurses documented incorrect information in the modal condition. Not an edge case, a systematic error.
I replaced the 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) comparing the modal against the side panel on the same documentation task. The modal's own fields tested fine in isolation, the failure was structural: because the modal covered the transcript, 9 of 30 participants had to close or reposition it mid-task just to re-read what the patient said before writing their note.
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, and revising mid-build was disruptive. But a 40%+ documentation error rate wasn't a tradeoff anyone would accept, and engineering agreed to the revision.
Result: zero documentation errors in post-launch testing. The Maze study confirmed why: 65% less time on task and hesitation nearly eliminated, not just fewer errors.
Takeaway: the real failure wasn't the design gap, it was that we never agreed upfront on 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.
The new queue was more accurate, but not more familiar. Nurses had years of muscle memory built around tabs, and 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 doesn't automatically become an adopted one.
- Ship a fallback before you ship the change, to bridge 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
The common failures across all three core design decisions was treating implementation as something that happens after design is finished, instead of 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 nobody built the transition plan until launch made it unavoidable
In each case I was solving the right problem. What I hadn't designed were the conditions that would let the solution 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