Intro: Perps trading case study

I designed Perps trading in Zerion from early research to shipped MVP in under 3 weeks.

The project expanded Zerion from portfolio management and swaps into a more complete trading experience for active crypto users.

The challenge was to bring a complex trading product into a self-custody wallet without making it feel like a separate app or overwhelming the existing user experience.

My role was to lead the design work across research, competitor analysis, MVP definition, UX flow, UI, edge cases, and engineering alignment.

The feature shipped, started generating referral revenue, and created a foundation for follow-up iterations like PnL, a dedicated Perps tab, and limit orders.


Problem

Zerion already helped users track portfolios, manage assets, and trade on-chain. But for active users, one major trading layer was still missing: Perps.

We had signals from user requests, internal interest, and market momentum that Perps were becoming an important part of modern crypto trading.

The challenge was to validate the opportunity quickly and define an MVP that made Perps feel clear, fast, and native to Zerion.

Role & team

Role: Lead Designer.

Scope: Research, competitor analysis, MVP definition, UX flow, UI, testing, design system, specs, and edge-case review.

Team: Product, engineering, design.

I led the design work from early research to shipped MVP. My role was to define the product structure, validate the core flow, design the interface, and align the experience with Zerion's existing product system.

I worked closely with product and engineering, especially on MVP scope, API constraints, implementation details, and edge cases.


Approach

Perps competitor research overview
MVP flow exploration helped define expected Perps patterns, critical trading information, and the core user journey.

I started with competitor research across Perps and trading products, with a strong focus on Hyperliquid.

The goal was to understand the expected patterns in this category: what information traders needed, which interactions felt familiar, and where Zerion could make the experience clearer.

Then I created a clickable prototype and launched an unmoderated Maze test with 89 participants in 2 days.

The test focused on three questions:

  1. How familiar are users with Perps?
  2. Did the MVP flow match their expectations?
  3. What usability issues should we fix before implementation?

The key finding was that most participants already understood Perps. 71 participants had traded Perps in other products.

This changed the MVP priority. Instead of teaching Perps from zero, we focused on a clear, fast, and familiar flow for users who already understood the category.
Maze test prototype and results
The test showed that education was not the main problem. Most users already understood Perps, so the MVP shifted toward speed, familiar patterns, and decision-critical information.

Challenges and trade-offs

The main challenge was speed. We needed to validate the direction, define the MVP, design the core flow, and align with engineering in under 3 weeks.

The biggest product trade-off was between a complete trading experience and a focused MVP. The ideal version included more advanced order types, deeper analytics, and more customization, but shipping all of that would delay validation. We focused on the core trading flow first and moved limit orders and deeper analytics into follow-up iterations.

The second trade-off was around education. Perps are risky and complex, but research showed that most users already understood the category. Too much explanation would slow down the experience and increase the scope, so we kept only decision-critical guidance around risk, leverage, and liquidation.

The third trade-off was implementation. Instead of designing the ideal flow in isolation, I worked with engineering in parallel and checked Hyperliquid API constraints early. This helped shape the design around what could be built cleanly, not only around the ideal UX.


Solution

The final solution made Perps feel like a native part of Zerion, not a separate trading app inside the wallet.

The core decision was to use a dedicated Perps account. Users could deposit funds, see available balance, open positions, and track performance in one place. At the same time, the account stayed connected to the broader portfolio experience.

The interface focused on the decisions traders needed to make quickly: market selection, position size, leverage, liquidation risk, trade details, and PnL.

The flow reused familiar Perps patterns, but adapted them to Zerion's product system, visual language, and self-custody wallet context.

Zerion Perps interface — markets, position, trade details
Final Perps screen flow designed as a native Zerion trading surface, covering onboarding, deposits, market selection, position opening, PnL, history, and edge cases.

Results & impact

The design was delivered in under 3 weeks and shipped as a working product.

After launch, Perps started generating referral revenue and gave the team real usage data for further iterations.

  • PnL for positions
  • A dedicated Perps navigation tab
  • Limit orders, designed for implementation

For Zerion, Perps became an important step in expanding the product from portfolio management and swaps into a more complete trading experience for active users.

Interactive demo of the shipped Perps experience, showing the core flow from deposit to opening and tracking a position.
Zerion Perps — markets, position and chart
Core Perps screens showing onboarding, account balance, open positions, and the asset page for monitoring an active position.
Zerion Perps — leverage, limit orders and order management
Advanced Perps controls designed for experienced traders: leverage adjustment, take-profit and stop-loss settings, limit price entry, and open order management.

Post-launch learnings

After the MVP shipped, the main question was whether Perps should stay as a small trading extension or become a dedicated product area inside Zerion.

Usage and product feedback showed that active traders needed faster access to positions, markets, and PnL. Based on that, we decided to give Perps a dedicated navigation tab instead of keeping it only inside the existing trading flow.

This changed the role of Perps in the product. It was no longer just an entry point for opening a position, but a separate trading surface for monitoring markets, returning to open positions, and managing active trades.

The next iterations focused on making this surface more useful for experienced traders: better PnL visibility, position-focused navigation, and limit orders designed for implementation.