Creating a design system in Figma

Context

Time period

December 2022 – June 2024

Team

• UX UI Designer (me!)
• Various developers, researchers, designers and CMS managers

1. Starting with the brand identity

Colour and typography

Avoiding the temptation to rush straight to Figma, I wanted to start by establishing brand fundamentals like colour and typography, and presenting them clearly for future use.

To put my best foot forward, I followed IBM Carbon's well-respected template for colours. As well as itemising the HEX code values, I therefore also gave a suggested variable for future use:

In terms of typography, I took the work that the Brand team and the agency had done using our new font, Helvetica Now Display, and identified the various heading sizes that had been used so far. I then worked to add these as text styles on Figma, and to define the variations for different screen sizes.

NewUsing new, innovative Figma functionality

Colour variables

I have since updated the colours further using the new "local variables" Figma tool:

This means we can change a primitive colour in a single location and that change will be applied to all uses of that colour throughout the design system.

For example, if we swap our white from #FFFFFF to a less harsh #F5F5F5, this would update the 'background-primary' and 'text-inverse' colour tokens too.

Typography variables

Similarly, I have recently defined the typography using Figma's local variables, with desktop and mobile variants:

This means that the typography can now change automatically depending on whether the frame is identified as a desktop or mobile screen size, bringing things closer to the HTML media query breakpoints that developers actually use.

2. Following atomic design

Identifying the atoms

I then started the design system following the principles of atomic design as set out by Brad Frost.

I gathered the mid-fidelity wireframes that had been created in the redesign project. I then started from scratch, taking them back to individual 'atoms' like buttons and dropdowns.

Adding component properties

I made sure to integrate future-proofed component properties, including styles, states, widths, font colours, and variable icon instances:

Building out components

Once I'd sorted out the atoms, I could turn to the molecules.

I decided to use lowercase naming for atoms (e.g. "button") and capitalisation for full molecules (e.g. "Fund Title"). This proved useful because it let Content Designers identify the components that correlated with a panel that could be used in our CMS, Umbraco.

In general, I tried to make the component properties at this level as close as possible to the realistic options available to our CMS team.

3. Creating guidance for colleagues

Writing documentation

It wouldn't be a complete design system without detailed documentation.

I first looked at other design systems to decide what would work best for us. I added a "Why this component?" section to explain the UX and accessibility thinking behind the design. Then the customary "When should it be used?" and "Where on the page can it go?" to set some guidelines for future designs.

I then itemised all the customisations and options that could be set on the CMS in "What are the design options?", alongside a "What are the content recommendations?" to steer all future copywriting towards good UX writing practices.

Encouraging design system use

There's no point to a design system if it's not used, so it was important to then introduce it to the wider team.

I led meetings with the CMS managers to take them through the design system and to learn if there were any changes I could make to help them further.

For example, their feedback led me to rename the components from a traditional name (e.g. 'Accordion') to the name that they used on the CMS (e.g. 'People Panel'). Although this made the design system less tidy, it felt worth it to help encourage adoption.