CCD Design System
One file. Every token, style, and component for three apps, built from scratch and held in a single source of truth.
01 CONTEXT
Three apps, one system to bind them
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 working when we came in, but they had grown without a shared language. They functioned, yet nothing held them together: no common foundation, no systemic backbone to keep them consistent as they evolved.
Concordium brought us in to build that foundation alongside shipping live features. There was no token layer and no component library the three apps drew from. The work was to build one, and to build 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 each defined 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 there doesn't just look unpolished, it undermines the sense that the product is secure and considered. The system had to make coherence 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. 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 reasonably 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, and forms 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 stay legible at a glance. One place to look, one place to change, nothing to keep in sync across files.
LAYER 02
Components built to flex, every state accounted for
Each component carries 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.
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 with no one hand-copying a value. Components themselves were coded manually against the designs, and the token layer, the part most prone to silent drift, was automated end to end.
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 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.
04 DECISIONS
Two calls worth walking through
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 alternative was to pack everything, foundations and all three products, into a single file.
WHAT WE 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 team and product count grow. Concordium was nowhere near that ceiling, and the daily cost of managing linked libraries was the more immediate price. For where they were, 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 WE CHOSE
The pipeline. We scoped it, documented every step in Confluence, and tested it against live product work until it proved itself. The resistance was reasonable, so we 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, ours 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
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 at the start.
One lesson carried forward: write the conventions down as they form, not once the system is stable. A lot of the rules lived in review conversations, which works with one designer but slows onboarding the next. Documenting as you go makes the whole thing easier to hand off.
- 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 in a single unified file.
- 1
- design system, built to lastConventions, 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, consumed natively by every platform.
