Case Study / Collective Health
Scaling Medical Plan Creation at Collective Health
Collective Health had no scalable way to create medical plans. I led the design of an internal platform that replaced a fragmented manual workflow and became where all plans are created and stored.
At a glance
The company and the team
Collective Health is a health benefits platform that manages medical, dental, vision, and pharmacy coverage for large employers. The Plan Structure Launch and Design team, 27 ops specialists, is responsible for creating customized medical plans for over 60 clients, each managing an average of 4 to 5 plans.
Before the Plan Authoring Suite (PAS), creating a single medical plan meant opening a 20-tab Google Sheet, filling out 3 specific tabs by hand, opening Terminal, and running a custom script to output the JSON and CSV files the backend needed to process the plan. PSLD team members are operations specialists, not engineers. They were required to do both jobs.
A workflow that could not scale
The workflow worked when Collective Health had a small number of clients and plans. As the business grew, it did not scale. Errors were hard to catch and harder to trace. Troubleshooting consumed hours that should have gone to plan accuracy.
Training new PSLD team members was a lengthy process. Ops specialists had to learn a quasi-technical workflow that required running code they did not write and did not fully understand.
The company needed a purpose-built tool for medical plan creation. What existed instead was a patchwork of spreadsheets, terminal commands, and tribal knowledge.
End-to-end ownership across four years
I started on this project before my design manager was hired, contributing to early stakeholder calls with the VP of Product and senior subject matter experts to define what the tool could be. When my manager joined she took over running those calls and we collaborated on discovery, lo-fi mockups, and user testing. I built all prototypes and user flows throughout.
As her focus shifted to other initiatives, she handed full ownership of PAS to me. From that point I ran all working sessions, owned the UI end to end, and presented work directly to executive stakeholders including the CTO and COO.
Designing for the future, under pressure to ship now
The early work focused on understanding the PSLD workflow deeply before proposing solutions. I mapped the existing process, identified where errors occurred, and used that foundation to sketch an ideal future state before designing toward an MVP. This sequencing became a point of contention.
The PM and engineering leadership felt we were moving too slowly and designing too far ahead. Rather than abandoning the approach, we made the case directly to engineers: building toward a near-sighted MVP risked throwing away work within a year as the product iterated. We kept executing. When usability testing results were presented at a sprint review, the PM who had been most skeptical saw the value of what we were doing. That shifted the dynamic and the team aligned behind the process.
Designing under constraint: multi-tier plans
The most technically complex challenge came mid-project when a market requirement emerged for multi-tier medical plan support. There was no industry consensus on what multi-tier meant. Different insurers and networks defined it differently. We had to define it internally, then design a flow around that definition while working within significant technical constraints.
The solution required a new step in the flow built around provider groups, an internally invented concept that had no equivalent in the industry and could not be exposed to clients without causing confusion. Designing that step meant making three interconnected concepts legible to ops users, two of which existed only inside Collective Health and one of which meant something different outside it.
Every plan. One tool.
PAS launched as MVP in December 2024. All new medical plans are created in the tool.
In mid to late 2025, Collective Health completed a full migration of all existing plans from Google Sheets to PAS. The migration required identifying gaps in the tool and building features to support legacy plan configurations. Every medical plan the company manages now lives in PAS.
- Training new ops members is faster. The quasi-technical workflow is gone. Creating a plan no longer requires opening a terminal or running code.
- Account teams now pull up PAS directly in client meetings instead of relying on custom spreadsheets.
- A notes feature added after MVP launch tracks feedback by status, assignee, and date, giving clients real-time visibility into what was discussed and what is being acted on.
- Multi-tier plan configurations, structurally impossible in Google Sheets, are now fully supported. This capability drove full organizational adoption of the tool.
- The project led to my promotion to Senior Product Designer during the build and launch phase.
PAS moved medical plan creation from a fragile, person-dependent process to a structured, scalable system with built-in guardrails.
The PSLD team can now support plan configurations that were structurally impossible before. As Collective Health grows its client base and plan complexity, the tool grows with it.
What I would do differently
By the time we reached the more complex features and flows, I understood the domain deeply. That familiarity helped in discovery and stakeholder conversations. It hurt in the moments that required me to see the product as someone new to it would.
We tested once, about six months in, and we tested the full tool rather than individual flows. The thinking was to wait until there was enough to react to. In practice it meant feedback came late and covered too much ground at once. The medical code customization flow was where this became obvious. Since I had been working alongside our SMEs for years, the details, nuances, and intricacies made total sense to me. In testing, users were slow and hesitant. The content I assumed would be clear wasn't clear for someone without that background.
The auto-save assumption is the clearest example of what smaller, earlier tests would have caught. Engineering was uncertain, product was split, and I was the one who felt confident it was the right call. We deferred it because engineering couldn't build it at launch, not because anyone stopped to question whether users actually wanted it. When I went back post-launch to scope the feature, users were immediate. They didn't want auto-save. They wanted to know they had saved. One user told me directly that she had once lost an entire plan. When she went to engineering to try to resolve the error and recover her work, she was confident it was a bug because she knew she had pressed save. With auto-save she said she'd always wonder. The explicit action was the reassurance.
A focused test on save behavior before launch would have answered that in an afternoon. Feeling close to the problem made the answer feel obvious enough to skip the question. That is the pattern I am most deliberate about catching now.
This page covers the arc. The decisions, tradeoffs, and stakeholder dynamics are best discussed in person.