Concordium Wallet — mobile and browser extension screens

Concordium Wallet

Two crypto wallets, one design system, and the workflow to keep them coherent. A year of work for Concordium across mobile and browser.

ROLE
Senior Product Designer
COMPANY
Concordium
TIMELINE
Mar 2025 – Mar 2026
PLATFORMS
Mobile + Extension

01 Context

A wallet that grew without a plan.

Concordium is a blockchain company. Their wallets, one for mobile and one as a browser extension, are how people hold tokens and interact with the network. They aren't the company's flagship product, more of a showcase for what the blockchain can do. Useful context, because it explains why there was room to redesign this thoroughly in the first place.

I joined as a senior product designer, working alongside the design lead. By the time I arrived, the wallets had been through enough hands that nothing quite matched anything else. Before I could redesign anything, I had to figure out what was actually there.

02 Problem

Years of decisions, none of them connected.

The wallet had been built. The problem wasn't quality. Most of the screens were fine on their own. The problem was that none of them knew about each other. To redesign anything cleanly, three things had to be true first.

  1. No system, just sediment.

    Years of decisions had piled up. Internal designers, an external agency, time. Patterns existed in multiple flavours. Type rules were inconsistent. Colour usage drifted from screen to screen. There was no shared system underneath any of it, just the accumulated residue of many people doing reasonable work without a common foundation.

  2. Nothing was where you’d expect it.

    Figma files were unorganised. Components were undocumented. Deprecated flows still sat next to active ones, with no way to tell them apart. Onboarding a new designer would have taken weeks just to understand what was where, let alone what depended on what.

  3. Every new feature negotiated with the chaos.

    Shipping anything new meant first deciphering what existed, then deciding whether to follow an existing pattern, pick between several, or invent a new one. Velocity suffered. So did consistency, because everyone made different calls under the same pressure.

03 Work

Four passes through the same product.

The work didn't happen linearly. Cleanup, system, and product overhaul all overlapped. Features kept shipping while the foundation was being poured. Easier to read as four passes than as a timeline.

Pass 01

Mapping what was there.

The first weeks weren't designing. They were untangling. Going through every file, every flow, every screen, and figuring out what tied to what. Archiving the deprecated. Naming the alive. Drawing a map of the product as it actually existed, not as anyone thought it did. Less glamorous than redesign, more important than redesign.

Files were a complete mess on my arrival

Pass 02

Building the system in the background.

While features kept shipping the old-fashioned way, the design system was being built underneath. Tokens, components, documentation, conventions. The wallets became the proof of concept for the whole thing, including the branching and versioning workflow for design files, which got set up at the same time. The design system case study covers this in more depth. It's its own story.

System tokens examples

Design ops - branching and versioning

Pass 03

Realigning the wallets to the system.

Once the system was real enough to lean on, the wallets got the overhaul they needed. Navigation was rethought, with tools that used to be scattered across the homepage moved into a single coherent menu. The discover feature, which nobody used, came out. Account and main menus were rebuilt. Type, colour, and spacing got aligned across hundreds of screens. Most of the work isn't visible in any single screenshot. It's visible in the consistency between them.

Consistent design language across all flows

Pass 04

One language, two platforms.

Mobile and the browser extension serve 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, but the layouts diverge where the context demands it. Same wallet. Two surfaces. Coherent without being identical.

Design consistency across all platforms

04 Decisions

Two calls worth showing my work on.

Most decisions on this project were straightforward. These two weren't, and they shaped a lot of what came after.

Call 01

Build the system in parallel with the product, not before it.

The safe move: lock the design system first, then redesign the wallets against it. The faster but riskier move: build both at the same time, with the wallets as the live testbed for the system. We were a small team, with features that had to keep shipping, and a system that had to stay grounded in real product needs.

What I 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, conventions, all stress-tested against actual product work as they got built.

Trade-off

Some early work had to be redone once the system caught up to it. We knew it would. But pausing feature work for months while a system got built in isolation would have cost more, both in shipped features and in a system that stayed too abstract to actually 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 required a paid plan upgrade and meaningful time spent on infrastructure instead of product.

What I chose

Pitched it, documented the workflow end to end, got greenlit, set it up. Scoped to cover the wallets, the design system, and the (separately cased) ID app, with room for any future product to slot in.

Trade-off

The upfront cost was real. Plan upgrade, 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 the company. Worth it only because the company kept investing in product design after I left.

05 Outcome

What shipped, and what I'd do differently.

Both wallets now run on the same design system, with consistent navigation, type, colour, and component vocabulary across mobile and the browser extension. The Figma files are organised, documented, and version-controlled, with a branching workflow that survives a designer joining or leaving. The system stretched to cover the ID app and is ready for whatever comes next.

If I were doing it again, I'd push earlier for sign-off on the boring parts. We got there in the end, but every time I had to make the case for tooling or process, the actual work slowed down. None of it was glamorous, all of it was load-bearing.

2
wallets, one languageMobile and browser extension, sharing a system, type, and components.
3
products on the systemWallets, design system, ID app. All built and maintained through the same pipeline.
1
design systemTokens, components, versioning workflow, and conventions. Written down, not just remembered.
12 mo
from chaos to shippingFrom mapping the existing files to a redesigned wallet running on a stable foundation.

More from this project

CCD Design System

CCD Design System

Design System

Comprehensive design system ensuring consistency across all Concordium products

View Case Study

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!