THE CHALLENGE

Building a design system that AI agents can actually read

An AI-augmented design system serving 120+ products across 28 countries.

Product type

Design system Web design

Team

Olivier André (Product designer) Yvoni Peersani (Front-end engineer) Ashvish Moogarsing (Dev Lead)

Olivier André (UX research designer) Jean-Paul Sauzier (Project manager) Ashvish Moogarsing (Dev Lead)

Olivier André (UX research designer) Jean-Paul Sauzier (Project manager) Ashvish Moogarsing(Dev Lead)

SOFTWARE AND TOOLS

Figma, Code Connect, Claude Code

Figma Claude code

Timeline

6 months (Feb–July 2026)

MY IMPACT

Bridging product, brand, and marketing

"As Senior Product Designer, I led the design system workstream inside a cross-functional squad partnering with brand, marketing, engineering, and product design leads across Europe. My focus was twofold: define the foundations and governance of the new system, and translate them into something marketing could actually use."

What I achieved with the team

Build robust foundations

Token architecture, components connected to production code, and strong guidelines.

Enablement

Documentation, defining annotations structure and workflows for non-design teams.

AI integration

Defining clear guidelines for AI usage and automating documentation generation

MY IMPACT

Bridging product, brand, and marketing

As Senior Product Designer, I led the design system workstream inside a cross-functional squad partnering with brand, marketing, engineering, and product design leads across Europe. My focus was twofold: define the foundations and governance of the new system, and translate them into something marketing could actually use.

What I achieved with the team

Build robust foundations

Token architecture, components connected to production code, and strong guidelines.

Enablement

Documentation, defining annotations structure and workflows for non-design teams.

AI integration

Defining clear guidelines for AI usage and automating documentation generation

FRAMING THE PROBLEM

A fragmented brand growing faster than its system.

SD Worx is one of Europe’s leading providers of HR digital services, scaling rapidly across products, regions, and teams. That growth created a familiar tension: product and marketing were drifting apart visually, verbally, and operationally. Teams were working in silos, making the codebase harder to maintain and creating a disconnect between how designers designed and how developers built. With different teams solving the same problems in different ways, it became harder for the organisation to align on what both sides needed.

Brand asset and art direction

Understanding the current system

The system existed. The consistency didn't.

Instead of immediately creating new components, we audited how the existing system behaved across Figma, products and code.

We looked at four things:

Area

What we checked

What we were looking for

Foundations

Colour, typography, spacing, icons

Duplicate values, inconsistent naming, hardcoded styles

Components

Buttons, cards, inputs, navigation

Buttons, cards, inputs,

navigation

Duplicates, variants, missing states, inconsistent behaviour

Usage

Real product screens

Detached components, overrides, one-off patterns

Design → code

Figma vs Storybook/code

Components that existed in one world but not the other

The design direction

Three pillars, one foundation.

Brand consistency

A unified visual and verbal system applied across 120+ products and 28 European markets.

Central documentation

A single source of truth for product, marketing, and brand — replacing scattered files, decks, and tribal knowledge.

Component management

A leaner, smarter component library with clear ownership, lifecycle, code connected system and contribution rules.

Components from the revamped system

How we solved the system problem

Using solid specs and guidelines that bridge
design and engineering.

By closing the gap between how designers think and how engineers build. Clear tokens, documented components, and shared governance turn handoffs into pickups — and make every downstream product win possible.

Example of guidelines: Skeletal Layout Design

Step 1: Identify elements that have a skeleton loader

As previously stated, it is important to note that not all elements on a page should or can be replaced by a skeleton loader. It is recommended to identify containers that hold information that will be added dynamically as the page loads, such as a list of messages.

Don’t

Unnecessarily make elements look like they are loading. Skeleton loaders reduce the perceived wait of a page, but replacing elements that don't have or require a loading state confuses users and makes the page feel like it is loading unnecessary data — which makes it feel less performant, not more.

Do

Target elements which contain information that will take time to load.

Applying semantics instead of styles

Foundational assets and semantic naming

