Case study · Web3

Trady — Interface

Redesigning discovery and trading for memecoin traders.

V1 translated the founder's broad product vision into a trading interface without a clearly prioritised audience. I led the redesign of Discover and Trade — the product's two most-used surfaces — for memecoin traders specifically, while directing the wider design team on the rest of the product.

My roleDesign Lead
TeamThree designers
TimelineSept 2025 – Apr 2026
PlatformsDesktop and mobile
Trady's live Trade page for the AGI token, showing the price chart, Buy/Sell panel, and live trades list
Trade: the live product — chart, execution panel, and trade activity in one workspace.
Problem and users

Trady is a non-custodial, cross-chain memecoin trading terminal — discovery, risk signals, execution, and portfolio management in one interface. V1 translated the founder's broad product vision into a trading interface without a clearly prioritised audience.

Finding

V1 served every type of crypto user without a clear priority. User feedback reached the design team through the founder, who relayed comments and supplied competitor research — not through direct user research.

Response

For V2, the founder narrowed the focus to degen and memecoin traders — a specific audience to prioritise discovery, token-level evaluation, and execution around.

Discover trending tokens Evaluate liquidity & risk Execute without losing context Manage cross-chain balance

What active memecoin traders need from Trady, in fast-moving, data-heavy markets.

The connected workflow V2 preserves — no step should require losing context on the last.

Three key decisions

The redesign centred on three connected decisions: making discovery actionable, bringing chart analysis and execution closer together, and clarifying cross-chain activity.

What I designed personally

Starting from the founder's low-fidelity layouts, I built the detailed UX/UI for Discover, the token detail page, and the trading module — the three decisions below.

What the team owned, I reviewed

The rest of the design team built the other product flows. I reviewed every screen for design quality and requirement coverage, and oversaw the design-system components, with a joint review alongside the CEO before handoff to engineering.

01 — Discover: making token evaluation more explicit

Problem

Markets showed a broad asset list with one aggregated Audit score and a Buy action per row. Buying was already easy — the surrounding discovery and evaluation paths weren't.

Decision

Discover splits the market into Trending, Smart Money, KOL Alpha, and Custom Radar, with Biggest Movers surfacing momentum. Individual risk indicators sit beside cap, liquidity, and volume — instead of one compressed score.

What changed

More specific discovery modes, visible token-risk indicators, and Quick Buy/Sell — the information around a trading decision is explicit, not hidden behind one score.

V1 Markets page: a broad, sortable asset list with core metrics and a single aggregated audit score
V1 — Markets: a broad, sortable market list with core metrics and a single aggregated audit score.
V2 Discover page: Biggest Movers panel, Trending/Smart Money/KOL Alpha/Custom Radar modes, and a token list with individual risk indicators
V2 — Discover: a signal-driven workspace combining real-time discovery, market context, token-risk indicators, and quick execution.

02 — Trade: giving chart analysis and execution clearer priority

Problem

The chart competed for space with a separate activity column, the order form, a long token-summary row, and multiple overlays.

Decision

A more selective token summary and clearer grouping around order entry, risk information, and activity — analysis, execution, and context no longer compete for the same space. On mobile, Security Audit moves into a bottom sheet instead of sitting on the chart permanently.

What changed

A wider chart, a leaner summary, and a hierarchy that gives analysis room to breathe.

V1 Trade page: a dense workspace with the chart, a Dev/Tracked/You activity column, and the order form competing for space
V1 — Trade: a dense workspace with multiple tools, data layers, and settings competing for attention.
V2 Trade page: a wider chart, a selective token summary, and a clearer buy/sell panel
V2 — Trade: a clearer hierarchy connecting chart context, execution, market activity, and token-risk signals.

03 — Clarifying cross-chain activity

Problem

Traders had to leave Trady for an external bridge just to check which chain held their funds.

Decision

Total buying power and its chain-level breakdown live together, with cross-chain movement inside the product — an overall balance alone doesn't say what's tradeable on a given chain.

What changed

Balance checking and funding stay inside the trading workflow — no detour to a separate bridge interface.

V2 cross-chain balance selector: Stable Mode showing a unified USDC balance across all chains, and Native Mode showing per-chain native balances for Solana, BNB, and ETH
V2 — Cross-chain balance: total buying power broken down by chain, with Stable and Native modes. V1 had no equivalent — checking chain balances meant leaving Trady for an external bridge.
What shipped

V2 translated a narrower product focus into a more specialised discovery and trading interface, implemented across both desktop and mobile:

4 intent-based discovery modes Quick Buy & Sell Selective token summary Wider chart layout Cross-chain balance view In-product bridging Mobile trade workspace

Comparable post-launch analytics weren't available, so I'm not claiming a measured improvement from these shipped changes — see the synthetic evaluation below for how I approached validation instead.

Usability validation — synthetic evaluation AI-simulated, not real users

To prepare for real-user testing, I ran an AI-assisted synthetic evaluation of V1 and V2 using six simulated trader profiles — the same task each time (find a token, check liquidity and top-holder concentration, prepare a 100 USDC buy without submitting), reviewed against screenshots and Figma designs. No real participants were involved.

2/6 → 3/6unaided task success, simulated profiles
3.17 → 4.00average task-ease score, out of 7
2.00 → 1.33average meaningful errors per profile

Constructed scenarios, not measured user behaviour — the point was to make assumptions explicit and find what to test next.

The exercise produced three hypotheses for real testing: individual token indicators may support evaluation, clearer grouping may help order preparation, and compact execution presets may need extra checking for experienced traders. Next: clarify holder-risk definitions and the preparing/submitting boundary, then test both versions with real traders.

← Back to all projects