FinTech
Prop trading platform · UX audit
A US prop trading platform, where people learn to trade real markets on a simulated account without risking their own money, asked where its funnel and product lose people. In six weeks I audited the marketing site, the trader product and the internal admin, and handed back a prioritised queue, two tested hypotheses and four working prototypes. The audit then became a design hire.
- Client's country
- USA
- Platform
- Web · marketing site, product, admin
- My role
- UX Practice Lead · audit
- Duration
- 6 weeks · May–June 2026
Overview
Learning to trade is hard: there are many rules to internalise, luck plays its part, and nobody wants to pay for the lessons with real money. A prop trading platform is a simulator for exactly that. Traders pay a monthly subscription to trade real markets on a simulated account under rules, and when they pass, the firm funds them and pays out real profit. Most do not pass the first time and come back to try again.
The business
No primary business goal was defined when I started, so I anchored on the one metric that is always a win: how many visitors become paying traders, and where they drop before that.
The goal
Six sources of evidence, and a problem counted only when at least two of them pointed at the same place.
Method
An audit ends in a diagnosis and a queue, not in metrics. The result here is what the client did with the queue.
Context
01
Product
A place to learn trading without risking your own money: a simulated account on real markets, rules that teach discipline (a profit target, a drawdown limit, consistency), and real payouts once you pass. Three surfaces: the marketing site, the trader dashboard and the internal admin.
02
Users
Three traders, drawn from 11,000 reviews and a 72,000-member community: the Discount Hunter who buys on a promo code and churns fast; the Serious Student who reads everything and still goes to the community for rule answers; the Experienced Scalper who searches for one rule and leaves if it is not visible. The site was built for the first one only.
03
Market
Competitors win on the same two things: a plan comparison on the home page and payout proof in the hero.
Seven days of analytics: 123,240 first page views, 24% gone after the first page, 2 h 52 min on average between the home page and the plan page, 0% week-one retention, and no conversion event tracked at all.
Approach
Measure
Funnels, referrers and 50+ session recordings marked where to look before any opinion formed.
Listen
The community and the reviews: confusion in traders' own words, before purchase and after.
Inspect
Heuristics, accessibility and a phone walkthrough across all three surfaces, each finding ranked by how much it hurts.
Evidence from six directions. A finding made the queue only when the data, the community and the screens agreed.
Process
What the audit found
01
Choosing a plan
Problem
Four plans with different rules and ten plan-and-size combinations, no comparison on the home page and no recommendation anywhere. The most repeated question in the community: “Which plan should I choose? I read everything and still don't know.” The help centre answered it by sending people to the community.
Hypothesis
If first-time visitors get a guided three-question plan finder, more of them will buy, because the site fails at the one decision that precedes every purchase.
What I proposed
A plan finder: three questions, one recommended plan, the comparison table beside it. The entry sits under the plan table and inside the FAQ, where the question is actually asked. Tested as an A/B split, with completion rate and time to purchase as secondary metrics and bounce as the guard.
- Choices to weigh
- 10 → 1
- Steps to a plan
- read everything → 3 questions
- Time on the plan page, recorded
- 24+ min → ≈ 1 min
- Where the answer lives
- the community → the page
The 24 minutes is a recorded session on the plan page with almost no clicks, one of several. The minute after is an estimate for three single-tap questions. The finder was proposed as an A/B split: primary metric eval subscription conversion, secondary finder completion and time to purchase, guard metric bounce.
2 h 52 min
Average time between the home page and the plan page: visitors leave to compare elsewhere
24+ min
Sessions on the plan page with almost no clicks: reading, not deciding
10 → 1
Combinations to weigh → one recommended plan
02
Checkout
Problem
The plan card promised $126 with a code, the order summary charged $157 unless the buyer found the code and typed it. Card fields showed “cannot be blank” errors before anyone typed, next to a session timer counting down. The total said “/month” without saying whether a challenge is a one-off fee or a subscription.
Hypothesis
If the price shown is the price charged and the payment form stays calm, fewer buyers abandon at the last step and fewer dispute the charge afterwards.
What I proposed
Two steps: pick plan, size and platform with the best eligible code applied automatically, then review with the discount as a line and the billing model in plain words. Validation on blur, the timer gone unless a minute remains. Prototyped as working HTML.
- Price on the card vs. in the order
- $126 vs $157 → $126 = $126
- Errors before typing
- 3 → 0
- Codes to remember and type
- 1 → 0
- Billing model
- “/month” → one sentence
The price gap was the most serious finding of the audit, because it leads to a purchase at the wrong price or a dispute. The fix is logic, not layout: apply the best eligible code when a size is selected and never show a price the summary will not honour.
$126 ≠ $157
Price on the card vs. price in the order, before
3 → 0
Errors shown before the buyer has typed anything
1
The most serious finding: the one the audit asked to fix first
03
Coupons and promotions
Problem
The promotions page listed every offer at the same weight: hot deal, new-user discount, plan-specific codes, social offers. Nothing said which one applied to the chosen plan or whether they combined. “Claim” did not say what would happen next. And none of it reached the checkout: the buyer still had to remember a code and type it. Two of the seven findings were critical, and they are the same leak the checkout showed from the other side.
What I proposed
Connect the offers to the purchase. The best eligible code applies itself when a plan and size are chosen; the page shows only the offers that fit that plan and marks one as recommended; one promotion is dominant, the rest are quiet; “Claim” becomes “Apply to checkout”. This is logic more than layout, which is why it went into the queue with the checkout rather than as a separate redesign.
2
Critical findings: offers disconnected from checkout, best offer not auto-applied
7 → 1
Offers competing at equal weight → one dominant, the rest quiet
0
Codes a buyer has to remember after the fix
Finding → what I proposed
Coupons disconnected from checkout
Claiming an offer applies it in the order
Best offer not applied automatically
Highest-value eligible code applied by default
Too many offers, no guidance
One “best for you” label; the rest secondary
Offers shown for plans the buyer is not choosing
Filter by selected plan, size and eligibility
“Claim” with no stated consequence
“Apply to checkout”, “Copy code”: the action says what it does
04
The trader dashboard
Problem
A paid account opened on empty charts, a countdown with no label and a drawdown shown as the account floor, $48,000, where a trader thinks in the amount they can still lose. Profit, loss and risk were told by colour alone, in grey text under 12 px on a dark theme. The question that drives every session, “where do I stand and what next”, had no single answer on the screen.
Hypothesis
If the dashboard opens with stage, distance to passing, remaining buffer and one next step, traders stop assembling their status from fragments and support hears about it less.
What I proposed
A guided dashboard instead of a wall of equal cards. It answers the trader's questions in the order they ask them: where am I, how far to passing, how much can I still lose, what do I do next. That is the status band at the top: phase and an on-track mark, the profit target as progress, drawdown as the buffer left in dollars, the next step in one sentence. Only then the details, quieter: a KPI row where every number carries a sign and an arrow, a growth curve with the pass and breach lines drawn on it, a calendar with a value in every day, trade reports by holding time, and a closed-trades table whose net reconciles to the P&L above. Empty states say what to do first. The whole page was rebuilt as working HTML.
- Places to look for status
- 5 → 1
- Ways drawdown was written
- 3 → 1
- Signals by colour alone
- all → none
- Smallest label
- < 12 px → 14 px
The band was prototyped as a working page together with the rest of the dashboard: KPI cards with arrows and signs, a calendar with a value in every cell, empty states that name the first action. The accessibility review behind it lists fourteen findings against WCAG 2.2 AA, two of them critical.
3 ways
The same drawdown was written three ways across screens
14
Accessibility findings, two of them critical: meaning by colour alone
Guided
Where am I, how far, how much can I lose, what next: answered in that order
Finding → what I proposed
No clear “where I stand”: stage, progress, risk and next step were nowhere together
A status band at the top with all four, in trader words
Drawdown shown as the account floor, $48,000
Drawdown as the buffer left: “$3,842 before the account breaches”
Target, equity, drawdown, countdown and account data scattered at equal weight
Account data in a plain header, the four numbers in the band, widgets below
Profit and loss told by red and green alone
A sign and an arrow next to every colour, on cards, in the calendar, in tables
Labels, axes and badges in grey under 12 px on a dark theme
Readability tokens: larger labels, higher contrast, one hierarchy
Empty widgets looked broken on a freshly paid account
Empty states that explain why and name the next action: open the platform
Every piece of account information boxed into its own card
Cards only for real widgets; the header is text
Widgets stretched to odd heights
Full, half and four-column widths at one consistent height
05
The leaderboard
Problem
The leaderboard is the product's social proof: it should show that real traders get paid. Instead it showed the same name with the same profit twice, 100% win rates with no sample size, no word on how it was ranked or how often it updated, no link between a profit and a real payout, and nothing about the reader. The table was dense and flat, so even the top three did not stand out.
What I proposed
A trust section, not a raw table. Your own standing first: ranked or not, your best account, what gets you on the board. Three top cards with a verified-payout mark, then the full ranking. One line states the method: top 30 by realized profit, updated daily. Win rate as a bar, gains marked with an arrow, and a sample size next to any extreme number, so “100%” reads as “100% on 3 trades”. Prototyped as working HTML.
- Duplicated rows
- 2 → 0
- Extreme values with a sample size
- none → all
- Ranking method on the page
- absent → one line
- The reader's own standing
- absent → first
Drawn from the audit's leaderboard findings and the working prototype. The names are bars because the real board carried real traders; the numbers are illustrative.
7
Findings on one screen, from duplicated rows to a missing “you”
100% → 100% · 3 trades
An extreme number with its sample size
1 line
The ranking method, stated where the table starts
Finding → what I proposed
Repeated names and identical profits read as fabricated
Validate the ranking data; one row per trader
100% win rates with no context
A sample size next to any extreme value
No ranking method or update cadence
One line: top 30 · realized profit · updated daily
Profits not connected to real payouts
A verified-payout mark and a link to the certificate
The reader's own position missing
A “your standing” strip before the table
Dense, flat table
Three top cards, then the table with bars for scanning
06
Mobile
Problem
35% of traffic came from phones. Visitors from the Facebook in-app browser dropped at five times the desktop rate: 121 arrived, 19 continued. On the product, two floating widgets kept their desktop position and landed on top of content, including the checkbox that accepts the terms at checkout.
Hypothesis
If the mobile home page is fixed for the in-app browser that paid campaigns send people to, the continuation rate doubles, because the current state is a rendering problem, not a message problem.
What I proposed
Phase one, confirm the friction point in heatmaps; phase two, fix the banner, the tap targets and the rendering, and move floating widgets out of the content column. Deployed to all mobile traffic, no test needed: the baseline was broken.
15.7%
Facebook in-app browser visitors who reached a second page, vs. 75% on desktop
35%
Share of traffic on phones
≥ 50%
Target continuation rate, matching mobile Safari
07
Trust
One account had three names across screens. Rules at the moment of purchase were bare ticks and crosses with no legend. The same drawdown was written three ways. Every inconsistency in a product about money reads as unreliability, so these went into the queue as a taxonomy: one name per plan, one way to write drawdown, a legend and a tooltip on every rule.
Three leaks that cost money
01
Nobody could tell which plan was theirs
Problem
Ten combinations, no recommendation, and the help centre pointing to the community for the answer. Decision paralysis at the one step that precedes every purchase.
Hypothesis
If a three-question finder recommends one plan, more first-time visitors buy.
What I proposed
A plan finder under the comparison table and inside the FAQ, run as an A/B split with a bounce guard.
Proof
A clickable prototype of the finder; test plan with primary, secondary and guard metrics written before the build.
02
The price shown was not the price charged
Problem
$126 on the card, $157 in the order unless the code was found and typed. Premature errors and a countdown on the payment form. “/month” with no billing model.
What I proposed
Auto-apply the best code, show the discount as a line, state the billing model, validate on blur, drop the timer.
Proof
The most serious finding of the audit, with a working two-step checkout prototype.
03
The product answered “what happened”, not “where do I stand”
Problem
Status scattered across metrics of equal weight, drawdown as a floor, colour as the only signal, empty states that looked broken.
What I proposed
A status band with phase, target, buffer and next step; signs next to colours; labels at readable sizes; purposeful empty states.
Proof
A working dashboard prototype and 14 accessibility findings with severities, handed over as one queue.
Outcome
- 3 surfaces audited, findings from 6 sources, each ranked by impact
- 2 hypotheses written as if/then with evidence, test plan and success criteria
- 4 working prototypes: plan finder, two-step checkout, dashboard with a status band, leaderboard as a trust section
- The queue split into judgement work and execution, and a senior designer placed on the project to run it
An audit does not move a conversion rate; it tells you where the rate is lost and in what order to fix it. What happened next is the result: the client took the queue, and the audit turned into ongoing design support. As UX Practice Lead I defined the roles the work needed and brought a senior designer onto the project, who now works through that queue. The client is happy with the hire.
What I'd do differently: Define the business goal with the client in week one instead of anchoring on conversion alone. It was the safe metric, and it was right, but a stated goal would have ordered the queue faster.
Next case
Analytics for campaign reporting
Campaign reporting for a B2B marketing-communications platform: email, web and video on one shared reporting language, with the wave as the unit of comparison.
View case