Built a design system that cut UI development time in half
From inconsistency to a shared design language
Prism is a cross-platform design system serving 8 product teams across web and mobile. Before Prism, each team had its own component library, its own color tokens, its own interpretation of the brand. The result: 340+ unique button variants, 23 different modal patterns, and a visual language that fractured with every new feature.
I led the design, architecture, and adoption strategy for Prism. Within 6 months, it became the default system for all new feature development, reducing UI build time by 52% and eliminating 89% of design-to-dev handoff issues.
Eight teams, eight interpretations, zero consistency
The company had scaled from 1 to 8 product teams in 18 months. Each team moved fast and built what they needed, resulting in massive UI fragmentation.
- 340+ unique button variants across products
- 23 different modal/dialog patterns
- Design-to-dev handoff issues caused 28% of all bug tickets
- Average time to build a new feature page: 3.2 weeks (50%+ spent on UI decisions already made elsewhere)
- Accessibility compliance was inconsistent — 4 products failed WCAG AA audits
- Brand perception research showed users didn't recognize products as part of the same company
Understanding why design systems fail to get adopted
1. The "not invented here" problem is real
Interviewing teams revealed that previous standardization attempts failed because they felt imposed top-down. Teams had valid reasons for their custom components — the standard ones didn't handle their edge cases.
2. Documentation is the product
Teams that did adopt shared components consistently cited good documentation as the reason. Those that didn't cited "I couldn't figure out how to customize it" — not that the components were bad.
3. Tokens before components
The most successful cross-team alignment wasn't around shared components — it was around shared design tokens (colors, spacing, typography). Teams were willing to standardize the foundation even when they resisted standardizing the UI.
Building adoption into the architecture
Strategy: bottom-up adoption through a layered system
Layer 1: tokens (foundations). Layer 2: primitives (basic UI atoms). Layer 3: patterns (composed components). Teams could adopt at whatever layer they were comfortable with, knowing each layer built cleanly on the one below.
Dead end: the "monolith mistake"
First approach was a single comprehensive component library. After 4 weeks of building, we learned that teams on different tech stacks (React, React Native, Vue) couldn't use a monolithic React library. The one-size-fits-all approach was DOA.
We built a beautiful component library that exactly zero teams could fully adopt. The problem wasn't the components — it was assuming everyone was on the same tech stack.
The pivot: platform-agnostic tokens + platform-specific implementations
We restructured Prism as a token-first system with platform-specific component packages. Tokens are the source of truth; components are the expression layer.
Iteration: the "contribution model"
Instead of the design system team building everything, we created a contribution framework where product teams could propose, build, and submit components. Peer review ensured quality; shared ownership drove adoption.
A system designed to be adopted, not imposed
Token-first architecture
200+ design tokens covering color, spacing, typography, motion, and elevation. Tokens sync automatically between Figma and code via Style Dictionary. Change a token, and every platform updates.
Living documentation
Every component page includes: interactive playground, usage guidelines, do/don't examples, accessibility notes, and platform-specific implementation details. Documentation is auto-generated from code annotations to stay in sync.
Adoption dashboard
A real-time dashboard showing component coverage per product, token usage, and custom override frequency. Teams can see their adoption score and identify where they're diverging from the system.
Measurable outcomes across every metric
Beyond the headline numbers, the system had a ripple effect across the organization:
- All products now pass WCAG AA accessibility audits
- Custom button variants dropped from 340+ to 24 (the intentional ones)
- New designer onboarding time for UI work decreased from 3 weeks to 4 days
- The contribution model generated 40+ community-submitted components in the first year
Prism didn't just give us components — it gave us a shared vocabulary. Conversations about design went from 'make it look like this screenshot' to 'use the elevated card pattern with secondary action emphasis.'
— Senior Frontend EngineerWhat's next, and what I'd do differently
We're currently building the theming layer — allowing each product to express its own personality while staying within the Prism foundation. It's the hardest design system challenge: flexibility without fragmentation.
Looking back, I'd start with the contribution model from day one. We spent the first 8 weeks building in isolation, then had to retrofit community input. Starting collaborative would have produced a better initial component set and built buy-in earlier.