SaaS
Design system consolidation for a healthcare scheduling product
Built by Camille Anne Villaruz
Merged three drifting component libraries into one, then spent longer removing components than adding them.
Builder email verified
Verification
- Type
- Professional
- Category
- SaaS
- Published
- Jul 25, 2026
- Updated
- Jul 25, 2026
About this project
- The problem
Three product squads had each grown their own component library out of a shared ancestor, and after two years they had eleven button variants, four date pickers and three different ideas about what a disabled field looks like. Clinicians using the product across modules were hitting genuinely different interaction rules on screens that looked the same, which in a scheduling context meant mistakes. The business cost was slower delivery — every squad rebuilt the same primitives — but the real driver was that a clinical safety review flagged the inconsistent confirmation dialogs.
- My role
Senior frontend engineer and the design system's owner for the year it took. I was not a manager; I had no authority over the squads, which meant the whole thing ran on persuasion and on making the new components obviously better than what people had.
- What I owned
I owned the audit, the merged library, and the migration. The audit was a real piece of work — I catalogued every component across the three codebases with usage counts pulled from the source, which is how we learned that six of the eleven buttons were each used fewer than four times. I built the consolidated components, wrote the accessibility tests that ship with them, and did the codemods for the mechanical parts of the migration. I also ran the fortnightly session where squads brought cases the system did not cover.
- Technical & product decisions
The decision that mattered was that the system ships one date picker and no escape hatch, after we found the four variants disagreed on whether a week starts Sunday or Monday. Squads pushed for a configurable component; I argued that configurability is how you get four date pickers with extra steps. Where I did concede was on layout — the system provides primitives and no page templates, because every attempt at templates in the audit had been abandoned within months. I also chose to keep the library in the same monorepo rather than versioning it as a package, so a breaking change is a single pull request that fixes every call site instead of a migration nobody schedules.
- Constraints
No squad could stop delivering, so the migration ran alongside roadmap work for a year with no dedicated headcount but mine. The product supports browsers older than I would like because some clinics run locked-down machines, which ruled out a few modern layout approaches and cost me a week of finding that out the hard way. Clinical sign-off was required for any change to a confirmation flow, which added about three weeks to each of those.
- Result & impact
Eleven buttons became two with three sizes, and the component count overall went from a hundred and forty to eighty-two. New screens went from roughly three days of frontend work to under one, measured on the squads' own estimates before and after. Every component ships with keyboard and screen reader tests, and the follow-up clinical safety review closed the confirmation dialog finding. The number I quote internally is that we deleted about nine thousand lines net.
- Who else worked on it
A designer from the platform team rebuilt the token set and did the visual reconciliation, which was at least half the work. One engineer from each squad acted as the migration point of contact and did the parts codemods could not. Our accessibility consultant reviewed the first fifteen components and taught me most of what I now do by default.