← Back to work
Case file 02 · Design systems · 8 weeks

Five products. One company. Nobody could tell.

Timeline
8 weeks
Team
4 designers, 3 developers
Role
Lead Designer
Scope
Tokens, components, adoption
01

A suite that didn't feel like one

Every product team shipped UI on their own. CRM looked nothing like billing. Ops modules invented their own validation patterns. Users felt the seams when they switched context, and engineering paid for it in duplicate components and slower handoffs.

Leadership didn't need another Figma library. They needed one shared language that let CRM, billing, and ops feel like the same company while each team kept shipping.

02

Foundation before components

Week one, stakeholders wanted visible components. I held for tokens and type scale. Awkward meeting. No screenshots to show. Worth it. We avoided rebuilding half the library in week six when products couldn't share spacing or color semantics.

We tried a top-down mandate first. Usage barely moved. What worked: showing engineers time saved per sprint when they pulled a standard component instead of Slack-ing design for "the fifth blue."

03

Adoption is the product

I printed the inconsistency. Every button, dropdown, and form field from every product, side by side on a wall. That beat any slide deck. Engineering joined at component definition, not handoff. We agreed on naming, states, and accessibility before specs were final.

Roughly 40% of this project was change management: workshops, migration docs, sitting with teams while they swapped their first screen. The library was necessary. It wasn't enough.

Systems decision

1:1 mapping between Figma and code

Every Figma component maps to exactly one code component. Same name, same states, same props. Sounds obvious. Most teams skip it. That's why engineers stopped rebuilding buttons and designers stopped accepting "close enough."

04

What shifted, and what we'd measure

We tracked adoption through team migration sessions, not a formal analytics dashboard. These signals told us the system was working, and what we'd instrument in a longer rollout.

Component reuse rate

Target: increasing share of screens built from system components vs. custom one-offs per sprint. Measured through design review and code audit.

Design-to-dev handoff cycles

Baseline: repeated debates on spacing, focus states, validation. Success = fewer one-off spec questions per feature after core components landed.

Cross-product consistency

Qualitative: users stopped asking "why does this work differently here?" when switching between CRM, billing, and ops modules.

Observed after 8 weeks: Standard UI shipped faster once core components landed. Design time moved from rebuilding primitives to feature work. Shared vocabulary in reviews replaced recurring debates about the same patterns.

05

What I'd tell a hiring manager

Honest scope

I underestimated how much of design systems work is change management. The library was maybe 40% of the job. Workshops, usage docs, and migration pairing was the rest. A system nobody uses is a side project with good documentation.

Build the system with engineering, not for them. Prioritize by cross-product usage frequency, not by who's loudest in the room. If adoption stalls, the rollout is the problem, not the components.

01

Foundation first

Tokens made everything after systematic. Boring week one, faster week eight.

02

Shared ownership

Co-design survived the first edge-case fight. That's when I knew it would stick.

03

Adoption is the product

Ship the rollout plan with the same rigor as the component specs.

↑ Back to work