Greta BartkuteProduct designer

Case study 01 · Fashion Cloud · Design system

Making the design system work for the team

I led the rebuild of Fashion Cloud's design system: reusable components, clear rules and one shared process, so teams build with less guesswork.

Role
Lead product designer
Team
Me, 2 designers, engineering, then the Platform team
Timeline
2025 to 2026
Status
Live, owned by the Platform team since January 2026
1 · Foundations
  • Inputs / Border / Default
  • Button / Primary / Background
  • Text / Darker
2 · Components
  • 1Search input from the Components librarySearch
  • 2Select from the Components librarySelect
  • 3Toggle switch from the Components libraryToggle switch
3 · Product: the Reorder key page
The Reorder key page built from library components: search, filter selects, toggles and article cards 1 2 3
Numbers show where each component is used.
Outcome

One shared system for Figma and code. Teams build new features from finished, documented parts, with less guesswork and less back-and-forth.

70+

Components in code, documented in Storybook

35+

Component sets rebuilt in Figma

All

New features built with the new UI

About the project

Fashion Cloud's design system, rebuilt so Figma and code describe the same components.

My role
  • Led the component approach and the rules between Figma and code
  • Set one process for every component, from Figma page to Storybook
  • Designed foundations, tokens and components with 2 designers
  • Made it a team OKR with my manager to get engineering time
  • Worked with engineering, then handed the code to the Platform team
01 · The problem

The same UI problems were solved in different ways

Every new feature reopened decisions the system should have made.

Three connected issues
  1. Duplicated components. Several components for one job.
  2. Figma and code didn't match. Different names and properties.
  3. Gaps filled by hand. Thin docs, hardcoded UI.
Search in Content and in Smart Replenishment: different fields, filters and layout for the same job
One job, two searches. Content vs Smart Replenishment.
Order area and Auto Restock pages built to different rules
Two pages, two rules. Order area vs Auto Restock.
The old Figma library page Buttons - old: seven button component sets with hundreds of variants
7 button sets, 435 variants in the old library.
Process · How the project ran

From a side project to a maintained library

Not interested in my design process? No worries at all. Skip to the result.

02 · Investigate

Figma, code and the product didn't agree

Two workshops and an audit.

  1. Developer workshop

    ~40 components in Figma, ~90 in code. Lots of hardcoded UI.

    Fix it in code, not only in Figma.
  2. Audit

    4 dropdowns, 7 button sets. Every variation its own component.

    One component per job. Variations become properties.
  3. Designer workshop

    Unnamed tokens. Unclear which colour to use when. Old docs.

    Name tokens by purpose. Document before building.
All designer workshop notes

Creating components

Too many variablesNot all components follow the atomic approachMost components are built

Structure

Duplication of similar componentsLack of key pages in the systemComponent groups on separate pages

Foundations

Foundations are incompleteMissing token namesColours unclear when to use

Updating

Need a better way to review componentsBranchingSlack for reviews

Audit

No audit

Documentation

Takes a lot of time to writeSome is out of dateHard to see all component states

Pink: doesn't work. Green: works.

03 · The direction

Build on a library, not from scratch

We didn't have the engineering time to build everything. PrimeNG for standard parts, custom work only where the product needs it.

Choosing a base

Three libraries, one fit

Design needed
Our own look: colours, type, spacing, icons
Engineering needed
Angular, easy theming, enough components, Storybook
Angular Material
  • Not flexible enough
Taiga
  • Rigid UI
  • No custom icons
PrimeNG
  • Biggest set of components for our data-heavy B2B product
  • Themeable with our own tokens
Chosen
04 · The component model

One component per job, with properties for the differences

Not merging for its own sake. One rule about behaviour and structure, checked for every component.

The rule

Same job, same component

  1. IfSame job, same behaviour, same structureOne shared component
  2. IfA real difference in size, state or label styleA property on that component
  3. IfThe behaviour is differentIts own component, documented next to it
Example

Four dropdowns became two

Before · old library4
  • Old single select dropdownSingle select
  • Old multi select dropdownMulti select
  • Old tree select dropdownTree select
  • Old tree select with a badgeTree select with badge
After · Components library2

Select

The new Select in Figma: placeholder, filled, invalid and disabled states, closed and open
Replaces
Single select, Multi select

Tree Select

Replaces
Tree select, Tree select with badge

Multi select and the badge are now settings, not separate components.

Structure

Built from smaller parts

Atoms make an option, options make the panel, input and panel make the Select.

35+ component sets were rebuilt this way.

05 · Tokens

Tokens carry each decision from Figma to code

Components never use a raw colour. Every value goes primitive → semantic → component.

Try it

One token chain, three layers

Primary button state
1 · Primitive
color-primary-700
#4630D2
89 primitive colours in 7 ramps.
2 · Semantic
buttonComponent- primaryType- defaultState- backgroundAttribute
Figma: Button / Primary / Background / Default
185 semantic colour tokens in 8 groups.
3 · Component
The Primary button in the Figma library in Large, Normal and Small, across Default, Hover, Active, Disabled, Loading and Focus
Each state reads its own token. Change it once, every button follows.

