Digital products are built from parts: components, tokens, and the conventions that hold them together. I design that layer: the foundation a team builds on, and what keeps a product coherent as it grows.
This page is a case study of one such foundation. It's also built with it.
Background
I joined SOON_ as an intern in 2015 and left as a senior designer in 2025, shortly before the agency closed. SOON_ was a London agency specialising in digital product and e-commerce. We were a small team. What follows is the approach I developed there.
If something works, keep hold of it: name it, structure it, use it again. And revisit it, because nothing stays fit for purpose on its own. For a long time the design tools couldn't hold that way of working. When tools built around components and shared libraries arrived, a source of truth you could actually point at, the ideas finally had somewhere to go. SOON_ was the kind of place that would let a designer evaluate a new tool and test it on live projects, so as the tools changed, the way we worked changed with them.
When the team was small we blended roles and shared the load. When it grew, the load spread, and I could go deeper on the work I was most drawn to. Prototyping, most of all: a mock-up walks through one path, but a prototype holds states and conditions, all the ways a thing can behave. That non-linear way of working made immediate sense to me, and the more of it I did, the better I got.
The clearest example of that structural instinct is MOX, the pattern library we worked from. It took shape when the agency's focus narrowed to e-commerce: repeat patterns became worth consolidating, and a client build gave us the moment to do it. The coded components came from the tech team, who knew the landscape and chose Svelte for the job. I consolidated the design side to match, running alongside them. Shared structure, clear naming, one place to look. It became the thing new work started from.
Pt. 1
Every component and token in one place, pulled from the library this page is built on, not a mock-up of it.
Think of it as an index: a reference guide to the patterns, keeping the names and structure of the Figma files. Look through what's actually there, rather than take my word for it.
MOX
Storefront pattern library for e-commerce sites. The baseline system, neutral or trying to be, that became the agency's starting point for new work.
Merch Tools
What clients used to manage their products and content: a product the agency built and offered alongside the storefronts. A work in progress, and an opinionated one.
Pt. 2
The components were built by hand, which leaves room for drift. Design debt accrues quietly. Formalising the structure closes that gap.
Fewer parts, clearly defined, referencing each other cleanly. This is the pipeline that pulled two production libraries into one portable foundation, every step of it recorded.
Two production Figma files: MOX (storefront UI) and Merch Tools (CMS UI). Each carries four variable collections: primitives, colour, layout and typography, with the alias chains intact.
Claude Code read both files over the Figma MCP server: names, types, values and alias chains, straight from the Variables API. Component bindings were extracted separately, frame by frame, and committed as structured JSON.
Everything lands in the repo as JSON snapshots: two files capturing the variable definitions from both systems, plus one per component recording its design values. Token references, dimensions, variants, structure.
A Python script that consolidates both source files into one portable foundation. Primitives are defined once and shared; semantic tokens alias into them, and the chain from component to token to primitive is kept in the output, not flattened to hex. Names from both systems were reconciled into one namespace, with the duplicates removed.
Generated by build.py. Raw primitives first (--prim-*), then the semantic properties that reference them (--color-*, --layout-*, --type-*). Light/dark and every density mode switch in plain CSS, via data attributes; no JavaScript.
100+ components across both systems, each binding straight to the CSS custom properties. Components reference tokens; the deliberate exceptions are documented.
500+ raw variables in, 300+ tokens out.
Pt. 3
The same tokens and components, put to work.
I finished ten years at SOON_ in 2025 and started the MA Photography Practice at Goldsmiths that September, just as AI tools were taking off in design workflows. That put me in an odd and useful position: watching from inside a student bubble, able to test things without real consequences. For a while I put off engaging with it properly. Towards the end of the year, things had settled enough that the question I'd been circling felt answerable.
Years of structure was already sitting in the agency's Figma files: the parts, the naming, the relationships. Rather than guiding every pixel again, could all of that be extracted once and referenced from then on? This page is the test, and the randomiser below is the proof.
It began as a thirty-minute lunchtime experiment during the MA. The course put weight on diptychs and triptychs, on what images do to each other when placed side by side, and I'd been pairing my photographs by hand: printing, arranging, observing. But I noticed I was editing before I'd even touched an image: ruling out pairings in advance, deciding before looking. The randomiser forces combinations I wouldn't have chosen, and surfaces relationships I'd have missed. It was never meant to replace the hand-done version. It catches what falls through the net.
The images are my own, most of them taken walking the London Outer Orbital Path and the Capital Ring. Shuffle, and see what turns up.
Summary
I approached this page as an R&D exercise: could a foundation extracted from Figma carry a real build, end to end?
It could, and the quiet result is that nothing needed reworking in Figma first. The files were already structured for it: the naming, the relationships, parts defined once and reused. Work that was put in order years ago turned out to be ready for tools that didn't exist yet.
On this build I directed and collaborated, the way I've always worked with engineers. I built this page with the same stack. The judgment calls were mine: what belongs in the system, what stays out, when to conform and when to deviate.
A foundation like this is never really finished. You make the best version you can, then keep improving it as it gets used. This page is where this one gets used.
Background
Where it starts.
Pt. 1
Every part, laid out.
Pt. 2
Pulled into one foundation.
Pt. 3
Put to work.
Glossary
A few words I use precisely, so we mean the same thing.
Component
A reusable piece of interface: a button, a card, a menu, built once and used wherever it's needed, so it looks and behaves the same in every place. On this page they exist twice over: designed in Figma, and coded for the build.
Token
A named design decision: one colour, one spacing step, one type size, stored once and referenced everywhere it applies. Change the token, and everything using it follows.
Pattern library
A set of reusable parts: components, tokens, and the rules for how they fit together, made for one brief and one context, not as a universal template. MOX is a pattern library. So is the foundation this page runs on.
Design debt
What builds up when work drifts from the system. Detached components, one-off variants, decisions made outside the structure. Tooling slows it; a team using the system is what keeps it down.
Design system
A pattern library plus everything around it: brand and voice guidelines, documentation, governance, and a team to keep it alive. I've laid the kind of foundations design systems grow from.
The back-end of design
My shorthand for the structural side of the work: the foundations, tokens and pattern libraries that sit behind what you see and keep it consistent. It's a location, not a rank; the structural side sits beside the visual side, and depends on it.