Aditya Meshram Work / Pi42
All work

Crypto derivatives · 2023 — present

Nineteen product areas.
Three platforms. Four brands.

Crypto derivatives trading on web, iOS and Android — futures, options, wallets, KYC, banking, reports, referrals. Sole designer for two and a half years; now leading the design team.

19Product areas
200k+Installs, iOS & Android
$1B+Monthly volume
90–95%Withdrawals settled instantly
~50%Less dev time per feature
~0Extra build time per brand

The web terminal

The web terminal.

Chart, order book, order entry and open positions on one surface, at the density traders work in. Around fifty of the eighty-seven semantic colour tokens carry the difference between dark and light — drag across the screen to move between them.

Pi42 futures trading terminal in dark mode — chart, order book, order entry and open positions

Drag anywhere on the terminal

Product decisions

Decisions made outside the system.

Trading products fail people in specific, expensive ways — a step nobody understands, a risk nobody sees coming, a promise nobody believes. Five decisions from the product itself.

WalletsLive

Money that arrives where it's going.

Problem
Funding a trade took two acts. Deposit INR into the INR wallet, then transfer to the futures or options wallet before anything could be traded. The second act existed because of how wallets were structured, not because anyone needed it.
Signal
A designer on the team — not a trader — couldn't work out why money had to move twice after it had already arrived. If the model isn't obvious to someone building it, a first-time user has no chance.
Decision
Route incoming funds at the point of deposit. The destination wallet is chosen during UPI confirmation and can be set as default, so repeat deposits skip the choice too.
Result
The transfer step no longer exists. The bottom-sheet explainer that taught it was deleted — wallet guidance now appears only when someone actually hits a funds shortage.
12 → 8Steps to fund a trade
WithdrawalsLive

A guarantee the interface has to carry.

Problem
Withdrawals were request-based — submitted, then waited on, with no reliable sense of when money would land. On a platform holding someone's money, ambiguity is the product.
Decision
Automated queuing, with the flow redesigned around it. The high-stakes moment is treated as one: the interface states the guarantee plainly, and shows where a withdrawal is rather than leaving it silent.
Scope
Shaped at system level alongside engineering, not only in the UI — the queue behaviour and the interface were designed against each other.
Result
Every withdrawal completes. Most settle immediately; the remainder are queued visibly rather than silently.
90–95%Settled instantly
Futures · risk educationLive

Explaining a trade-off that costs money.

Problem
Setting take profit or stop loss via Market or Limit is a real trade-off, not a preference. Market guarantees the price but the order can be skipped if price jumps past the target. Limit guarantees execution once triggered, but can slip in a volatile move. Copy can state that. It can't show the moment the difference bites.
Decision
Both cases animate side by side on the same price ladder. Price moves once, and you watch one order get skipped while the other fills at a worse price. The trade-off is visible in about four seconds, before anyone has money on it.
Market
Limit
Margin · risk educationLive

Showing risk as it changes.

Problem
Auto top-up is conditional. It fires only when margin ratio approaches the threshold, and it can be on or off. A toggle shows the setting; it can't show what the setting does.
Decision
A liquidation-risk meter that animates between protected and unprotected states, inline beside the control. Shipped on web, iOS and Android, and now the pattern for several other conditional features.
Liquidation risk · auto top-up bottom sheet
Onboarding & KYCIn progress

Fewer steps, less time.

Problem
Verification averaged five to ten minutes — long enough that people abandoned it partway and came back later, or didn't.
Decision
The same step-cutting applied to wallets, applied to signup: steps merged, and anything that could be inferred or deferred taken out of the critical path.
Status
Shipping now. Target is under two minutes on median completion.
<2 minTarget, from 5–10 min

The token pipeline

How the system is built.

Every colour, space and radius decision is made once in Figma and resolved everywhere else by the token pipeline. Three layers, each with a single job.

LAYER 01

Primitives

Raw values with no opinion about use. Neutral ramps, per-partner brand ramps, transparency steps, spacing and radius scales.

173 variables · single mode

LAYER 02

Semantic colours

Named by job, not appearance — fill-brand-default, text-primary, border-buy. This is the layer that changes per partner and per mode.

87 tokens × 8 modes

LAYER 03

Space & radius density

The same components on a 360 px phone and a 2560 px terminal need different breathing room. Density is a third axis, independent of brand and mode.

35 tokens · mobile / web

One value, three codebases

Follow a colour through the system.

A brand ramp sits in Figma. One step of it is bound to the semantic tokens, and those tokens drive every component property that should carry brand. Switch brands below — the ramp, the tokens and the components all follow.

Primitive

Pi42 primary

    Semantic token
    text/Brand fill-brand/default border-brand/default
    Component
    Isolated .tag__label { color }
    .btn--primary { background }
    .btn--secondary { border-color }
    Button.css 
    
    
    

    
    One ramp step feeds three semantic tokens, and those tokens feed every component that carries brand. Adding a brand is fifteen token values, and shipping the same feature to a partner platform costs close to nothing extra.
    

    
    
      
    
        
    16 components, 18 stories, browsable.
    
        
    The working library, deployed from the same repo.
    
      
    
      
        Open Storybook