Also: 22 primitive and 44 semantic sizes, 19 type tokens.

Foundations: colour, spacing, radius and type
Colour · 7 ramps
Primary050–950
Neutral000–999
Success050–900
Warning050–900
Error050–900
Information050–900
Promotion050–900
Spacing · Space/0 to Space/80
Space/2
Space/4
Space/8
Space/12
Space/16
Space/24
Space/32
Space/48
Space/64
Radius
xs2px
sm4px
md8px
lg12px
xl64px
Type · Font size 8 to 32, Regular and Bold
Aa10
Aa12
Aa14
Aa16
Aa20
Aa24
Aa32
8 semantic colour groups · tokens named for what they colour
  • BackgroundPage, article card
  • BorderGeneral strokes
  • TextParagraphs, headings
  • FormsInputs, dropdowns, accordion
  • LinksText links
  • ButtonEvery button type
  • StatusBadges, tags
  • MessageMessages, toasts
06 · Document and build

The same name in Figma and in Storybook

A reviewed Figma page first. Then a themed PrimeNG wrapper in Storybook, with the same name and properties.

Figma → Storybook

Same name, same properties

The Select in the Figma Components library: Basic and Float Label types, default, selected, invalid and disabled states, closed and open
Figma
Fashion Cloud Storybook: the Select story open with search, and its controls: optionValue, disabled, loading, group, floatLabel, filter, emptyMessage, filterBy, filterPlaceholder, fluid
Storybook
Name
Select
Select · Grouped Select
Label
Type Float Label / Basic
floatLabel True / False
Search
Panel With search
filter True, with filterPlaceholder
Disabled
State Disabled
disabled True / False
Documentation

One page template for every component

The Select and Tree Select documentation page in Figma: links to both components in code, then every variant laid out and labelled

Every variant shown and labelled. One reference for design and engineering.

  • LinksTo each component in code
  • OptionDefault, hover, selected, disabled, indeterminate
  • DropdownSingle, multi, tree, with search

Reviewed and marked "Ready for development" before handover.

07 · Implementation and adoption

A plan without engineering time stays in Figma

With my manager, I made it a team OKR to get developer time.

2025 to 2026

How the commitment grew

  1. 2025Side project

    Workshops, audit, first components.

  2. May 2025Team OKR and the ask

    Vision, cost of today, plan, and a small ask: 3 developers.

  3. CooldownFirst wrappers

    First PrimeNG wrappers.

  4. SprintA dedicated sprint

    A full sprint for the library.

  5. AgreementDefault for new features

    New UI for every new feature.

  6. January 2026An owner

    Platform team maintains the code.

08 · The result

Feature pages built from the same parts

Every new feature is built with the new UI. Drag to compare.

Before / after

Reorder page

The Reorder page built with the new UI
The live Reorder page in 2024, before the rebuild
Before · 2024After · new UI
Before / after

Create organisation form

Create Brand Organisation form built with the new UI: float label inputs and select
Create Brand Organisation form before: underlined fields
BeforeAfter · new UI
Before / after

Marketing material

Marketing material overview built with the new UI: boxed search and filters, folder cards with item counts, and a summary bar
Marketing material overview before: underlined filters, plain image tiles and a different summary bar
BeforeAfter · new UI
Before / after

Brand profiles

Brand profile page built with the new UI: brand details and brand assets in grouped panels
Brand profile page before: banner image, underlined fields and a separate logo column
BeforeAfter · new UI
Feedback

What the team said

  • We don’t have to reinvent the wheel every time we build a new feature. The patterns are already there, so we can focus on solving the actual problem.
    Designer
  • Fewer back-and-forth questions during development. The specs answer them before we ask.
    Engineering lead
  • When I demo to brands, the product feels consistent and professional, which builds trust.
    Sales
  • More intentional and cohesive.
    Product manager
Reflection · Decisions and what they cost

The hard part was never the design

Getting engineering time and adoption was. Four calls, each with a cost.

DecisionContextWhat we didGave upGot
A third-party libraryNo engineering time to build and maintain standard components.Theme PrimeNG with our tokens. Custom work only where the product needs it.Full control, and some visual freedom.Standard parts we didn't build. Design and code stay close.
A team OKRSide projects don't get engineering time. OKRs do.Made it a team goal, with my manager.Speed. Securing commitment took several rounds of alignment.A cooldown, a sprint and a PM agreement.
New features firstNo team for a big migration.Build every new feature with the new UI.Old and new UI side by side for a while.New components reach the product feature by feature, so users adjust gradually instead of waiting for one big switch.
Platform owns the codeA library without an owner in code drifts again.Handed the code library to the Platform team.It stays maintained without depending on me.
Still missing
  • The grid in code
  • Older pages still on the old UI
  • Making the system readable for AI tools
Next time
  • Plan the rollout per product area. From day one, not only for new features.
  • Agree ownership at the start, so Figma and code don't drift apart.