Crypto wallet

Crypto Wallet: new features, a new design system and design debt

This project is under NDA. I don't disclose the product name, the screens are redrawn, without branding, but with the functional decisions kept. I can show the full designs and flows on a call.

Context

A Web3 wallet that has been on the market for over 4 years, with more than 15 million downloads and users in 190+ countries. The core audience is beginner crypto traders, but the team wants to gradually bring in experienced ones too. That sets the frame for every decision: don't overwhelm newcomers, give professional tools to those who want them, and don't scare off existing users with abrupt changes.

I worked on three tracks: building out the core trading scenarios and adding a viral loop, rebuilding the design system with AI tools, and paying down accumulated UX debt.

Track 01

Core trading features and virality

Goal. The hypothesis: if trading feels safe, beginners will trade more often and with more confidence. We watch the share of positions with TP/SL and the number of active traders.

Take Profit / Stop Loss and limit orders

The wallet already had perpetuals trading, and people used it a lot. But there was no way to close a trade automatically: to lock in profit or cap a loss, you had to keep watching the market and close the position by hand.

The task: add TP/SL and limit orders with a market / limit switch. Fit them into the existing interface so beginners wouldn't get lost, and gradually update the perpetuals page along the way.

Research and decisions

I looked at how TP/SL and limit orders work at the key players: Hyperliquid, Phantom, Trust Wallet, MetaMask. I looked at both the visuals and the functional decisions.

A user should understand in a second what they're opening, for how much, and what happens if the price moves.

  • TP/SL is part of the order form. It's set right when the position is opened, and it can be turned off.
  • The market / limit switch is at the top of the form. The limit price field only shows up when it's needed.
  • Defaults are safe, and errors are visible before confirmation. Warnings are orange rather than red: the point is to give a hint, not to scare people.
  • I prepared mockups for all the extra states and corner cases. Risk states and edge cases were finished together with the developers during implementation.
Order form: market / limit, TP/SL in percent

The basic wireframes came from the product manager, and I reworked the logic:

  • Percent instead of dollars. The Gain field was set in $ by default. Almost every competitor uses percent, and many dropped dollars entirely. It's easier for a beginner and for the whole dev team to think and calculate in terms of "close at −10%". We switched to percent.
  • Simple stop editing. The product team hadn't covered this flow, and competitors make it confusing: you cancel limit orders to change a stop. I suggested one input for profit and one for loss: you enter the new value, and the old one is shown underneath so you don't forget it. The team approved it.
  • Corner cases missing from the spec: closing all positions at once, adjusting margin on an open position, the screen state after placing a bet. I designed them on my own.

After that I oversaw the build and ran design reviews. 30+ desktop screens in total.

Editing TP/SL: current and new value

On mobile I carried over the same principle, but there I had to rework the whole perpetuals page. I used progressive disclosure: a beginner sees a simple form, and an experienced trader can open every parameter when needed.

Mobile: chart and order form

Result sharing

Goal: reach and new users. We watch shares per 100 trades, clicks and installs from the links.

Traders love to share results: a good trade or a winning bet is a reason to post on X. Competitors have ready-made cards for this, we didn't, so people either took screenshots or didn't share at all. For the product, that's a missed acquisition channel.

There were no prototypes or requirements, and the product manager was barely involved, so the structure, scenarios and visuals were up to me.

Research. I went where people actually share — X. I collected both card references and behaviour: what people are proud of (profit percentage, leverage, "called the market"), what they don't want to reveal (absolute amounts and deposit size), what makes a card feel alive (a chart, animation, GIFs instead of a static number), and when people want to share (not only on close, but while the position is still open).

For perpetuals I designed profit and loss cards in 4 different designs, so users can pick one to match their mood. For prediction markets one card wasn't enough: people share different things at each of three stages, so there are three states.

  • No bet yet. The user shares the market itself: the event and the current odds. Basically, it's an invitation.
  • Bet placed, market open. We show the position and the outcome they bet on: "I think this is how it'll go".
  • Bet won. The result, profit percentage and, if they want, the amount.
Sharing card for prediction markets

Key decisions

PrivacyA "show amount / percent only" toggle right at the moment of sharing. For many people amounts are sensitive, and not everyone wants to share them.
Live chartI asked the developer whether we could draw the real trade chart on the card instead of a decorative curve. Turned out we could, and the card became much more interesting than static alternatives.
Entry pointsThe share button sits where people see their result: in trade history and in open bets. It's easy to notice and find.
Track 02

Design system and AI-accelerated process

Goal. Right now the system covers a small part of the interface. The aim is 80–90% of screens, so the app looks consistent and new screens are built from ready components.

Where we started

On paper, the product had a design system. In practice it was three incompatible layers, and every new screen added another one.

Two versions of one systemSomeone had already started an update: some components lived in old, some in new, and both were used at the same time.
Mockups outside the systemThe latest screens were built with no link to the design system at all: their own colours, spacing and corner radii.
One typeface, dozens of sizesOne font, but sizes and line heights jumped around in both old and new screens.
Scattered iconsSeveral sets in different styles and weights, with no shared naming. Finding the right icon took longer than drawing a new one.

How I rebuilt it

Audit. I went through the whole app and every existing mockup and wrote down the values actually in use. That gave me a map of inconsistencies.

Tokens with AI. I moved all those values into a new file and turned them into tokens: colours, typography, spacing, radii. The mechanical part (parsing, grouping, naming) was done by an AI agent under my control: I set the structure and rules and checked the result. The icon pack was collected and renamed the same way.

Tokens in Figma Variables: 9 collections, 280+ variables

Atomic build. The system follows atoms → molecules → organisms. All new mockups use the new tokens, and components go into the system when the screen that uses them gets updated. That way the system grows with the product instead of becoming a separate project. The agent also generates component variants: the element already exists in a mockup, the agent turns it into a component with all its states and variants, and I review and fix it.

How much faster. By my estimate, about 3x. A component with all its variants takes 10–20 minutes by hand and 3–5 with the agent. Editing a component or adding an icon takes at least 5 minutes by hand and 1–2 with the agent.

Track 03

Product quality and UX debt

Alongside the features, I was paying down the design debt that made the app look inconsistent.

  • Visual defects. I ran a full audit of the desktop version and the mobile app and collected all the accumulated inconsistencies in one file. It came to about 40 UX/UI issues of varying importance. I sorted them by priority, and the developer and I started fixing them. First came small fixes that cost almost nothing in time but are immediately visible: the app became neater and easier to use. These fixes are also a way to move screens onto the new tokens.
  • Release materials. I updated the App Store and Google Play screenshots and the visuals for X, so what the team ships looks consistent in the storefront too. I also designed and built landing pages for the new product sections.

Status and outcome

  • TP/SL and limit orders: 30+ desktop screens are designed, built and have passed design review; mobile is waiting for the product manager's feedback.
  • Sharing: perpetuals cards in 4 designs and 3 states for prediction markets; entry points and privacy settings handed off to development.
  • Design system: tokens and icons are done, all new mockups use them, components are added as we go.

Other projects