Design System

The Impact

• A system the design team actually wanted to use, instead of working around
• Engineering parity through Storybook, mapping each component to real code
• Accessibility built in, resolving the contrast complaints that dogged the old system
• 56 ready-to-use components, 120 tokenised colours, and 14 typographic styles

Problem

ShipServ's original design system had done its job once, but it had drifted. Over time it fell out of sync with the live platform, and the gaps had real consequences for both design and engineering.

Components in Figma no longer matched their production counterparts, so designers couldn't trust what they were building. The colour system had no order or logic, which made tokenisation impossible and left engineering without a clean set of variables to work from. Suppliers and internal users kept flagging colour-contrast problems. And there was no documentation for any component, so usage was guesswork. The system that was meant to create consistency had become a source of friction for everyone touching it.

Team & business goals

1. Refactor the design system so design and engineering could work in step rather than around each other.
2. Rebuild the colour system so it could be tokenised and scaled.
3. Rework the component library to use the Figma features the old system never leveraged.
4. Integrate with Storybook so developers could match components to real code.

My role

As the sole UX designer on this, I owned the full refactor and its implementation.

• Built, reworked, or retired roughly 107 components across the refactor, landing on a final library of 56.
• Rebuilt the colour system from scratch so it could be tokenised, expanding to 120 scalable colours with accessibility built in.
• Remapped the typographic system, cutting redundant styles down to 14.
• Asked engineering for their stylesheets at the very start, so the system aligned to their code from day one rather than being retrofitted later.
• Helped test the integration in staging through to Storybook.

My approach

Build it adjacent so I never disrupted live design work, align to engineering's code from the first day, and use atomic design so the system was built in the right order, foundations first.

Research

I started by auditing what we already had: the typography, the component library, and the colour system. The goal was to map exactly where it was failing and where Figma's newer features could do work the old system wasn't using.

Alongside the audit, I taught myself design-system best practice and adopted atomic design as the organising logic. That gave me a clear order to build in, foundations first, then atoms, then upward, rather than rebuilding piecemeal.

The plan

Before building anything, I set out how to do it with the least disruption.

The core decision was to build the new system adjacent to the old one rather than tearing the old one out. The team was still designing live work every day, so a clean-room rebuild alongside the existing system meant I never blocked anyone while it came together.

From there the plan was concrete: a comprehensive component list marking what to build, refactor, or remove; a full breakdown of the colour system with redundant colours stripped and a proper mapping added; a typographic cleanup; and engineering involved in implementation from the start.

How I built it

Using atomic design, I started at the foundations, colours and typography, since everything above depends on them. Then I moved to the atoms.

Buttons were the first real test. Even at the smallest level, the old button had many variants and almost no flexibility. Rebuilding it with nested components and variables turned a rigid set of one-offs into a single flexible component, and proved the approach for everything above it.

The piece I was proudest of was the table cell component. ShipServ uses tables constantly, and the old system could never capture every use case in one component. By designing a single, flexible cell, tables became fast to build and genuinely scalable, which removed one of the most repetitive jobs in the team's day.

The result

The finished library landed at 56 components, 120 scalable colours, and 14 typographic styles. More importantly, it changed how the team worked: designers stopped fighting the components and got to concentrate on the actual problem, and engineering had a system they could map straight to Storybook.

Measured against the goals: the system was refactored and adopted, the colour system was fully tokenised, the component library used Figma's nesting and variables properly, and the Storybook integration gave developers real parity with code.

Reflection

This ended up far bigger in scope than I expected going in, and that was the lesson.

• A design system is mostly not the components. Building components is the fun, visible part, but it's a small slice of the work. Getting it to translate cleanly into production is the much larger effort, and the part I underestimated.
• Engineers make or break it. I didn't fully grasp at the start that without the dev team, none of this reaches Storybook or gets implemented. Aligning to their stylesheets early turned out to be the best decision I made.
• It has to work for everyone, not just me. Between engineering, UX, solutions, and product, a design system serves a lot of people. It needs to work for all of them, not just the person who built it.