Enter password to view case study
Unifying three product libraries into one adaptable system that three products, 8–10 designers and the team’s AI tools now build from.
TL;DR
GoodLeap’s three products each had their own component library. In 2 months, I designed one system that replaced 150+ component families with 62, and all three products now use it.
The problem. Origin, GoodLeap Pro and the homeowner app had each grown their own library and interaction rules, so teams rebuilt the same components and the brand felt different from app to app. But Ops staff, contractors and homeowners work on different devices and need different density, so the products couldn’t simply look the same.
What I changed
Cut 150+ component families to 62. One shared foundation of 643 design tokens and configurable components, with product-specific patterns only where workflows truly differ.
Became the system’s gatekeeper. I review and approve every new component, and decide with each designer whether it belongs in the global library or a product library.
Brought the system into AI tools. The library is published in Figma and connected to Claude, Codex and GitHub, so PMs use it for early concept prototypes too.
My role. UX Lead and sole designer of the system: research, design, documentation and engineering handoff in 2 months, with input from product designers, engineering and marketing.
Results
62 component families, down from 150+ across three libraries
3 of 3 products now use the new design language
8–10 designers build from one library
2–3x faster, as designers estimate, using the library with AI-assisted drawing
Project snapshot
Role: UX Lead, sole designer of the system
Scope: Audit · Design tokens · Components · Documentation · Engineering handoff · Governance
Products: Origin (desktop) · GoodLeap Pro (tablet and mobile) · Homeowner app (mobile)
Users of the system: 8–10 product designers · Engineers · PMs
Partners: Product designers · Engineering · Marketing
Timeline: 2 months, from research to engineering handoff
Status: Adopted by all three products; I continue to review every new component
Context and challenge
Three roles. Three apps. One financing journey that no longer felt like one brand.
The same home-improvement project moves through three GoodLeap products: contractors use GoodLeap Pro in the field, homeowners use the homeowner app on mobile, and Ops teams use Origin on desktop.
Each product had grown its own component library and rules:
Duplicate work. Teams rebuilt the same components in three places: 150+ component families in total.
Inconsistent brand. The same action looked and behaved differently from app to app.
Real differences. Users differed in device, density, permissions and how often they do a task, so consistent couldn’t mean identical.
The challenge: decide what should be shared, what should adapt through configuration, and what should stay product-specific.
I mapped the three libraries against their workflows and sorted every difference as repeated, conflicting, missing or required.
How I led
I built the system end to end, and I still own its rules.
Built it solo, with input from every team. Designers shared their libraries and real use-case screenshots, Engineering walked me through how components were implemented, and Marketing confirmed the brand direction.
Set four principles as the decision filter. One brand with adaptable experiences; foundations before components; flexibility without duplication; easy to adopt and extend.
Aligned design and code. Engineering adopted the library’s token names, so designers and engineers use the same language.
Run governance. I review and approve every new component, and decide with each designer whether it is global or product-specific.
Made the system usable in AI tools. Published to Figma, Claude, Codex and GitHub, so designers and PMs prototype with real components.
Trade-offs I navigated
Each decision meant choosing what to unify and what to leave alone.
Unify or keep product differences · with product designers
Some patterns differed because the workflows differed, such as dense desktop tables in Origin and touch-first layouts in GoodLeap Pro.
Decision: I reviewed each case with that product’s designer. Genuine workflow differences became product-specific components outside the global library; everything else was unified.
New token names vs. existing code · with Engineering
Each product’s code used its own naming, so a new token system risked drifting from what was built.
Decision: I reviewed the current implementation with Engineering before naming tokens. Engineering then adopted the library’s names, so design and code match.
The system
Three layers: shared foundations, configurable components, and product patterns only where needed.
Foundations. 643 design tokens for color, Inter typography, spacing, radius, shadows, grid and icons.
Components. 62 families with variants and states, such as buttons and input fields, so teams configure instead of duplicating.
Product patterns. Reserved for genuine workflow differences.
Decision: Build foundations before components, so every component inherits the same brand rules.
Shared components, different experiences
Same building blocks, three layouts.
Every product shows financing projects. Ops admins manage thousands in Origin on desktop, contractors work through assigned projects in GoodLeap Pro on tablet, and homeowners follow a few on mobile. All of them need the same four things: project identity, status, key details and actions.
I turned these into shared building blocks with consistent structure, behavior and states. Origin arranges them in a dense table, GoodLeap Pro in a tablet split view, and the homeowner app in simple mobile cards.
Decision: standardize the building blocks, not the layout.
Outcome and impact
All three products now share one design language, built from 62 component families instead of 150+.
Delivered system scale. 62 component families, down from 150+, and 643 tokens across foundations, actions, forms, navigation, data and feedback.
Covered 3 product contexts. Origin, GoodLeap Pro and the homeowner app now share one design language, shaped around each product’s workflows.
Created one source of truth. Shared anatomy, states, naming and behavior replaced competing local component rules, and 8–10 designers now build from the same library.
Made guidance accessible. The library and its usage guidance live in Figma, Claude, Codex and GitHub, so designers and PMs find the same rules wherever they work.
Aligned design and engineering. Engineering adopted the library’s token and component names, so design specs translate directly into code.
Enabled controlled evolution. I review every new component and decide with each designer whether it belongs in the global library or a product library. Designers estimate they now work 2–3x faster (not formally measured).
Next. Measure adoption formally: component reuse, requests for new components, design-to-code drift, and time to ship a brand update.
AI in the workflow
AI sped up the work; I set the rules and checked the output.
Audit. AI organized the three component inventories and surfaced likely duplicates and naming conflicts.
Production. After I defined each base component, its rules and properties, AI generated variants and states.
Documentation and QA. AI drafted usage guidance and found missing or inconsistent states for me to review.
Access. The library is connected to Figma, Claude, Codex and GitHub, so designers and PMs build with real components.
Reflection
1. Consistency is really a decision about where to allow difference.
The hardest calls were about what to keep, not what to unify. Reviewing each case with product designers produced one rule: differences driven by workflow become product-specific components, and differences driven by habit get unified. That rule outlasts any single component, because designers can apply it before review. Next time, I’d publish it as a decision guide from day one.
2. A design system is a product, and designers are its users.
62 component families aren’t the outcome; 8–10 designers choosing them every day is. So I ran the library like a product: research on three existing libraries and real screens, alignment with Engineering and brand, and ongoing review after launch. Next time, I’d define adoption metrics, such as reuse, new-component requests and design-to-code drift, before implementation starts.
3. A library needs an owner after launch.
Publishing was the start. Reviewing every new component is what keeps 62 families from growing back to 150, and it keeps the global and product libraries clearly separated. But a single gatekeeper doesn’t scale. Next time, I’d write down the contribution process early and name a reviewer in each product team, so quality holds as the team grows.
