Understanding Who We Were Designing For

Before touching any screens, I worked with the team to align on who the product was actually for. The HyperLiquid ecosystem in mid 2025 had a specific kind of user: crypto-native, fast-moving, and already comfortable with DeFi tooling. But the referral-gated onboarding model meant the user base would expand beyond power users over time. We needed to design for the full range.

I defined three directional personas to anchor design decisions throughout the project.

Persona 1: The Active Trader

"I want execution speed. Don't make me click five times to place a trade."

Profile: 26–34 years old. Trades daily. Familiar with perpetuals, leverage, and position sizing. Already uses tools like Hyperliquid's native interface or a competing bot. Came in through the founding team's network.

Goals: Execute trades fast. Monitor open positions without friction. Manage multiple order types (spot, perp, margin) from one place.

Frustrations: Overcrowded interfaces. Slow confirmation flows. Having to leave the app to check prices.

Design implication: The advanced trading mode, single-line command execution (futures buy eth 0.1), and the persistent portfolio overview all came from this persona. Speed was non-negotiable. Every extra tap was a failure.

Persona 2: The DeFi Participant

"I want full control of my wallet and my keys. I don't trust platforms by default."

Profile: 28–40 years old. Technically literate. Understands self-custody, private keys, and the difference between hot and cold wallets. Evaluates platforms on security architecture before onboarding.

Goals: Understand exactly where funds are held. Have a recovery path if Telegram access is lost. Full transparency on fees.

Frustrations: Platforms that obscure wallet mechanics. Black-box fee structures. No way to export keys or access funds outside the app.

Design implication: The dual-wallet architecture (funding wallet vs. trading wallet) needed to be explained clearly, not buried. The private key export flow, the account recovery documentation in the help section, and the fee tier transparency all responded directly to this persona's concerns.

Persona 3: The Referred Newcomer

"Someone I trust sent me this. I'm curious but I don't know where to start."

Profile: 22–30 years old. Has a crypto wallet and some trading experience but has never used a bot-based terminal. Discovered the product through a friend or community recommendation, not organic search.

Goals: Understand what the product is and why it's worth using. Get from registration to first trade without needing support. Build trust in the platform early.

Frustrations: Jargon-heavy onboarding. No clear next step. Feeling lost in a product built for experts.

Design implication: The onboarding checklist flow (step-by-step, dynamically updated with completion states), the simplified Lite Mode trading interface, and the FAQ section were all shaped by this persona. The product needed to earn trust, not assume it.

Phase 1: Brand Identity

The founders had a clear visual direction: a triangle-based mark that referenced casino chips, projecting premium confidence over startup energy. The brand needed to feel like something a serious trader would trust, not a product built for hype alone.

I developed the logo and logotype, a color system, typography guide, and icon guide simultaneously, treating the brand as infrastructure rather than decoration. Every element was chosen for durability across very different contexts: a Telegram message card at 320px wide and a desktop web app at 1440px.

The dark background with high-contrast teal accent was a deliberate decision. In a market where most DeFi products lean toward purple-and-black or white-and-neon, the teal direction read as composed and distinctive without trying too hard. The typography was selected for clarity at small sizes in bot messages while carrying weight in display headings on the landing page.

The brand was approved before any product screens were touched. That sequencing was intentional: every downstream decision needed a single source of visual truth to reference.

Phase 2: Landing Page

The landing page served two distinct purposes at two points in time.

Version 1, Waitlist: A focused, conversion-only page. The job was to capture interest before the product existed. Minimal surface area, single call to action, brand-forward.

Version 2, Launch: A full product marketing page, designed with the content team. Sections covered: product features, how it works, target audience, gamification and rewards, social proof, and the dual-wallet security model. Both desktop and mobile versions were designed.

The launch page had to do something most landing pages don't: explain a genuinely complex security architecture (two wallets, fee tiers) to both the DeFi-literate and the newcomer without alienating either. The solution was layered information density: surface-level headlines for the newcomer, with expandable detail for users who wanted to go deeper.

Phase 3: Product Design

The product ran across three surfaces: Telegram bot, Telegram mini app, and web app. The Telegram bot was the core. The web app extended it with a richer interface for users who wanted more than a chat flow.

The Telegram constraint

Designing inside Telegram means accepting a hard ceiling on interaction patterns. You work with inline keyboards, message flows, and limited feedback mechanisms. Early on, there was a pull toward pushing the medium, building custom interactions that would feel more like a native app. The decision was to go the other direction: lean into what Telegram does well, keep flows short and predictable, and invest the complexity budget in the web app instead.

This was the right call. A bot that fights its medium confuses users. A bot that works cleanly with it builds trust.

Onboarding

The onboarding flow needed to create two wallets, explain the purpose of each, guide the user to fund their account, and do all of this without losing the newcomer persona along the way.

The solution was a progressive checklist: each step was shown as pending or complete based on the user's actual account state, dynamically updated. New users always knew where they were and what came next. The framing of the two wallets (funding for deposits and withdrawals, trading for active market exposure) was written to reassure rather than alarm. The security benefit was the headline, not the complexity.

Dual-wallet UX

The security model was one of the harder problems on the project. The product uses separate funding and trading wallets so that a compromised trading environment doesn't expose a user's full holdings. Explaining this in a way that felt protective rather than bureaucratic took several iterations.

The final approach: introduce both wallets by name at registration with a plain-language explanation of their roles, reinforce the model in the account overview, surface the private key export in a visible but considered position (behind a clear warning), and cover recovery scenarios explicitly in the FAQ. The goal was that a user who read the onboarding carefully would never feel stranded.

Trading flows

The trading section covered:

• Spot market orders

• Spot limit orders

• Perpetual futures (default leverage)

• Margin orders with cross and isolated modes

• Cancel individual or all open orders

In Telegram, each of these ran as a guided menu flow. On the web app, the same functionality was split into two modes: Lite Mode (simplified interface, chart, fast order entry for active traders who wanted less noise) and Advanced Mode (multi-panel, full-featured, for users who wanted complete control).

Power users could bypass the menu entirely with single-line text commands. The parser was designed to validate all parameters, return helpful error messages for malformed input, and confirm execution clearly. Designing the error states for this was a detail that mattered: bad input needed to feel recoverable, not punishing.

Rewards and growth system

The fee structure used referral-based tier progression, reducing trading fees from 1.00% at Level 1 to 0.20% at Level 4. I also designed the UX for a point-based alternative system proposed during the project, which combined referral activity with trading volume into a unified leaderboard. This was documented and handed off for the team to evaluate against the v1 model.

The rewards section of the web app surfaced all of this in one place: total points, tier breakdown (trading points, referral points, social points), current fee level, and referral link.

Design system and team direction

Midway through the project, I brought in a junior designer. I scoped their work to missing component builds and design system documentation, keeping them on tasks with clear boundaries while I stayed focused on new feature flows. The UI Kit was in active development at handoff. The component library, color tokens, and typography system were built to support continued expansion after delivery.

Stakeholder Management

This project involved a founder, VC stakeholders, and a project manager, each with different priorities and different levels of design literacy. The VC stakeholders had strong opinions on brand direction (the triangle mark, the premium positioning). The founder was focused on shipping speed. The project manager was managing dev timelines.

My job was to move fast without accumulating decisions that would need to be undone. That meant being decisive in design reviews rather than presenting options, getting brand alignment locked early so it couldn't be reopened later, and being clear with the dev team about what was specced versus what was still in motion. The two-month timeline was only achievable because the process was tight.