Selected workProject 4 of 4

Plinth

A grocery marketplace that had 24 kinds of button now builds from one library of tokens and components shared by design and code.

Role
Design systems designer
Team
2 product designers, 4 front-end engineers, me
Timeline
5 months
Tools
  • Figma
  • Storybook
  • VS Code
  • Claude Code
Platform
Web and mobile web

Sample project. Replace with real work.

Plinth component sheet: colour ramps in plum and saffron, a type scale, button states, an input, and four product cards.
The core sheet: colour, type, actions, inputs and the product card. On screen: Tokens; Five buttons, that’s all; Parts compose the card.
The Marketday storefront built from Plinth, on a laptop and a phone: a plum banner and rows of grocery product cards.
The storefront rebuilt from Plinth components. On screen: Banner, made of parts; Product cards, same parts; Same library on the phone.
Diagram of three rows of tokens, primitive, semantic and component, with dotted lines showing how each component token points to a semantic token.
Three tiers of tokens: primitive, semantic, component. On screen: Primitive; Semantic; Component.

Problem

Marketday is a grocery marketplace that grew fast and designed every new screen from scratch. By the time I joined, the product had drifted: different greens for “in stock”, product cards rebuilt every sprint, and handoffs that turned into long threads about spacing (sample context for this placeholder project).

Designers and engineers had no shared source of truth, so every screen was rebuilt slightly differently and the product felt less trustworthy than the groceries it sold.

Research

I audited every live screen and collected each unique component, then interviewed six designers and engineers about where handoff broke down (sample research).

I rebuild the product card every sprint because I can’t find the last one. And even if I could, I wouldn’t know which one is right.

Front-end engineer (sample quote)
  • Twenty-four button styles in production, from eight colours and six corner radii.
  • Nobody owned the library. It had components, but no one could say which were current.
  • Names differed between Figma and code, so every handoff needed a translation.
A grid of 24 different button styles found in the live product, in different colours, heights and corner radii.
The audit: 24 buttons doing the same five jobs. On screen: 24 buttons doing five jobs; Same job, different style.

User flows

A design system’s users are designers and engineers, so the flow I designed for was theirs.

From a design need to shipped codeChoose a step to see what happens there.

  1. A designer or engineer needs a button, a card or a banner.

  2. Five buttons and a small set of parts: few enough that people know what is in there.

  3. Use a variant, or compose cards, rows and banners from parts instead of saving a new component.

  4. Semantic names like action-primary, identical in Figma and in code.

  5. No translation step, so the handoff thread is about the product, not spacing.

Key decisions

Three tiers of tokens

Accepted

Primitive tokens (plum-600), semantic tokens (action-primary) and component tokens (button-bg), with components only ever using semantic ones.

Rejected

One flat list of colours and sizes.

Trade-off. More to learn on day one. In return, a rebrand or dark mode becomes a change to one tier instead of every screen.

Fewer variants, more composition

Accepted

Five buttons and a small set of parts that combine into cards, rows and banners.

Rejected

A component for every screen's variation, which the team first asked for.

Trade-off. Designers compose a little more. The library stays small enough that people actually know what's in it.

The rejected direction was the library the team first asked for: every variation from every screen, saved as its own component. It would have made the first month faster and every month after it slower.

The rejected direction: a grid of 48 near-identical component variants.
Rejected: one component per variation. On screen: 48 near-identical variants.

Solution

Plinth ships as a Figma library with variables and a coded package documented in Storybook. Token names are identical in both.

I used Claude Code to generate the first pass of token files and Storybook stories from the Figma variables, then reviewed and corrected them in VS Code. It saved days of typing, and it found three variables I had named inconsistently.

The Marketday storefront rebuilt with Plinth.
The storefront after the rebuild. On screen: Banner, made of parts; Product cards, same parts; Same library on the phone.

Outcome

Placeholder results until real ones are supplied.

  • 24 button styles became 5, and 11 product-card versions became 1 with options (sample).
  • New screens went from design to code in about half the time, e.g. 6 days to 3 (sample).
  • The library has an owner and a monthly review, so it stays current (sample).

What I’d do next

  • Dark mode, which the semantic tier was built to make cheap.
  • Usage analytics on the library, to retire components nobody uses.
  • Contribution guidelines so product designers can add to Plinth without waiting for me.