Redesigning a virtual care platform for scale

Pager provides a virtual care platform and nurse services to health insurers. The initial model was built for a single payer. With the addition of two more payers (for a total of three) and thousands of daily live chat interactions, the underlying infrastructure had not adapted to meet demand.

Each new insurance company required a completely separate engineering build. This forced nurses serving multiple insurers to run several systems at once during consultations, switching windows while a patient waits, creating patient safety risk.

The business needed an architecture that can scale without rebuilding from scratch. The nurses needed a system that doesn't actively complicate their work. Those two problems turned out to be the same problem, and that realization became the foundation for the redesign.

Pager’s virtual care platform and nurse services are designed to serve health insurers. The first version of this platform was originally developed as a single-payer model. Since then, two additional health payers have been added, with thousands of daily live chat interactions. The original design for the backend has not scaled to support the growth in demand.

With each additional payer, the engineers were required to develop an entirely separate build. As such, nurses who served multiple payers would need to operate and switch between several different systems simultaneously during a consultation; switching between windows on a computer while waiting for a patient to respond to questions creates a patient safety issue.

The business needed an architecture that could scale up or down without requiring complete rebuilds. Nurses needed a system that did not add complexity to how they worked. These two needs ended up being the same problem, which ultimately led to the development of a revised solution.

Every new client required a separate engineering build. Nurses serving multiple insurance companies kept several systems open simultaneously, switching mid-consultation. Along with the additional That's not inefficiency. That's a patient safety risk.

The business needed a platform that could scale across clients without rebuilding from scratch. The nurses needed a system that didn't actively complicate their work. Those two problems turned out to be the same problem, and that realization became the foundation for the redesign.

This 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.

To reconcile that with the need for iteration, I built a product vision document (a north star) early in the process. Engineers could use it for high-level estimation and shared directional understanding, while the actual feature-level designs were revised immediately before implementation began, incorporating what usability testing had revealed in the interim. The north star held the overall structure. The details stayed revisable until the last responsible moment.

That constraint shaped every decision that followed.

Problem: Nurses managed five to six simultaneous chats in separate tabbed queues. Incoming messages in other tabs surfaced only as a small notification badge, which was easy to miss at high volume. In shift debriefs, 12% of sessions mentioned at least one missed patient response in the prior week.

Empathy mapping with nurses identified an issue beyond the notification gap: Nurses had spent years developing a 'muscle memory' with their current workflow using the tabbed layouts. The idea of a new information architecture introduced both a learning curve and a physical adjustment of their behavior to interact with the new design.

What went wrong? I designed the queue, but I did not create the transition to the queue. A nurse explained this very well during a usability study: "I know this is better... but my hands keep going to the wrong spot."

The System Usability Scale (SUS) dropped from 64 to 60 at launch. Although I had anticipated an improvement with the accurate mental model, I realized after conversation with the nurses that building habits required a path between old and new behaviors — a bridge I failed to create.

Course correction: 30-day fallback to classic mode, two weeks of 15-minute shift walkthroughs, and a four-week data-gathering window before drawing conclusions.

Results: By the fourth week, the SUS rebounded back to its pre-launch levels (64), and by month five, it reached 88. Critical alert misses decreased from 11% to 6.5%. Average response times reduced from 110 seconds to 88 seconds.

Observation: As suggested by the nurse empathy mapping sessions, nurses needed a transition plan before the new product launched, including fallback options and early support to help them learn and adjust proactively, rather than as a reaction to problems.

Problem: Encounter actions such as transfer encounter and end encounter opened as full-screen modals, obstructing the chat history completely. Nurses needed to reference the conversation while filling out those forms. Since they could not see both at once, 56% had developed a workaround: they drafted notes in a separate application with the chat visible, then pasted them into the modal afterward. The product failed its users visibly enough that they built their own fix.

Testing: In moderated usability testing, 4 of 10 nurses documented at least one incorrect piece of information in the modal condition. The errors were not edge cases. They were systematic, a predictable consequence of asking someone to recall information they could no longer see.

