Skip to content
DeFi / Crypto

KeyFi

Clarity for DeFi. Control for you.

Overview

Product design for a multi-chain DeFi app

KeyFi was a multi-chain DeFi platform where everyday users manage crypto across wallets and protocols — track a portfolio, swap, farm, stake, lend and borrow, and use research tools to make decisions. It ran a free tier and a paid PRO tier.

Role
Product Designer
Skills
Product Design · Design Systems · UX/UI · Systems Thinking
Tools
  • Figma

The problem

A working dashboard already existed, and a designer had worked on it, but the team was not happy with where it had got to. So this was not a tidy-up, it was a full redesign. The UI had to be redrawn too, but that is not where the weight sat.

The product could not yet answer the one question it existed for. People hold wallets on several networks at once, and never see what they are worth in total, or how that total is split. I went back to the start: how the competition solved it, and what the user interviews the team already had were saying.

Two halves. On the left, a spreadsheet of APY formulas and a stack of browser tabs across different DeFi sites. On the right, one dashboard: total value on top, a wallet and network switch, the split across Ethereum, Polygon, BSC and Avalanche, and the same account on a phone.
Before, a spreadsheet and a dozen open tabs. After, one place, with the total on top.

The core decisions

Aggregated value became the hero of the dashboard, the single figure people came back for.

Filtering had to work in both directions. A wallet holds tokens on several networks, and a network holds several wallets, so you can start from either one and still get a straight answer. And not as a list alone: a chart beside it shows the weighting inside one wallet and across the whole portfolio.

A new brand and logo came with it, in dark and light. Underneath sat the design system in Figma, from primitive tokens through components to patterns, so Swap, Farm, Yield, Borrow, Research and Alerts stayed consistent without re-deciding the basics each time.

Dark arrived with PRO and became the default, because it reads as the more premium of the two. You could still switch.

Design system sheet: text inputs in normal, focus, filled and error states, primary and secondary buttons across four states, three button sizes, a button group, a network tooltip and an open market-cap dropdown.
The design system in Figma, from primitive tokens through to components and patterns.
Strategy builder called Leverage Long. Setup Position lists four numbered actions, swap then two deposits then rewards, connected by arrows. Manage Position lists two borrow actions beside it.
Multi-step positions built as numbered actions, so a strategy could be read before it was run.
Swap screen with a SOL to USDT price chart, a dashed line marking the limit order, a table of open orders below it, and a panel on the right for placing a new limit order through Uniswap.
The chart carries the limit line, the table carries what is still open.

Iteration

A small team: the founder, one developer, one person on marketing and sales, and me. The developer got Figma, a clickable prototype and the states, so he could see what followed what instead of having it described. When I drew something one-off, we decided together whether it was worth the time it would take to build.

Every release went out with a clear note on what had changed, and the feedback came straight back through Discord and Telegram.

Outcome

It shipped as KEYFI Pro, to a strongly positive response. A group of regulars used it daily, and they were told directly whenever something went live so they could test it. The design system became the foundation the later features were built on.

A phone showing borrowed status with a health factor slider, a watch showing the BNB price, and a second phone showing saved watchlists with follower counts.
The same numbers away from the desk: borrow status, watchlists, and a price on the wrist.

What I would add

The team heard plenty from users, through interviews and a loud Discord. But what people say and what they do are two different records, and we only had the first one. Analytics would have shown which sections were actually used, and the navigation could have been grouped by that instead of by the order things were added to it.

Today I would go further and highlight the items a particular person actually uses, per user, instead of showing everyone the same flat list.

Next case study

  • Bringing GitHub PR-style review into the GraphQL federation workflow.