I established a standardised semantic way to define values across our products. Using this method, the design system became more than a Figma library: it became our organisation's shared language, bridging the gap between developers and designers.

Color

Color

Raw value

Raw value

Primitive

Primitive

Semantic applied to component

Semantic aliasing

Primary-Color

Primary-Color

Primary interaction

#006DD8

#006DD8

#006DD8

Button-background-primary-default

Button-background-primary-default

Defining design tokens structure

A clear token structure that connects raw values, primitives, and semantic roles. This created a consistent language for defining how values are used across products, making the system easier for designers and developers to implement and interpret.

Primary color

Blue 100

#ECF9FF

Blue 200

#D4F2FF

Blue 300

#B2E9FF

Blue 400

#7DDDFF

Blue 500

#40C9FF

Blue 600

#14ADFF

Blue 700

#0088FF

Blue 800

#006DD8

Blue 900

#0858A0

Blue 1000

#0A3561

Semantic aliasing roadmap
Applying the components to our products

Exploring a new approach to tokens

I introduced Figma Code Connect to link the codebase with its Figma representation, keeping components synchronised without manual updates. I first aligned with developers, then migrated from foundations tokens and primitives to larger components, ensuring the architecture was stable before scaling.

Writing documentation for agents, not just for people

The less obvious shift was treating Code Connect documentation as agent context rather than developer documentation. If AI agents maintain the mapping, documentation becomes their instruction set, so it needs to be unambiguous, complete, and structured for machine context. We defined what exists in Figma, what the codebase must provide, and how agents should extend Code Connect files reliably.

Token building workflow for AI

What broke using AI, and the design decisions that solved it

The usage and experimentation phase taught us valuable lessons about AI agents' real effectiveness and limitations. It also surfaced system-level problems that made connecting components to code difficult.

Design and code spoke different languages

Token names, component properties and variants didn't always map directly between Figma and production.

The source of truth wasn't always obvious

Multiple teams had different implementations, making it difficult to determine which component or token should become the reference.

Connections became stale as the system evolved

Components changed in code while their Figma counterparts and mappings didn't always evolve with them.

Connecting the system exposed gaps in the system itself

Some Figma properties had no production equivalent, while some production behaviours weren't represented in Figma.

Problems

Problems

Design decisions

Design decisions

Different naming

Different naming

Establish a shared token/component vocabulary

Establish a shared token/component vocabulary

Multiple implementations

Multiple implementations

Start with agreed foundation + core components

Start with agreed foundation + core components

Stale mappings

Stale mappings

Treat Code Connect mappings as part of system maintenance

Treat Code Connect mappings as part of system maintenance

Different APIs

Different APIs

Map properties deliberately rather than assuming 1:1 relationships

Map properties deliberately rather than assuming 1:1 relationships

Missing coverage

Missing coverage

Prioritise high-use components first

Prioritise high-use components first

Design/code disconnect

Design/code disconnect

Pair designers and developers during mapping

Pair designers and developers during mapping

Moving strategically instead of overhauling a system that works

Moving strategical instead of
overwhelming a system that works

Rather than transforming the entire system at once, I took a phased approach starting with the foundations and a few core components to validate the structure before scaling. This reduced risk, surfaced issues early, and allowed us to improve without disrupting existing products.

Our strategy roadmap to Agent integration

Our decision on integration

Keeping the system mostly human

Rather than risking the entire system on AI, we chose a hybrid approach. Foundations and tokens could be structured and generated with AI, while larger components still required manual design and development due to their complexity and the level of rework involved. This allowed us to automate where it added value without disrupting a system that was already working.

What we built using the hybrid system

Registration & login flow

Registration and login were duplicated across multiple SD Worx products, each with its own form components, error states, and visual treatment. Users moving between products encountered subtly different experiences and engineering teams maintained the same logic in parallel.

Screen designed with design system assets
Screen designed with design system assets

Using the card component in a
standardized way

I established clear rules for how the card component should be used across products, from its structure and spacing to content hierarchy and interaction states. This gave teams a consistent starting point while still allowing cards to adapt to different product needs without creating unnecessary variations.

