top of page
Stena
design system
Co-led the restructuring of a fragmented, unscalable component library into a clear five-layer design system for Stena Recycling's Customer Portal, facilitating a workshop with five designers to build consensus, recataloging 71 components, and auditing design-to-code alignment against Storybook.
Project Overview
Stena Recycling's Customer Portal design system components lived on ungrouped Figma pages, were named inconsistently, and often diverged from what developers had actually built in Storybook. I helped turn that fragmented library into a documented, governable design system: from a full inventory of what existed, to a structure the design team agreed on, to a clear record of where design and code had drifted apart.
Responsibility: Component auditing & categorization, workshop facilitation, tagging system design, Figma–Storybook alignment audit
Keywords: Design Systems · Design Ops · Workshop Facilitation · Cross-functional Alignment
Introduction
The mission is to turn the Customer Portal's design system into something scalable, searchable, and aligned with what engineering actually builds. My contribution fell into three parts: ① making sense of what already existed, and rebuilding it into a structure the whole design team could actually agree on, ② making that structure governable long-term through a tagging system and a few standards I noticed were missing, and ③ closing the gap between what's designed in Figma and what's actually built in Storybook, and aligning the findings across teams and developers.
my responsibility
.png)
① Structure — Co-hosted a workshop with 5 designers to build shared categorization logic, then recataloged all 71 components into a coherent library with two complementary views
② Governance — Designed a component card system that surfaces usage frequency, configurable properties, and a direct Storybook link at a glance, and proactively proposed three additional standards outside the original brief: Capitalization Rules, UI Text Styles, and Unit conventions
③ Alignment — Audited where the Figma library and the Storybook implementation had drifted apart, and helped define the system's first component variants
From Consensus to Structure
Before proposing any new structure, we needed to know what actually existed. I went through the Customer Portal's key product areas and mapped every component to the screens it appeared on — and every screen back to the components it used. This System Coverage Map became the evidence base for everything that followed: which components were core, which were duplicated across teams, and which were legacy.
Why a workshop, not a decision memo?
We could have picked a categorization scheme ourselves and documented it. We didn't, on purpose: we wanted it to survive contact with the team that has to use it every day. So I co-hosted a workshop with five designers, walking through the full inventory together and working toward a categorization logic the team recognized as their own, not one imposed on them.
That shared logic became the backbone of the new library. All 71 components were recataloged into two complementary views:
List Overview — a searchable text index for quickly locating a specific component by name.
Visual Overview — every component tiled by category (Buttons, Cards, Controls, Input, Navigation & Menus, Page Content, and more), so the entire system can be scanned visually in under a minute.
List Overview
Visual Overview
Underneath both views, every component was also mapped to one of five system layers — Foundations → Primitives → Layout → Content → Pages — giving the library a structural backbone that's invisible in day-to-day use, but essential to keeping it scalable as new product lines get added.
Making the System Governable
A reorganized library solves discoverability today, but it doesn't stay organized on its own, and it doesn't tell you which components actually matter. So for every component, I designed a card that surfaces three things at a glance: what it is, how it can be configured, and how much it's actually used.
In the Visual Overview, each component: Buttons, Cards, Controls, and so on, appears as a card showing the component's name, a live thumbnail of its variants, and a row of chips listing its configurable properties (e.g. Show left icon, Show right icon, Instance swap icon, Loading). Next to the name sits a colored dot: green for frequently used, orange for occasional use, red for components that are barely touched, drawing on the same usage patterns mapped in the System Coverage Map.
A designer can tell whether they're looking at a core pattern or something rarely used without opening a single file.
Clicking through opens that component's own page, carrying the same name, chips, and frequency indicator, plus everything needed to actually use it correctly.
Below the Component banner, it shows every variant and state (default / hover / pressed / disabled, across primary, secondary, tertiary, text, and icon-only styles), spacing and icon-placement rules, guidance on when to pair primary with secondary or tertiary buttons.
And below the Documentation banner, showing how the components have been used in practice.
I also added a chip that didn't exist in the original card view, a direct Storybook link, so anyone can jump from the design source straight to what's actually implemented in code.
Outside the original design system, I also noticed a few gaps nobody had assigned but that were already causing visible inconsistency, and proactively proposed three additional standards: Capitalization Rules, a UI Text Styles guide, and a set of Unit conventions: the kind of small, easy-to-skip decisions that quietly fragment a product when nobody owns them.
Aligning Design and Development
A design system is only as trustworthy as its fidelity to what's actually shipped. So the last major piece of this initiative was auditing how closely the Figma library matched Storybook — the library developers build from.
Working through both libraries side by side, I catalogued:
① Naming mismatches — for example, what's called a Progress tracker in Figma is a Progress bar in Storybook; an Input field in Figma is a Text field in Storybook; a Chip button in Figma has a Storybook counterpart only for its multi-select variant, with other variants filed under a different name (Dropdown button) entirely. In total, the audit surfaced 6 direct naming mismatches like these.
② Components missing from Figma — things developers had already built (a Week picker, a Link card, a Loader) with no corresponding source of truth in design.
③ Components missing from Storybook — the reverse: components designers had defined that had never been built standalone, or existed only folded into a larger composite component in code.
④ Gaps in typography and color — bold heading styles and mobile/email-specific type that existed in Figma but weren't reflected in Storybook's tokens, plus at least one color flagged as duplicated in Storybook.
Rather than write this up as a one-off report, I tagged each finding directly on the component ([storybook] vs. [external]), so the gap between design and code became something the whole team could see and track inside the file itself.
Quantifiable Results
-
Recataloged 71 components into a two-view library (List Overview + Visual Overview) structured across 5 system layers.
-
Co-hosted a 5-designer workshop to build categorization consensus before any restructuring began.
-
Designed a 3-dimensional tagging system (Layer / Intent / Status), fully searchable inside Figma.
-
Proactively introduced 3 additional standards beyond the original brief: Capitalization Rules, UI Text Styles, and Unit conventions.
-
Audited Figma–Storybook alignment, surfacing 6 direct naming mismatches and multiple components missing on each side.
-
Delivered the system's first version of component variants, starting with color, across buttons, tags, and cards.
What I Learned
A design system is an agreement. The structure only became real the moment designers and developers looked at it and recognized it as their own, not something handed to them.
bottom of page