Scaling a design system

Overview

It spanned across roughly 6 months from discussion to full rollout. The goal was not to do a massive overhaul all at once, as we all had our individual streams of work, but to make incremental changes that were most critical and helpful for all our workflows.

My role

Contributing designer for mobile & web app design system

Lead designer for internal management portal’s design system

Why upgrade the design system?

With all the new streams of products and increasing number of designers, we decided it was time to make time to clear design debt that would otherwise accrue and slow down our processes, and to avoid inconsistency and a drop in quality in our designs.

Upgrading a design system required careful planning so as not to disrupt our daily active users (5 designers and over a dozen developers) workflow. Even a small change in naming alone can cause confusion.

Here are some things we did to reduce the chances of destablizing the current state of the design system, while simultaneously making it more future-proof:

individual information architecture exercise to name, group, organise our components

group syncs to agree on how to name components, how to structure our files for easier search

colour audit to make theming easier

a submission workflow to improve ownership over the design system (everyone should be able to contribute)

a check and balance workflow to ensure quality before committing to the design system

Some questions I faced as I reflect upon my experience scaling a design system:

How do we decide when a component should be deprecated?

How do we create space for experimentation and exploration of design system possibilities?

How do we encourage shared ownership, maintenance and contribution to the design system?

How to do theming in our design system colours?

Moving to a tokenised approach to naming components and elements in our front end library and figma