CCD Design System

One file. Every token, style, and component for three apps, built from scratch and held in a single source of truth.

ROLE: Senior Product Designer
COMPANY: Concordium
TIMELINE: Mar 2025 – Mar 2026
PLATFORMS: Multi-product

01 Context

Three apps, one designer, no system yet.

Concordium is a privacy-first layer-1 blockchain. The product surface spans three apps: a mobile wallet, a browser-extension wallet, and Concordium ID, a standalone identity app. All three were built and functional when I joined, but they had grown without a shared language. They worked, yet nothing held them together: no common foundation, no systemic backbone to keep them consistent as they evolved.

I came in as the senior product designer on the suite, and the only person on the team positioned to build a design system. There was no shared foundation underneath the products, no token layer, no component library the three apps drew from. The work, alongside shipping live features, was to build that foundation, and to do it as a single, unified system rather than three that happened to look alike.

02 Problem

A system was the obvious need. Adoption was the real problem.

Building the library was the tractable part. The harder problem was that a design system only works if everyone downstream actually uses it, and most of the people downstream had never worked with one. Three pressures defined the job.

Three apps drawing the same things separately.
Mobile wallet, browser wallet, and ID app were each defining their own buttons, inputs, colours, and spacing. The apps already shared a family resemblance, but nothing enforced it. Every shared element existed in three slightly different versions, and every change had to be made three times, three chances to drift.
A trust product, where inconsistency reads as risk.
This is a wallet on a privacy-first blockchain. Users are confirming transactions and guarding recovery phrases. Visual inconsistency in that context doesn’t just look unpolished, it undermines the sense that the product is secure and considered. The system had to make trustworthy and coherent the default, not something each screen re-earned by hand.
Engineers with no design-system habit, and no appetite for one.
The system’s real test was the handoff. The frontend leads were experienced engineers who had always read values straight off a mockup. Introducing design tokens meant asking them to adopt an unfamiliar pipeline and trust a source of truth they hadn’t built. The early reaction was resistance, and rightly so, until the workflow proved it was worth the change.

03 Work

One file, one pipeline, and a workflow people would actually follow.

The system came together across four fronts: the single file and how it was organised, the components built inside it, the token pipeline that carried it into code, and the workflow that kept it maintained. They were built together, not in sequence. The craft was in the components and the tokens; the workflow is what made any of it stick.

Layer 01

One file, organised so anything is findable.

CCD was built as a single source of truth: every variable, style, and component for all three apps in one file, rather than a foundation with separate product libraries branching off it. Inside, everything has a clear home. Shared foundations, icons, buttons, forms, and the like, live on their own pages, while anything specific to one app sits on its product page: Mobile Wallet, Browser Wallet, ID App. An Intro page carries the versioning system and a version-specific changelog, so the state and history of the system stay legible at a glance. One place to look, one place to change, nothing to keep in sync across files.

One file holding variables, shared assets, and product-specific components, organised by purpose.

Layer 02

Components built to flex, every state accounted for.

Each component was built to carry its full range inside a single, structured definition: variants, states, and sizes handled through properties rather than scattered across separate copies. Spacing, colour, and typography bind to the same variables that feed the rest of the system, so a token change reshapes every instance at once. The result is components a designer can drop in and trust, and an engineer can read straight off the file, with the structure doing the work rather than convention or memory.

A live screen from the Mobile Wallet, with key components and their properties called out.

Layer 03

From Figma variables to native code, automatically.

Variables were exported as JSON tokens, run through Style Dictionary to translate them into a format each platform's codebase could consume, and pulled in directly by frontend. A colour or spacing change made once in Figma propagated to every platform without anyone hand-copying a value. Components themselves were coded manually against the Figma designs, but the token layer, the part most prone to silent drift, was automated end to end.

Variables exported as JSON, processed through Style Dictionary, consumed natively by each platform.

Layer 04

A versioned workflow, and the case for using it.

System changes happened on a branch under a specific version number. When the design was done, the branch was merged and the library republished; if variables had changed, the new tokens were exported down the pipeline. The whole workflow, every step for both designers and engineers, was documented in Confluence. Getting there took real persuasion: scoping the change, explaining the payoff, and testing it against live work until the people who'd resisted it agreed it was the way to build.

Branch by version, merge, publish, export. The workflow documented end to end in Confluence.

04 Decisions

Two calls I'd defend to a skeptical peer.

Most of the work was technical and uncontroversial. These two weren't. They were about architecture and risk, and they're the ones worth showing the reasoning behind.

Call 01

Build one unified file, not a foundation with linked libraries.

The conventional structure for a multi-product system is a shared foundation file feeding separate, linked product libraries, the model I’d used before. The alternative was to pack everything, foundations and all three products, into a single file.

What I chose

A single file. For a team this size, one source of truth meant no cross-file linking to maintain, no version-skew between a foundation and its dependents, and one place to look for anything. The simplicity paid for itself daily.

Trade-off

A single file scales less gracefully than a federation as a team and product count grow. The team was nowhere near that ceiling, and the daily cost of managing linked libraries was the more immediate price. For where Concordium was, single-file was the right call.

Call 02

Invest in a real token pipeline, despite the pushback.

The path of least resistance was to hand engineers the Figma file and let them read values off it, the way they always had. The harder path was building the JSON-to-Style-Dictionary pipeline and asking experienced engineers to adopt an unfamiliar workflow they were openly skeptical of.

What I chose

The pipeline. I scoped it, documented every step in Confluence, and tested it against live product work until it proved itself. The resistance was reasonable, so I treated it as something to earn past rather than override, by making the workflow demonstrably better than reading values by hand.

Trade-off

It cost time up front, mine to build and document, theirs to learn, and it spent goodwill before it earned any back. But hand-copied values are exactly where a design system silently rots. Automating the layer most prone to drift was worth the early friction.

05 Outcome

What shipped, and what I'd do differently.

All three Concordium products run on the same design system: mobile wallet, browser wallet, and Concordium ID. Every token, style, and component lives in one file. Designers and frontend engineers reach for the same tokens by the same names across the suite, fed into each codebase through one shared pipeline. The engineers who pushed back hardest on tokens ended up relying on them. None of that existed when I joined.

If I were doing it again, I'd write down the working conventions earlier. A lot of the system's rules lived in my head or in review conversations, which was fine with one designer but would have made onboarding a second much slower. Documenting conventions as they formed, rather than once the system was stable, would have made the whole thing easier to hand to someone else.

3: apps on one systemMobile wallet, browser wallet, and Concordium ID, all drawing from the same source of truth.
1: file, one source of truthEvery variable, style, and component for all three apps packed into a single, unified file.
1: designer, built soloConventions, design language, components, and the branching and versioning workflow, all built from scratch.
100%: token coverage to codeVariables exported as JSON, run through Style Dictionary, and consumed natively by every platform.

Let's Work Together

I'm always interested in hearing about new projects and opportunities. Whether you need a design partner, want to collaborate, or just want to say hi. I'd love to connect!

Email Me

CCD Design System

Three apps, one designer, no system yet.

A system was the obvious need. Adoption was the real problem.

Three apps drawing the same things separately.

A trust product, where inconsistency reads as risk.

Engineers with no design-system habit, and no appetite for one.