Concordium Wallet
Two crypto wallets on one design system, and the workflow to keep them coherent. A year of work for Concordium across mobile and browser.
01 CONTEXT
A wallet that grew without a plan
Concordium is a blockchain company. Their wallets, one on mobile and one as a browser extension, are how people hold tokens and interact with the network. They aren't the company's flagship, more a showcase for what the chain can do. That's useful context, because it's why there was room to redesign them this thoroughly.
Concordium brought us in to work alongside their design lead. By then the wallets had passed through enough hands that nothing quite matched anything else. Before redesigning anything, we had to map what was actually there.
02 PROBLEM
Years of decisions, none of them connected
The wallets had been built, and quality wasn't the issue. Most screens were fine on their own. The problem was that none of them knew about each other. Three things had to be true before anything could be redesigned cleanly.
No system, just sediment
Years of decisions had piled up, from internal designers, an external agency, and time. Patterns existed in several flavours. Type rules were inconsistent. Colour drifted from screen to screen. There was no shared foundation underneath, just the residue of many people doing reasonable work without one.
Nothing was where you'd expect it
Figma files were unorganised and components undocumented. Deprecated flows sat next to active ones with no way to tell them apart. Onboarding a designer would have taken weeks just to learn what was where, let alone what depended on what.
Every new feature negotiated with the chaos
Shipping anything meant first deciphering what existed, then choosing whether to follow a pattern, pick between several, or invent one. Velocity suffered, and so did consistency, because everyone made different calls under the same pressure.
03 WORK
Four passes through the same product
The work wasn't linear. Cleanup, system, and product overhaul overlapped, and features kept shipping while the foundation was being poured. It reads more clearly as four passes than as a timeline.
PASS 01
Mapping what was there
The first weeks weren't design. They were untangling: going through every file, flow, and screen to work out what tied to what. Archiving the deprecated. Naming what was alive. Drawing a map of the product as it actually existed, not as anyone assumed it did. Less glamorous than a redesign, and more important than one.
PASS 02
Building the system in the background
While features shipped the old way, the design system went in underneath: tokens, components, documentation, conventions. The wallets became the proof of concept for the whole thing, including the branching and versioning workflow set up alongside it. The design system case study goes deeper. It's its own story.
PASS 03
Realigning the wallets to the system
Once the system was solid enough to lean on, the wallets got their overhaul. Navigation was rethought, with tools once scattered across the homepage pulled into one coherent menu. The unused discover feature came out. Account and main menus were rebuilt. Type, colour, and spacing were aligned across hundreds of screens. Most of that work isn't visible in any single screenshot. It's visible in the consistency between them.
PASS 04
One language, two platforms
Mobile and the extension do different jobs. Mobile is for daily use; the extension is for transactions tied to a desktop session, like signing into a dApp. Forcing them to look identical would have made both worse. They share visual language, components, and primitives, and the layouts diverge where context demands it. Same wallet, two surfaces, coherent without being identical.
04 DECISIONS
Two calls worth walking through
Most decisions on this project were straightforward. These two weren't, and they shaped much of what came after.
CALL 01
Build the system in parallel with the product, not before it
The safe move was to lock the design system first, then redesign the wallets against it. The faster, riskier move was to build both at once, with the wallets as the live testbed for the system. It was a small team, features had to keep shipping, and the system had to stay grounded in real product needs.
WHAT WE CHOSE
Both at once. The wallets became the proof of concept for the system, and the system gave the wallets a foundation as it took shape. Tokens, components, and conventions were stress-tested against real product work as they were built.
TRADE-OFF
Some early work had to be redone once the system caught up. That was expected. Pausing feature work for months to build a system in isolation would have cost more, both in shipped features and in a system too abstract to serve the product.
CALL 02
Set up real branching and versioning for design files
Most design teams don't have this. They keep one master file, accept the conflicts, and reach for Notion when things get confusing. The alternative was Figma branching with a documented workflow on top, which meant a paid plan upgrade and real time spent on infrastructure instead of product.
WHAT WE CHOSE
We pitched it, documented the workflow end to end, got it greenlit, and set it up. Scoped to cover the wallets, the design system, and the separately documented ID app, with room for future products to slot in.
TRADE-OFF
The upfront cost was real: the plan upgrade, the documentation, training the team. The payoff is mostly invisible, a system that catches breaking changes before they ship and a workflow that survives the next designer joining. It was worth it because the work was built to outlast any one person on it.
05 OUTCOME
What shipped
Both wallets now run on one design system, with consistent navigation, type, colour, and component vocabulary across mobile and the extension. The Figma files are organised, documented, and version-controlled, with a branching workflow that survives designers joining or leaving. The system stretched to cover the ID app and was ready for whatever came next.
One lesson carried forward: make the case for the unglamorous parts early. Tooling and process are load-bearing, and the sooner everyone agrees on them, the less the visible work slows down.
- 2
- wallets, one languageMobile and browser extension, sharing a system, type, and components.
- 3
- products on one systemWallets, design system, and ID app, all built on the same foundation.
- 1
- design system, built to lastTokens, components, versioning workflow, and conventions. Written down, not just remembered.
- 1y
- from chaos to shippingFrom mapping the existing files to a redesigned wallet running on a stable foundation.