Do

Use the system

Reuse the component before creating a new variation and follow the defined structure, spacing, and content hierarchy.

Don't

Create unnecessary variations

Don't create unnecessary card variations for minor differences. Keep the hierarchy and structure intact.

How we solved the system problem

Using solid specs and guidelines that bridge design and engineering.

By closing the gap between how designers think and how engineers build. Clear tokens, documented components, and shared governance turn handoffs into pickups — and make every downstream product win possible.

Example of guidelines: Skeletal Layout Design

Step 1: Identify elements that have a skeleton loader

As previously stated, it is important to note that not all elements on a page should or can be replaced by a skeleton loader. It is recommended to identify containers that hold information that will be added dynamically as the page loads, such as a list of messages.

Don’t

Unnecessarily make elements look like they are loading. Skeleton loaders reduce the perceived wait of a page, but replacing elements that don't have or require a loading state confuses users and makes the page feel like it is loading unnecessary data — which makes it feel less performant, not more.

Do

Target elements which contain information that will take time to load.

Step 2: Convert the design into a skeletal layout

When translating designs into a skeletal layout (different from a wireframe), it's important to not make the mistake of turning every element into a skeleton loader. Doing so will result in an overcrowded layout that lacks visual appeal.

Internal Communication • Survey

Employee Wellness Survey

Published Fri, 20 April 9:00 to 2108 users by Fran Kilgad

NL

EN

FR

DE

Published

Internal Communication • Survey

Discover our FIP plan

Published Fri, 20 April 9:00 to 2108 users by Fran Kilgad

EN

DE

Draft

Don’t

Internal Communication • Survey

Employee Wellness Survey

Published Fri, 20 April 9:00 to 2108 users by Fran Kilgad

NL

EN

FR

DE

Published

Internal Communication • Survey

Discover our FIP plan

Published Fri, 20 April 9:00 to 2108 users by Fran Kilgad

EN

DE

Draft

Do

Applying semantics instead of styles

Foundational assets and semantic naming

I established a standardised semantics way to define value across our products. Using this method, the design system became more than a Figma library, it became our organisation shared language document bridging the gap between developers and designers.

Color

Raw value

Primitive

Semantic aliasing

Primary-Color

#006DD8

#006DD8

bg-color-primary

Defining design tokens structure

A clear token structure that connects raw values, primitives, and semantic roles.
This created a consistent language for defining how values are used cross products,
making the system easier for designers and developers to implement and interpret.

Primary color

Blue 100

#ECF9FF

Blue 200

#D4F2FF

Blue 300

#B2E9FF

Blue 400

#7DDDFF

Blue 500

#40C9FF

Blue 600

#14ADFF

Blue 700

#0088FF

Blue 800

#006DD8

Blue 900

#0858A0

Blue 1000

#0A3561

Semantic aliasing roadmap
Applying the components to our products

Exploring a new approach to tokens

I introduced Figma Code Connect to link the codebase with its Figma representation, keeping components synchronised without manual updates. I first aligned with developers, then migrated from foundations tokens and primitives to larger components, ensuring the architecture was stable before scaling.

Writing documentation for agents, not just for people

The less obvious shift was treating Code Connect documentation as agent context rather than developer documentation. If AI agents maintain the mapping, documentation becomes their instruction set, so it needs to be unambiguous, complete, and structured for machine context. We defined what exists in Figma, what the codebase must provide, and how agents should extend Code Connect files reliably.

Token building workflow for AI

What broke using AI, and the design decisions that solved it

The usage and experimentation phase taught us some valuable lessons that help us understand the AI agents real effectiveness and limitations. I was able to detect system level problems that make the component and code connection difficult.

Design and code spoke different languages

Token names, component properties and variants didn't always map directly between Figma and production.

The source of truth wasn't always obvious

Multiple teams had different implementations, making it difficult to determine which component or token should become the reference.

Connections became stale as the system evolved

Components changed in code while their Figma counterparts and mappings didn't always evolve with them.

Connecting the system exposed gaps in the system itself

