Building Ledger Wallet: Blending UX, Architecture & Delivery

Tech

Side Channel – Where Ledger engineers talk about how they design, build, and scale our systems.

Ledger has become the gold standard in crypto security. With hardware devices trusted by millions, the foundation is solid. But trust in security doesn’t automatically translate into a great daily experience.

By the time we started scoping Ledger Wallet last update, a gap had opened up between what the product could do and how much users actually engaged with it. The feature depth was there. The engagement wasn’t.

The Problem

The Ledger Wallet™ app has evolved considerably since its early days, from a focused device management tool into a full financial interface covering portfolio tracking, staking, swapping, buying, selling, market insights, and more, across both mobile and desktop.

That growth brought real value. It also brought real complexity.

Users, especially newer ones, found it hard to know what to do next. Navigation had become cluttered. Key actions required too many steps to reach. For users still building confidence with self-custody, every moment of friction was a reason to disengage.

But some of that friction wasn’t just a design problem. It was rooted in years of accumulated technical decisions: performance that fell short in real conditions, mobile and desktop experiences that had drifted apart over time, and an architecture that made every improvement more expensive than it should have been.

These weren’t separate problems. They were the same problem, visible at two different layers.

The Ambition

The vision behind this huge update is to turn Ledger Wallet into the most trusted, easy-to-use, and insightful wallet, a place where users don’t just secure their assets, but actively manage and grow their portfolio.

The first milestone focused on reducing the distance between opening the app and taking a meaningful action: a redesigned navigation, a cleaner portfolio view centered on what users own rather than historical charts, and better guidance for users at different stages of their journey.

The next step goes further, giving users the tools to actually grow their portfolio: deeper analytics, richer market insights, and a more complete experience. That work is ongoing, and some of the hardest problems are still in front of us.

One constraint shaped everything: both mobile and desktop had to move together. Ledger users switch between platforms. A redesign that shipped first, or produced divergent experiences, would have undermined the whole effort. That immediately pushed us to think in terms of reuse, consistency, and long-term maintainability, and forced a central architectural question: what should be shared across platforms, what should remain specific, and where exactly is that line?

Why A UI Refresh Wasn’t Enough

The answer could have been: redesign the screens, introduce the new Lumen design system, ship it.

We chose a different framing early on. A better-looking wallet that still felt slow to launch, or that still behaved inconsistently across platforms, wouldn’t actually be better. Users feel the difference even when they can’t name it. And in a product where people are managing assets they care deeply about, that feeling matters.

So Ledger Wallet is built around a dual mandate: deliver a meaningfully better experience for users, and build the foundations that make that experience sustainable. This means that this Ledger Wallet update had to be approached not only as a product redesign, but as a broader technical transformation.

Designing For Product Ambition & Technical Reality

One of the defining aspects of the project was that every major product decision had technical implications, and every technical decision had product consequences. This was not a context where UX could be designed in isolation and “implemented afterwards.”

Many of the questions we had to solve were multidimensional:

How do we enable richer and more coherent flows without multiplying implementation complexity?
How do we introduce a new design language in a way that is sustainable for teams?
How do we improve the perceived and actual performance of the application while modernizing the experience?
How do we make architectural decisions that support delivery rather than slow it down?

In other words, we were not simply choosing how to build Ledger Wallet:
We were choosing what kind of system would allow Ledger Wallet to exist and evolve well.

That required thinking beyond individual features and treating the wallet as a platform experience.

One Transformation, Two Applications

A major challenge of Ledger Wallet is that it was never a single-app project. We needed to impact both our Mobile and Desktop applications, built on different runtime environments, with different constraints, but expected by users to feel like parts of the same product. That raised the bar considerably.

A redesign of this scale only truly succeeds if it creates a coherent experience across touchpoints. Releasing one platform ahead of the other, or evolving them through completely separate strategies, would have weakened that ambition.

So one of our targets was clear:
Transform and release both applications simultaneously, with a shared product direction and a shared technical strategy wherever it made sense.

This immediately pushed us to think in terms of reuse, consistency, delivery coordination, and long-term maintainability across platforms. And it forced us to confront one of the central architectural questions of the project:
What should be shared, what should remain platform-specific, and how do you draw that line without creating accidental complexity?

That question ended up shaping much of the journey.

Performance Is Part Of The Experience

One principle quickly became non-negotiable in Ledger Wallet: performance could not be treated as a later optimization phase. A redesigned product that still feels slow, heavy, or brittle is still a degraded experience.

In our case, some of the UX friction we wanted to solve was directly tied to accumulated technical debt. That meant improving the experience was not only about redesigning flows or rebuilding screens, it was also about reducing the technical weight behind them.

So performance had to be part of the redesign itself.

That pushed us to rethink:

