Joined Storable • Ongoing
Overview
The existing design system gave the product team a starting point, but as the product evolved, it became clear that the system had not yet reached the level of maturity needed to support the growing number of product experiences and use cases.
Components had been created over time to solve immediate product needs, but the underlying foundations, variables, component architecture, and patterns were not structured consistently enough to scale.
Rather than continuing to add components on top of the existing structure, I took a step back and approached the problem as a system redesign.
I used the existing system as a base, audited what was already there, retained the parts that were useful, and rebuilt the core structure to create a more consistent and scalable foundation.
The goal was not to create the biggest possible component library.
What did I do?
The Challenge
The original system had established some common UI patterns, but it had evolved organically.
As more features were added, several challenges became apparent:
The challenge wasn't simply a lack of components.
Starting With What Already Existed
I didn't approach the work as a complete replacement of everything that had been designed previously.
The existing system contained valuable product knowledge.
I audited the existing library to understand:
I categorized the existing work into four groups:
This gave the redesign a clear starting point while avoiding unnecessary disruption.
Rebuilding the Foundations
The first step was to establish a stronger foundation before rebuilding individual components.
I focused on creating a consistent structure for:
The intention was to move away from individual component decisions and establish shared system-level decisions.
Core Components
With the foundations in place, I focused on rebuilding the core components that form the backbone of the product experience.
This included:
Each component was designed with consistent variants, properties, states, sizing, and interaction behavior, creating a reliable foundation for building product experiences.
Creating a Stronger Variable Architecture
Variables became one of the most important parts of the rebuild.
Instead of allowing components to directly use arbitrary values, I structured the system around relationships between foundational and semantic values.
This included:
Each component was designed with consistent variants, properties, states, sizing, and interaction behavior, creating a reliable foundation for building product experiences.
These defined the raw building blocks of the system.
For example:
Color
→ Brand colors
→ Neutral scale
→ Success
→ Warning
→ Error
Spacing
→ 4
→ 8
→ 12
→ 16
→ 24
→ 32
These values were intentionally kept independent from specific component use cases.
Semantic variables
These values were intentionally kept independent from specific component use cases.
Semantic variables gave those foundations meaning within the interface.
For example:
Neutral / 100 → Background / Primary
Neutral / 700 → Text / Secondary
Brand / 500 → Action / Primary
This created a relationship between what a value is and how it is used.
That distinction became especially important when introducing themes.
Designing for Light & Dark Themes
One of the key requirements was making the system capable of moving between light and dark themes without visual detachment or component-level overrides.
Instead of creating separate component styles for each theme, components consumed semantic variables.
This meant the component didn't need to know whether it was being used in a light or dark environment.
The architecture
Primitive
→ Color / Neutral / 900
↓
Semantic
→ Surface / Primary
↓
Component
→ Input / Background
↓
Experience
→ Website Builder
This made theme switching much more predictable and reduced the risk of individual components breaking when the theme changed.
Building a Consistent Component Architecture
With the foundation established, I rebuilt the component layer around a consistent structure.
Each component was designed with clearly defined:
Variants
Different functional or visual versions of a component.
Properties
Configurable attributes exposed to designers.
States
Default, hover, pressed, focus, disabled, selected, error, and other relevant states.
Interaction behavior
Clear expectations for how components respond to user actions.
Sizing
Consistent sizing rules across components.
This created a more predictable component architecture and reduced the need for designers to modify components manually.
From Components to Patterns
A design system becomes valuable when components start working together.
Rather than treating every component as an isolated asset, I focused on how they could combine into reusable patterns.
For example:
Input + Label + Helper text + Validation
became a repeatable form pattern.
Similarly:
Button + Icon + Loading state
could support multiple interaction contexts without creating separate components for every scenario.
The goal was to make the system flexible enough to support different product requirements while maintaining consistent behavior.
Design System 2.0
could support multiple interaction contexts without creating separate components for every scenario.
The goal was to make the system flexible enough to support different product requirements while maintaining consistent behavior.
What am I doing now?
I manage the design system as a side project, optimising the process for designers to request changes via a dedicated channel and Figma branch.
As the only designer in the Design System team, I collaborate with developers to gate-keep the system.
Part of this side gig includes reviewing Figma files from various verticals to ensure consistency and quality.
KPIs that we are tracking
Percentage of components from the design system actively used across projects.
Regular feedback surveys to measure satisfaction levels of designers, developers, and stakeholders with the contribution and component edit processes.
Number of reported errors or issues related to contributed designs or components.
What I Learned
The biggest lesson from this project was that a design system isn't primarily a UI library.
It's an architecture for making decisions consistently.
The strongest systems aren't the ones with the most components.
They're the ones where designers can understand:
Why a component exists
When to use it
How it behaves
How it adapts
How it connects to the rest of the system
How it can evolve without breaking existing experiences
This shift—from building components to designing relationships between them—changed how I approached the entire system.
Looking Forward
The next evolution of the system is to make it increasingly connected across design and development.
The goal is to establish a stronger bridge between:
with stronger documentation, automated consistency checks, accessibility considerations, and AI-assisted maintenance.
The long-term goal isn't simply to have a larger design system.
It's to create a system that makes building better products faster, more consistent, and more resilient to change.
Thanks for watching 😀
How I redesigned Inventory widget experience
