Let's talk
All work

Case 04 / Design systems · Working in code

One system. Shared rules.

A shared component library is a start. The harder question is how the same design decisions stay useful across design files, implementation and AI-assisted development.

My contribution
Established the design-system foundation and initiated the move to Figma; later shaped the direction with engineering.
Scope
Component systems, design tokens, coded prototypes and migration planning.
Concrete outcome
A shared foundation and a revised approach to design governance.

01 / The problem

Synchronising values does not ensure consistent use.

Earlier in my time at BlueConic, I established the design system and initiated the move to Figma. That provided a shared component foundation for the product.

Later, working with AI-assisted UI development raised another question: how do the design rules stay usable and consistently applied where the interface is built? A library and its implementation can still drift apart.

02 / The approach

Be willing to revise the architecture of your own solution.

I first explored a flow that synchronised Figma variables and assets into code. I then reconsidered the approach: another synchronisation layer did not sufficiently address the consistent application of rules.

I chose a direction with code as the central source, design tokens and reusable components, with Figma following the implementation. I worked with engineering on a gradual migration approach and made design guidance usable as focused specifications for AI coding tools.

  1. Decision 01

    Separate a source of values from their application

    Keeping files in sync is useful, but the design problem also includes how existing components and rules are chosen and applied.

  2. Decision 02

    Make rules usable in the medium that ships

    Connect tokens, components and concise design guidance to the code context. Use working prototypes to discuss interaction and implementation together.

  3. Decision 03

    Treat migration as part of the design

    A new foundation needs a path for the existing interface. I worked on the direction and governance approach, without treating the migration plan as evidence of completed consolidation.

Shared rules
Tokens & components
Working interface

A conceptual summary of the direction. It is not a diagram of an internal architecture or proof that the proposed checks and migration were completed.

03 / The outcome

A foundation, and a deliberate change in direction.

The earlier work established a shared design-system foundation and the move to Figma. The later work produced a revised design direction and governance and migration approach. They are separate contributions at different stages.

What I contributed

  • Established the shared component foundation and initiated the Figma move.
  • Revised the synchronisation approach in favour of code as the central source.
  • Worked on governance, migration and specifications usable by AI coding tools.

What the evidence does not establish

The available material does not verify the current coverage of automated checks, the number of consolidated components or a measured reduction in inconsistency. The proposed governance is not presented as fully deployed.

04 / The next question

What would I want to learn next?

The next evidence would be the extent of component reuse, actual deviations from shared rules and the effort required to maintain the system across design and code.

Continue exploring / Case 01

From setup to intent