Turning fragmented global patterns into a shared system

The challenge

The challenge was not simply creating a new component library. Teams needed a practical way to move from fragmented legacy interfaces to one shared system without losing the differences their products and markets genuinely needed.

I focused on four connected decisions:

1. Consolidate fragmented patterns.
2. Add flexibility without detachment.
3. Connect design and code.
4. Make behaviour reusable.

1. Consolidating fragmented patterns

I led an audit across existing pages, identifying repeated text styles, colours, interface elements, and product patterns. The evidence helped us separate unnecessary variation from differences the new system still needed to support.

The shared visual language supports consistent experiences across products and markets.

I mapped legacy colours and calls to action to their new equivalents. This gave teams a migration path between what they already used and what the new system supported.

Key decisionMap before replacing

Legacy patterns are connected to their supported system replacements.

The same approach helped with larger components. Product cards looked similar across the existing sites, but their content, actions, and layouts had evolved separately.

The audit exposed repeated product-card structures and local variations.

I gathered their content and actions into one supported structure. Approved sections could be shown or hidden to fit each journey, which consolidated several local patterns without forcing every product into the same content model.

The master component supports different journey and content needs.

2. Flexibility without detachment

Components needed to work across different products without becoming difficult to understand. I kept shared structure, spacing, states, and behaviour controlled, then exposed approved options for the parts that genuinely varied.

Key decisionControl the parts that can change

Input variants brought component types and states together. Designers could select the state they needed from one component instead of finding and replacing separate assets.

Designers change input states without replacing the component.

For expandable patterns such as tables, I defined cell variants that designers could combine into the rows and columns they needed.

Cell variants support different table structures from the same foundation.

Some components had previously required designers to detach them before changing their content. I designed non-destructive overrides so teams could adapt approved areas while preserving the system connection.

Approved overrides adapt content without breaking the component instance.

3. Connecting design and code

I partnered with developers to establish shared token names and connect design decisions to implementation. I led the design-side token structure while developers shaped the repository and code integration. The custom repository pulled tokens from Figma into code, removing repeated manual updates between the two libraries.

Key decisionName tokens by purpose

Shared token names connect design decisions in Figma with implementation in code.

Together, we stored core decisions as base variables and added semantic names at component level. This connected the design and code libraries through shared language, made each token's purpose clearer, and made future changes easier to manage.

Semantic names connect foundation decisions to component intent.

As the library expanded, I created a logical naming framework for component-level tokens. It gave teams a repeatable way to describe new decisions without inventing a different structure each time.

The naming framework gives teams a repeatable way to add tokens.

4. Making behaviour reusable

I defined a branded motion principle that teams could apply consistently. It connected expressive brand movement with smaller functional feedback, so motion could scale without every team creating its own rules.

The motion principle connects brand expression with interaction behaviour.

The call to action showed the expressive end of the principle.

The Move Beyond principle applied to calls to action.

For a multi-selection control, I used smaller movement to confirm a change without slowing the task.

The same principle provides functional feedback in a selection control.

What changed

• Repeated interface patterns became shared components.
• Legacy styles gained a clearer path into the new system.
• Designers could use approved flexibility without detaching component instances.
• Design and code used the same token language.
• Motion became reusable behaviour rather than a local effect.

Teams gained more than a component library. They gained a shared foundation they could adapt without losing the system connection.