The notification came through on a Tuesday morning. I was sitting at my desk in Los Angeles, coffee still too hot to drink, window light coming in at that flat California angle, when our CEO sent a message in Slack with the Ledger announcement link. "This goes live December 8th. Five million users." I read it twice. For almost three years at VALK I had been designing for a very specific kind of person. Institutional. Experienced. Someone who reads a data table the way most people read a headline. Our typical Merlin user was a portfolio manager or DeFi analyst, someone who wanted every number visible at once and would consider a simplified view an insult. Building for that audience has its own challenges, but you at least know who you are building for. Five million Ledger hardware wallet users is a completely different population. Most of them bought a Ledger to keep their crypto safe. Many had never looked at a portfolio analytics tool in their life. And starting December 2022, Merlin was going to appear inside their Ledger Live app. This is the story of how that happened from a design perspective, and why it was the hardest thing I had worked on in my career up to that point. How Merlin and Ledger Live actually work together For context: Ledger Live is the companion app for Ledger hardware wallets. You plug in your device, manage your assets, see your balances. In late 2021 Ledger opened up a "Discover" section, a curated marketplace of third-party DeFi apps that live inside Ledger Live as embedded experiences. You don't leave the Ledger app. You open Merlin from within it, your wallet connects automatically, and you see your analytics. This sounds clean in theory. In practice it meant Merlin was running inside an iframe inside Ledger's app, with Ledger's navigation chrome wrapping everything, on a screen size we didn't control, for users who had never used our product before and hadn't specifically searched for it. They just saw it in a list and tapped. That last part is important. Our existing users came to Merlin with intention. Ledger users might arrive with nothing more than curiosity. The context of use was completely different, and the design had to account for that from the very first pixel. The scale problem isn't just numbers When people say "design for scale" they usually mean technical scale, can your infrastructure handle traffic. That's a real concern and I spent time talking to our engineers about load considerations. But for a designer, scale means something more specific: can the experience hold together when it's being used by people with wildly different goals, different levels of expertise, different devices, and different amounts of patience. Our existing Merlin interface was built around density. You could see your DeFi positions across protocols, P&L in USD, yield rates, impermanent loss, all on one screen, all updating in near real-time. For an analyst who lives in spreadsheets, this is ideal. For someone who just wants to understand if their crypto portfolio is up or down today, it's overwhelming. I had done some level of this translation before at Spacecode, where I built apps for both enterprise and consumer audiences in separate projects. But I had never had to take one product and make it work for both simultaneously. That constraint is what made this interesting and difficult. The answer wasn't to dumb things down. It was to restructure what was visible by default. Designing the simplified entry layer I spent the first two weeks after getting the integration brief doing something I almost never do in my normal workflow: making very rough paper sketches before touching Figma. Not because paper is magical, but because I needed to think through hierarchy without getting distracted by how things looked. The core question I kept coming back to: what does a new user need to understand in the first 30 seconds? For our institutional users the answer was "everything." For a Ledger user arriving via Discover, I decided the answer was simpler, how much your portfolio is worth, whether it went up or down, which protocols it's sitting in. Everything else, the detailed yield breakdowns, the historical curves, the per-position P&L, could live one tap deeper. This sounds obvious when I write it out. In practice it required rethinking component hierarchy in ways that touched almost every screen. Some data that was in the primary layer for institutional users moved to an expanded detail view. Some charts that were visible by default became accessible only after a user actively opened a position. The hardest part was doing this without breaking the experience for existing Merlin users. The product had to work for both audiences from the same codebase. So we weren't building a separate simplified app, we were building a layered version of the same app, where the default state was more accessible and the full complexity was still reachable. I built this out in Figma as two parallel flows with shared components, color-coded in a way that made it obvious which decisions affected both experiences and which were specific to one. This became the working document I kept open for the entire integration period. The mobile problem I had been avoiding Merlin was designed as a desktop-first product. This wasn't an accident, our institutional users worked on large monitors and needed the data density that screen real estate allows. I had done mobile explorations before but never treated it as primary. Ledger Live is mobile-first. A significant portion of the five million users access it primarily on their phones. I had roughly two months to redesign the core Merlin analytics experience to work on a 375-point-wide screen without losing the data accuracy that was the product's entire value proposition. Not a comfortable timeline. What I ended up doing was prioritizing ruthlessly. The desktop layout had a lot of simultaneous panels, protocol list, position details, portfolio chart, summary header all visible at once. On mobile this becomes a vertically stacked flow with a single dominant view at each step. The portfolio value and daily change sit at the top. Protocol cards scroll below. You tap into a protocol to see positions. You tap into a position to see the full breakdown. Each step reveals exactly one layer of additional information. No more. This sounds like basic mobile UX; and it is, but getting there from a desktop-first design system required rebuilding a lot of components from scratch rather than just resizing them. Resizing doesn't work. The components have to be rethought for how touch interaction works and for how much space a thumb can comfortably reach. I got it done, but if I'm being honest, some of the mobile screens launched in a state I wasn't fully satisfied with. The performance on older Android devices was inconsistent. Some of the interactions felt slightly off. When you have a hard integration deadline, you ship what you have and iterate after. I have a list of things to improve in Q1 next year. The design system negotiation This was the part of the project nobody tells you about when they pitch you a major integration partnership. Ledger has their own design system. Clear visual language, their own component library, their own rules about typography and interaction patterns. It makes sense, they've built a complex product that millions of people use daily and they have standards for how third-party apps inside Ledger Live should feel. Merlin also has a design system. We built it over about a year and it reflects the specific needs of financial data display: the way we handle number formatting, the color logic for gains and losses, the density of our data tables. When your product lives inside another product's chrome, there's an immediate question: whose system wins? The answer, in practice, is "both, uncomfortably." I had several calls with Ledger's design team during the integration process. They were professional and collaborative, this wasn't adversarial. But there were real moments of tension. They wanted certain interface elements to follow Ledger Live conventions because consistency across their Discover apps matters for their users. I wanted to maintain Merlin's visual identity because we were also going to announce this integration publicly, and having our product look like a Ledger white-label inside our own marketing felt wrong. We ended up with a compromise that I think worked reasonably well. Merlin kept its core color system and the way it displays financial data. The outer interaction patterns, how modals behave, how navigation cues work, followed Ledger Live conventions more closely. The navigation chrome was entirely Ledger's. The data presentation inside was entirely ours. Some of the visual tension this created is visible if you look carefully. I notice it. Most users probably don't. The work that doesn't show up in the product After the integration itself was done, or mostly done, there was another full cycle of work that I had to do as the sole designer: the announcement. An integration of this scale is a major marketing moment. We were telling the world that Merlin was now available to five million Ledger users. That story needed to be told visually across pitch decks, social media graphics, press materials, and the blog announcement. I have written before about how much of my time at VALK goes into this kind of communication design rather than product design. For this integration it was significant. I built the announcement assets in Figma alongside the product work, sometimes literally in the same working session, switching between the product file and the marketing file. The deck for the announcement had to simultaneously explain what Merlin is (for people discovering us through the Ledger news), what the integration means technically, and why it matters for DeFi portfolio management as a category. I had to make this visually interesting without having any new screenshots I could share before launch. So a lot of it was diagram-driven, showing the connection between Ledger's wallet layer and Merlin's analytics layer in ways that were accurate but not technically literal. This is its own design discipline and I've gotten reasonably good at it. But it's time that comes directly out of product design time, and for an integration with this much product complexity, the balance was stressful. What it means to design for five million people I've been thinking about this a lot since the announcement went live. When I started at VALK in late 2019 I was designing for a handful of clients, early institutional users who we knew by name. I knew their feedback directly. I could trace a design decision to a specific person's specific need. At Spacecode I built apps for larger audiences but the projects were sprints, you shipped, you handed off, you moved to the next thing. You didn't live with the consequences. Merlin in its pre-Ledger form had a few thousand active users at most. I had a general sense of who they were from user research sessions and from the feedback that came through to our team. I could hold the user in my head. Five million is a different thing entirely. I cannot imagine the full range of ways people will use this product, the devices they'll use it on, the contexts they'll use it in, the things they'll find confusing that I never anticipated. The statistical reality is that some percentage of people will hit edge cases I never designed for. Some flows will confuse people in ways that will seem obvious in retrospect. This is humbling in a specific way that I think every designer should experience at some point. It breaks the comfortable illusion that you can design something perfect if you just think hard enough. You can't. At scale, you can only design something good enough to recover from, clear enough that when something confuses a user, the surrounding context helps them find their way. I don't know yet how the integration is being received by actual Ledger users. The data will come in over the next weeks and months. I will find out which parts of the flow are working and which aren't. I am prepared to be surprised in both directions. What I know is that the design work I did here was the most demanding of my career so far. Two audiences, two platforms, two design systems, a compressed timeline, marketing work running parallel throughout. Each one manageable. All of them at once, not so much. The coffee is always cold by the time I get to it. If you're working on a similar integration, one product living inside another, the design system negotiation is the thing to start early. The visual compromises are manageable. The interaction pattern conflicts are harder. Get that conversation with the partner's design team on the calendar before anyone writes a line of code. If you're working on a similar integration, one product living inside another, the design system negotiation is the thing to start early. The visual compromises are manageable. The interaction pattern conflicts are harder. Get that conversation with the partner's design team on the calendar before anyone writes a line of code.

Figma

Four Years Inside One Figma File

Portfolio

What It Takes to Design for 5 Million Crypto Users

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Accessible Data Visualization in Fintech: Why It Matters

159 Stories To Learn About Android App Development

15 Stories To Learn About Androiddev

48 Stories To Learn About Android Development

5 Amazing Android Apps for Android Developers & Designers

5 Great Java Courses for Android Developers

Accessible Data Visualization in Fintech: Why It Matters

159 Stories To Learn About Android App Development

15 Stories To Learn About Androiddev

48 Stories To Learn About Android Development

5 Amazing Android Apps for Android Developers & Designers

5 Great Java Courses for Android Developers

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps