Case study 02 · Platform Product
One component library for 6 delivery teams
Multiple teams on the same client program were rebuilding the same buttons, tables, and forms — each slightly different. I helped treat our internal UI library as a product, with engineers as its customers.
- Client
- Fortune 50 Enterprise · Healthcare & Insurance program
- My role
- Front-end Engineer · platform & adoption lead
- Timeline
- 8 Months
- Team
- 4 core contributors, 6 consuming teams
6
teams onboarded
70%
of UI built from shared components
12 hrs
saved per team, per sprint
01
The problem
6 applications, one brand, yet no shared foundation. The result: inconsistent UX for end users, duplicated accessibility bugs, and design reviews that re-litigated the same decisions every sprint.
02
Treating engineers as customers
Earlier shared libraries had failed because they were built for teams instead of with them. So I ran short interviews with tech leads from each team and audited their codebases.
- 12 components covered roughly 65% of UI across every app.
- Teams didn't fear the library — they feared breaking changes landing mid-sprint.
- Nobody read wiki pages. They copied examples.
03
The solution
- 01Design tokensColor, type & spacing as code
- 02Component libraryAccessible, tested primitives
- 03Docs & playgroundLive, copy-paste examples
- 04Versioned releasesSemver + changelogs
- 05Consuming teamsUpgrade on their schedule
The docs site became the product's front door: every component shipped with a live example, props table, accessibility notes, and a “when not to use this” section.
04
Trade-offs & alignment
To secure buy-in, I recruited one “champion” engineer per team, ran a monthly demo, and published a public roadmap so teams could see — and vote on — what was coming next.
05
Outcome
- 6 of 6 teams adopted the library within 6 months.
- Accessibility defects in UI audits dropped by 82%.
- New screens shipped 35% faster, measured by story cycle time.
06
What I'd do differently
I'd establish a formal RFC (Request for Comments) process and governance model for community-contributed components from day one. In our initial launch, delivery teams wanted to contribute custom variations back to the core library, but without clear contribution guidelines, pull requests sat in review too long, causing temporary friction between core maintainers and delivery teams.