Improving a design system

A look at how I improved the usability and impact of the design system at Babylon.

The design system team

  • 1x Product Manager
  • 3x Product Designers
  • 1x Engineering Manager
  • 4x Engineers
  • 1x Accessibility Manager

My responsibilities

  • Component library maintenance
  • UI Design
  • Documentation
  • Engineering support
  • Accessibility integration

The problems

When I joined Babylon as a Senior Product Designer for the "DNA" Design System team, I ran a quick user survey with my colleagues to discover areas for improvement. The most common complaint from designers was the usability of the Figma component library.

The layers are too complicated, some variants are completely broken, and the categorisation is confusing.

Internal user study

I wanted to find the best way to reorganise the component categorisation without adding my own biases, so I held an open card sort with the designers. I presented them with a generic component library (to avoid bias) and asked them to group them in to categories. They could then name the categories in a way that made sense to them. This allowed me to build a picture of the team's mental model of components.

A screen capture of a card sorting session
One of the card sorts held with the users of the component library.

Once I understood the team's mental model, the results from the open card sort were applied to the component categories in the Figma Asset panel.

Some of the categories in the Asset panel
Some of the categories that the designers created in the card sort.

Fixing the layers and variants

The convoluted and inconsistent layers of the components were causing variant properties and responsiveness to break, and they were also just difficult to navigate and read. I simplified all layers as much as possible and introduced consistent naming conventions. The designers and engineers found it much easier to work with the components like this, because they could more clearly see how they were structured.

Simplified component layers
The Banner component had its layers reduced from 14 to 4.


In order to keep the design system relevant and mature, it's imperative to have designers and engineers from all around the business contributing to it. For this reason, a good process needs to be designed and implemented. There was no existing contribution model, so I created one suited to the teams ways of working.

A flow chart of the new contribution model
The new contribution model for components in the design system.

If the quality of components is not kept in check, the problems can start to snowball, and the usefulness of the design system declines dramatically. Amongst the process guide for creating a new component, I devised a checklist for quality assurance, and the designers had to ensure their components met these requirements before it would be signed off.

A checklist of quality assurance rules
A checklist that designers could reference when building a new component.


Documentation desperately needed the inclusion of accessibility notes, so an overhaul of how we documented each component was done. Here's the Accordion page as an example.

A page of documentation from DNA.
An example of the documentation, including accessibility.

Design Tokens

When Figma introduced the Variables feature, I took the time to edit all components using design tokens. This was achieved with 3 layers of tokens built on each other: Global, Alias and Component.

The Variables window in Figma.
Some of the Alias Tokens from the component library, showing the Light and Dark modes.


To make sure the components were effective, the DNA team would observe user testing sessions to see how they were being used. We could measure Time on Task, and see if they were working as intended for our users with impairments.

A video call with a user.
A journey being tested with a user, as we measured the Time on Task for the Metric Cards.

Using Jira we measured how much dev and design time the components saved, by looking at story points spent in sprints before and after the introduction of a component.

A graph showing the burndown in a sprint before the introduction of a component.
What a typical sprint looked like before components.
A graph showing the burndown in a sprint bafter the introduction of a component.
What a typical sprint looked like after components.

Next steps

Further tokenisation. The Bupa and Telus third-party libraries would become really powerful if we used the Variables feature with them too.

Web library. The app libraries were in a good place, the desktop components needed attention.

Decision log. A better system for documenting decision-making could be implemented.