Some Figma properties had no production equivalent, while some production behaviours weren't represented in Figma.

Problems

Design decisions

Different naming

Establish a shared token/component vocabulary

Multiple implementations

Start with agreed foundation + core components

Stale mappings

Treat Code Connect mappings as part of system maintenance

Different APIs

Map properties deliberately rather than assuming 1:1 relationships

Missing coverage

Prioritise high-use components first

Design/code disconnect

Pair designers and developers during mapping

Moving strategical instead of
overwhelming a system that works

Rather than transforming the entire system at once, I took a phased approach starting with the foundations and a few core components to validate the structure before scaling. This reduced risk, surfaced issues early, and allowed us to improve without disrupting existing products.

Our strategy roadmap to Agent integration

Our decision on integration

Keeping the system mostly human

Rather than risking the entire system on AI, we chose a hybrid approach. Foundations and tokens could be structured and generated with AI, while larger components still required manual design and development due to their complexity and the level of rework involved. This allowed us to automate where it added value without disrupting a system that was already working.

What we build using the hybrid system

Registration & login flow

Registration and login were duplicated across multiple SD Worx products, each with its own form components, error states, and visual treatment. Users moving between products encountered subtly different experiences and engineering teams maintained the same logic in parallel.

Screen designed with design system assets
Screen designed with design system assets

Using the card component in a
standardized way

I established clear rules for how the card component should be used across products, from its structure and spacing to content hierarchy and interaction states. This gave teams a consistent starting point while still allowing cards to adapt to different product needs without creating unnecessary variations.

Do

Use the system

Reuse the component before creating a new variation and follow the defined structure, spacing,
and content hierarchy.

Don't

Create unnecessary variations

Don't create unnecessary card variations for minor differences. Keep the hierarchy and structure intact.

What changed

A foundation that ships, scales, and shows up
in the work.

A foundation that ships, scales, and shows up in the work.

The design system isn't a deliverable, it's a multiplier. Its value only becomes visible when product teams ship faster, brand teams stay consistent, and users feel the cohesion. Three cases below show how the foundation translated into measurable product outcomes across very different parts of the business.

40%+

Teams transitioned to the AI-assisted workflow

120+

Products and apps adopted the system

50%

Reduction in components (150 → 75)

28

European countries unified under one design language

Need help?

Need help?

Help & support

Frequently asked questions

Contact support

Preview

English

Manage message

Message details

Status

Last Modified

Author

Show as grid

Show as list

Need help?

Need help?

Help & support

Frequently asked questions

Contact support

Preview

English

Manage message

Message details

Status

Last Modified

Author

Show as grid

Show as list

Learning

Balancing expression and AI functionality.

I've learnt that design systems live at the intersection of brand expression, usability, and AI functionality. Components need to feel unmistakably on-brand while remaining flexible and reliable across different products. The challenge is finding the balance between consistency, distinctiveness, and what AI can help us automate.

Designing, thinking and researching across scale.

Working on a design system taught me to move constantly between the details and the bigger picture. From a tiny spacing decision to an entire product ecosystem.

Context is a budget

While AI can speed things up, I quickly realised that it comes at a cost. The approach is to be intentional about where AI adds real value and where a manual approach is simply more efficient. By reusing context, keeping prompts focused, and automating the repetitive parts of token generation, I could get more value from it without wasting time or budget.

Adoption is the real deliverable

Seeing the system scale across products and teams taught me that a design system's value doesn't live in the library, it lives in adoption. What made it worthwhile was watching it shape a common product ecosystem for the benefit of our customers.

SELECTED WORK

Product Design case studies

I've gathered a selection of my latest Product Design examples to showcase my expertise

SELECTED WORK

Product Design case studies

I've gathered a selection of my latest Product Design examples to showcase my expertise

SELECTED WORK

Product Design case studies

I've gathered a selection of my latest Product Design examples to showcase my expertise

DESIGNED + CODED BY OLIVIER

DESIGNED + CODED BY OLIVIER

DESIGNED + CODED BY OLIVIER