The Challenge

‍Three independent Figma libraries with overlapping components, inconsistent naming conventions, and no shared governance model were slowing delivery and compounding design debt across every platform Specialized ships.

‍

My Role‍

Led the full consolidation effort – audit and architecture through component rationalization, design-engineering alignment, and organization-wide rollout. This wasn't a visual refresh. It was a structural rebuild with real operational stakes.

‍

My Approach

‍Audit before design, tokens before components, governance before adoption. Every phase was sequenced to prevent the new system from inheriting the problems of the old ones.

‍

Solution & Outcome‍

A scalable, actively governed design system that reduced duplicated components, improved cross-platform consistency, and meaningfully accelerated feature delivery across web and mobile.

‍

Lessons Learned

‍A design system is only as valuable as its adoption. The governance model and rollout strategy aren't administrative afterthoughts – they're the work. Building the system is the easier half.

As Specialized's digital ecosystem expanded (e-commerce (D2C), retailer (B2B), consumer app), the design infrastructure didn't scale with it. Three independent Figma libraries had evolved in parallel, each solving the same problems slightly differently.

‍

The compounding effects were significant:

Fragmented foundations

• Three independent Figma libraries with overlapping components and no shared token layer
• Inconsistent naming conventions and file structure across libraries
• No centralized governance or contribution model. Changes in one library didn't propagate to others

Design-to-code misalignment

• Significant drift between what existed in Figma and what was implemented in code
• Redundant components built multiple times by different engineering teams
• No shared documentation for component APIs or usage guidelines

Scaling friction

• Brand updates required manual propagation across all three libraries and their corresponding codebases
• New features required designers to decide which library to work from – and often resulted in new one-off components rather than extensions of existing ones
• Inconsistencies compounded with every release cycle

The cost wasn't just aesthetic. Fragmented systems slow teams down, erode trust in the tools, and make it harder to maintain quality as the product evolves. Sequoia was built to solve this at the root.

I led Sequoia end-to-end as Senior Product Designer, Design Systems at Specialized. My responsibilities spanned system architecture, component design, token infrastructure, documentation, and cross-functional adoption. I collaborated closely with engineering to ensure design-to-code parity, and with product and brand to align the system with both platform requirements and visual identity.

‍

This work grew directly out of my earlier mobile app work at Specialized, where building reusable components for the app revealed the broader fragmentation problem and made the case for a unified system.

Audit first, no assumptions

‍Before designing anything new, I conducted a comprehensive inventory of all three existing libraries: every component, token, pattern, and interaction state across every platform. I then cross-referenced design files against implemented code to map the gap between what was designed and what was actually shipped.

‍

This audit produced two things: a clear picture of what could be consolidated, and a usage analysis that identified which components were load-bearing versus vestigial. It also gave the team a shared, objective view of the problem. This was essential for getting alignment before any new direction was proposed.

‍

Tokens before components

‍I established the foundational token layer before touching a single component. Color, typography scale, spacing, elevation, and motion were defined as global design tokens and aligned with engineering variables – creating the shared language that would make design-to-code parity possible at scale.

‍

This sequencing was deliberate. Tokens are the hardest layer to retrofit and the most expensive to get wrong. Building components on top of an unresolved token system just recreates the fragmentation problem one level up.

‍

Component rationalization

‍With the token foundation in place, I merged duplicate components into scalable, variant-based systems – reducing unnecessary permutations while preserving the flexibility teams actually needed. Every component was standardized across interaction states (hover, focus, active, error, loading), naming conventions, and file structure. Accessibility standards were built in at the base layer, not added afterward.

‍

Design-engineering alignment

‍I partnered directly with engineering throughout, not just at handoff. Regular platform design/dev syncs validated feasibility early, caught drift before it compounded, and produced shared documentation covering component APIs, usage guidelines, and migration paths from the legacy systems. The goal was 1:1 parity between Figma and code, not approximate alignment.

‍

Governance and adoption

‍A design system without governance decays. I defined the contribution workflow, review criteria, and release and versioning process. This gave teams a clear path for proposing, validating, and shipping system updates. I then led internal rollout sessions across design and engineering to drive adoption, document migration paths from legacy libraries, and establish the system as the authoritative source of truth.

A unified token infrastructure

‍Global design tokens (color, type scale, spacing, elevation), aligned with engineering variables across platforms. A single change to a token propagates correctly across every surface that uses it, eliminating the manual propagation that had made brand updates so costly.

‍

A rationalized component library

‍Merged, variant-based components built on the token foundation. I covered the full range of UI patterns across app, e-commerce, and B2B surfaces. Consistent naming, file structure, and interaction states throughout. Accessibility baked into base components rather than handled case-by-case.

‍

A responsive layout system

‍A standardized grid and layout system established across breakpoints – giving designers and engineers a shared spatial language for every platform.

‍

Design-to-code documentation

‍Shared component documentation covering APIs, usage guidelines, and edge cases – maintained alongside the system and versioned with each release. The documentation isn't supplementary; it's part of the system.

‍

A governance model that scales

‍A defined contribution workflow and review process that allows teams across the organization to propose and validate additions to the system, without the system owner becoming a bottleneck. Migration guides for legacy components lowered the barrier to adoption across existing products.

Sequoia transformed a fragmented set of libraries into a coherent, operational system that teams across Specialized design and ship from every day.

‍

Specific metrics are confidential, but the impact is demonstrable across four dimensions:

• Reduced design debt – duplicated components and one-off patterns replaced by a shared, rationalized library.
• Improved consistency – a unified token layer and component system producing coherent experiences across app, e-commerce, and B2B surfaces.
• Faster delivery – teams spending less time making foundational decisions and more time solving product problems.
• Scalable foundation – a system architecture capable of absorbing new platforms and product lines without fragmenting again.

The testimonial from Jack Sadler, Senior UI Designer at Specialized, speaks to both the quality of the system and the collaborative process that built it – "two years of working sessions characterized by "meticulous attention to detail" and "universally applicable" decisions."

Design systems work is fundamentally organizational design work with a Figma file attached. The hardest problems in building Sequoia weren't component architecture or token naming – they were alignment, adoption, and governance. Getting cross-functional teams to trust and use a new system requires as much communication and facilitation as it does craft.

‍

I also learned that the best design systems aren't designed in isolation, they're extracted from real product problems. Sequoia became a better system because it was built alongside the Specialized App, under real constraints, solving real design problems. That production context shaped every architectural decision in ways that a greenfield systems project wouldn't have.

‍

Sequoia is the work I'm most proud of in my career so far, not because it's visually impressive, but because it's operational. Teams are faster, more consistent, and more confident because of it. That's what a design system is supposed to do.