Close case study
Design system component library
All work

Scaling one design language across AI teams

A design system built from scratch while its products were still wireframes, shared by three design teams.

My role
Design System Manager
Field
Design systems · AI
Timing
2025
Team
Six or seven designers, across two agencies and the client
Duration
11 months
Scope
Design system: library, tokens and documentation

In short

I built, from scratch, the design system of an organisation that was launching several AI tools at once, while those tools were still wireframes. Eleven months later, one library fed six products at launch and was shared by the designers of two agencies and the client.

Months, from February to December 2025
11
Products fed by the design system at launch, and counting
6
Organisations designing with the same library
3
Components in the library, fully documented for designers and developers
62
Component variants, interaction states included
616
Variables ready to become tokens
1.3K+

The context

An organisation that promotes the use of data and artificial intelligence across industry was starting to build several independent tools. The first plan covered four or five products, with more to follow.

When I joined, in February 2025, the products were wireframes. There was no visual language, no shared rules and no design system: only the idea.

I worked through an agency as the person in charge of the design system: building it, documenting it, running its backlog and keeping designers and developers in step. Two other designers at the agency were designing the first products in parallel.

Later products were commissioned to other agencies, so the system was never only for my own team. It had to be the single source of truth for whoever came next.

The challenge

A design system normally tidies up something that exists. Here there was nothing to tidy: designers needed components for screens with deadlines, while the visual language those components depended on was still changing.

Buttons showed the cost. Successive changes of visual direction left four or five button styles in the files, some of them no longer used, and a designer joining the project could not tell which one belonged where. The visual proposals also stopped at how things looked: hover and disabled states, behaviour and small screens were left open, and nobody can code from that.

And the audience kept growing. A second agency joined when the project was about two months old, to design a product that was not in the first plan. The library had to make sense to people who had not been there when it was decided.

My approach

The work, in order:

  1. FoundationsLayout, spacing, type scale and colour, agreed with the client and the team.
  2. Core componentsButtons and forms first, built from the cases the designers sent me.
  3. PublishEach component into the shared library, with a notice to swap the provisional version.
  4. TokensFrom primitive tokens to Figma variables, then semantic tokens applied to the components.
  5. DocumentationHow each component is used, so a designer who joins late does not have to ask.
  6. Update logNew components and changes to existing ones, for development to check every week.

And the decisions that shaped it:

  • Publish a basic kit before the visual language is closed

    Waiting for the final colours would have left every designer solving the same buttons and forms on their own, which is how fragmentation starts. I agreed with the team to publish usable components early and update them later. The risk was redoing work. What made it affordable was the library: once designers swapped their provisional pieces for linked instances, a change made once reached every file.

  • The component first, its tokens and documentation after

    The tidy order is foundations, tokens, component, documentation. It would have had the product teams waiting. When a designer needed something, I built it and published it, and tokenised and documented it afterwards. A backlog open to everyone showed which components were coming and when, so nobody had to guess.

  • Where a design left a gap, I filled it

    I was the link between the person who designs a screen and the person who codes it. When a proposal arrived without hover, disabled or empty states, or with no answer for a small screen, I could pass the gap on to development or close it myself. I defined those states, with their tokens, so a component was usable beyond its first appearance.

The results

  • Six products fed by the design system at launch, and countingThe first plan covered four or five.
  • One library shared by the designers of three organisationsMy agency, a second agency and the client’s own designers: six or seven people at the busiest point.
  • A library of 62 components and 616 variants, documented for designers and developersBehind them, more than 1,300 variables in 5 collections, from primitives to semantics, ready to become tokens in code, and 63 text styles.
  • Changes that reach every product file from one placeDesigners work with instances linked to the library, so an update does not mean replacing components by hand.
  • An update log that development reviewed every weekIt lists new components and changes to ones already coded, sometimes months after they were built.
  • Delivered in December 2025, after eleven monthsAt the handover, the team and the client singled out the level of detail of the system.

What I learned

The hardest part was not building components. It was explaining, to people less used to design systems, that whatever gets designed someone has to code, and that a visual change is never only visual once other teams depend on it. Looking back, I would have put that cost on the table earlier, while the buttons were still multiplying. It settled once the visual language was fixed, but it did not have to take that long.

It also confirmed a habit I already had: asking who will open my files next, a designer or a developer, and staying close to development to get ahead of their questions. What happens here when the state is empty? I would rather answer that while designing than be asked later.

What I cannot claim is time saved: nobody measured what the system saved the teams.

More case studies

Contact me

If you’ve taken a liking to me and want to get in touch, tell me about the project, the talk or your theories about Area 51. Write to me, or book a call.

book a callcheck my linkedinemail me