What happens at startup?
How much work does the app do before becoming usable?
and which architectural choices would make the product feel faster and more reliable over time?

This was especially true for startup time. For a wallet, being slow to start is not a detail. It is one of the first things users feel, and one of the fastest ways to degrade trust.

That is why we spent a significant part of the last year optimizing app launch across platforms, with strong results:

iOS: ~4.0s → ~1.2s (-70%)
Android: ~7.3s → ~3.6s (-50%)
Desktop: ~10.5s → ~3.5s (-66%)

These gains were not a side effect of the redesign. They were part of it.

A Cross-functional Transformation

Projects like this Ledger Wallet update are often viewed solely through the lens of technology choices. However, real transformation at this scale depends just as much on how the work is framed and executed as on the architecture itself. Ledger Wallet was shaped through a close partnership between Design, Product, Engineering, and Delivery, not as separate functions, but as a system that needed to move with shared intent.

Maxime Nguyen-Them and Julien Cochard from the Product and Design teams worked as a single unit to define the target experience behind Ledger Wallet. Together, they rethought flows, interaction patterns, and the foundations of a more cohesive product experience across platforms.

This collaboration went beyond designing interfaces or managing a backlog. It involved defining what success looks like for users, translating a broad vision into clear, prioritized steps, ensuring every trade-off served the right user outcome, and making sure we were not just modernizing the product technically but also improving the right parts of the user experience.

This close collaboration ensured that the vision remained rooted in user value and that decisions consistently addressed the most important problems.

From an engineering perspective, the Principal Engineer’s role, Raphaël Tahar, was to help define the technical vision: understand the system’s structural limitations, shape the cross-platform strategy, and align on a future state that could be understood and supported by engineering teams and top management alike.

But having a clear direction is only part of the equation. What made Ledger Wallet possible was also turning that direction into actionable steps. This is where the Engineering Manager Kevin Le Seigle, and Delivery Manager, David Pedrono, played a vital role: organizing the work, sequencing changes, managing dependencies, and creating operational conditions for multiple workstreams to progress efficiently without fragmenting the effort.

Operational efficiency was just as crucial as the architecture itself. Because large transformations rarely fail solely due to poor technical decisions, they often fail when the organization cannot sustain the transition from the current system to the future one. A big part of the work, then, was not only deciding where we wanted to go but also designing a credible, coherent, and scalable path to get there.

The Challenges That Shaped Ledger Wallet

This article is the first in a series where we’ll go deeper into the technical transformations behind this huge Ledger Wallet update.

Rather than telling the story only from a high level, we want to share the work through the actual engineering topics that shaped the initiative, from architecture and platform strategy to performance, tooling, and developer experience.

Each of the next articles will focus on one of the major challenges we had to tackle, and will be written by the engineers who worked directly on them.

Here is a preview of that journey:

Removing legacy platform constraints (CAL Removal), Gaëtan R. and Martin C.
Untangling foundational legacy systems (DADA), Frederic S. and Kevin C., with contributions from Come G.
Modernizing our React Native foundations, Yoann S. and Iqbal I.
Upgrading React Native in a high-velocity monorepo, Yoann S., Iqbal I., and Martin C.
Improving startup time and first-use responsiveness, Théo S., Lucas W., and Gaëtan R.
Designing a new cross-platform code architecture, Martin, Raphaël T., and Lucas, with contributions from Come G.
Moving from MVVM to DDD, Raphaël T.
Structuring the monorepo with Nx, Lewis P., Yoann S., and Raphaël T.
Revamping CI to support a broader transformation, ownership to be confirmed
Rethinking bundling and packaging with Re.Pack, Yoann S., Lucas W., Kevin L. S., and Raphaël T.
Rationalizing the state management stack, Raphaël T., Yoann S., and Gaëtan R.

One thing we wanted this series to reflect is that transformations like this update are never the result of a single decision or a single role. They are made possible by many focused engineering efforts, carried by the people who identify the pain points, design the solutions, and make the trade-offs real in code.

That is why the next articles will be written by the engineers who worked directly on these topics. Our goal is not only to share outcomes, but to share the actual journey: the constraints, the dead ends, the trade-offs, and the engineering decisions that shaped Ledger Wallet from the inside.

Looking Back

Ledger Wallet was a reminder of something easy to underestimate in software:
The most meaningful product improvements often happen when design, architecture, delivery, and execution are treated as one problem.

That is what made this journey both challenging and worth sharing.

In the next article, we’ll start with the first of those challenges:
Why redesigning user experience in a mature product is as much a technical problem as it is a product one.

Raphaël TAHAR – Principal Engineer
Maxime NGUYEN-THEM – Senior Staff Product Manager
Kevin LE SEIGLE – Engineering Manager
David PEDRONO – Delivery Manager