Solution: A full-height contextual side panel replaced all modals. The encounter history remained visible throughout documentation. Nurses referenced and documented simultaneously instead of sequentially.

What went wrong: By the time testing confirmed this, engineers were halfway through building the modal. Under the north star model, feature-level designs were meant to be finalized before implementation started, but this test ran later than it should have, after estimates had been committed. Revising the design mid-build was disruptive and costly.

After conversations with the product manager and engineers, stating a 40% documentation error rate was not a tradeoff, they agreed to the revision. But the more important failure was not having an explicit agreement with engineering about what kinds of changes were acceptable at each stage, and what the process would be when testing surfaced a necessary one. That conversation should have been the first one. Instead, it happened under pressure, mid-build.

Outcome: No documentation errors were found in post-launch testing.

Insight: The north star approach worked, but it depended on feature-level designs being finalized and tested before implementation began on that feature, not concurrently. The gap here was a sequencing failure, not a methodology failure. If the agreement about that sequencing had been explicit and documented upfront, the mid-build revision either would not have happened or would have had a clear path to resolution.

In the past, all clients needed a fully customized (engineered) solution in order to accommodate their unique workflow processes; unique patient information systems; and unique clinical protocols. Nurses were also continually juggling through an entire suite of separate applications including DrChrono for documentation purposes; ClearTriage and 5 Minute Consult for clinical decision-making; as well as Slack, Google Chat, ZenDesk and Five9 for communication; as well as Confluence, Jira and Google Docs for documentation and management of policies/procedures/workflows. All of this would cause significant cognitive load — which while inconvenient, is dangerous to patient care.

The old setup required a custom engineering build for every new client, since each one had different workflows, patient data, and clinical protocols. On top of that, nurses were constantly switching between a sprawling stack of disconnected tools — DrChrono for documentation, ClearTriage and 5 Minute Consult for clinical decisions, Slack, Google Chat, ZenDesk, and Five9 for communication, and Confluence, Jira, and Google Docs for protocols and workflows. Adapting to different payer requirements on top of all that created serious cognitive load — and that level of mental overhead became a patient safety risk.

Research: A card sort and first-click test with 10 nurses uncovered the root issue: clinicians think in tasks, such as communication, member lookup, clinical reference, documentation, and handoff. The platform was organized around system objects like "plugins." That's an engineering concept. It doesn't map to anything nurses actually do.

No one had documented the clinician's workflow before this. The research was the first time. It became the foundation for rebuilding the information architecture around how nurses actually work, not how the database is structured.

Solution: Two layers. A Core that never changes (member profile, chat feed, documentation panel, plugin menu) and Configurable components toggled on or off per client. A Latin American client's admin panel remained off until their backend integration was complete, then activated without an engineering sprint. One codebase. Every client gets a tailored experience.

Outcome: Four payers, previously four separate engineering builds. After: one nurse dashboard serves members across all of them.

Insight: Component documentation standards should exist before the first client is onboarded, not under the second client's deadline. The reactive approach required the same design effort as an upfront one. It just cost weeks of onboarding time that compounded under pressure. The north star would have been the right place to establish this standard early; it wasn't used that way.

These weren't three separate failures. They were the same failure on three different surfaces: treating implementation as something that happens after design is done, rather than a constraint that design has to account for.

In each case, the right problem was being solved. What wasn't being designed were the conditions under which the solution could actually land.

Use the north star to establish standards, not just direction. The product vision document served its purpose for engineering estimation and alignment. It should also be the place where component documentation standards, transition plans, and rollout structures are defined, before the first client ships, not under the second one's deadline.

Make the feature sequencing agreement explicit. The north star model works when feature-level designs are finalized and tested before implementation starts on that feature. That sequencing needs to be documented, agreed upon, and referenced when pressure builds to move faster. The conversation should happen before a single estimate is committed.

Run adoption modeling as part of design. For any change that disrupts physical habits, model the transition before launch. Design the fallback option and support structures in the same sprint as the feature itself. Set stakeholder expectations around measurement windows before the feature ships, not after a metric drops.