User research · methodology

The number tells you what.
The person tells you why.

Portfolio metrics tell one story — fewer steps, faster compliance updates, lower KYC drop-off. The four traders below tell the other. Composite personas distilled from 32 real interviews across retail and institutional segments — and every measured number here shows its working.

Trader interviews
18 months

Composite personas
retail + institutional

147

Session recordings
Hotjar + GA4

Users per major
feature test

The operating model

Two tracks, run together.

Quantitative analytics locate the problem; qualitative research explains it. Neither is enough alone — a funnel drop tells you where users leave, never why.

Quantitative · what

"40% abandon at the risk-disclosure step."

GA4 funnels, Hotjar heatmaps and session recordings surface the anomaly — the exact screen, the exact click, the exact drop. Precise, but mute on motive.

Qualitative · why

"I don't understand why you need my tax ID for a demo."

Moderated interviews and think-aloud testing supply the motive behind the number — the fear, the mental model, the missing word. That is where the fix lives.

The toolkit

Three methods, chosen for fit.

Moderated interviews

45–60 min sessions with traders from novice to expert — mental models, workflow context, and emotional responses to risk.

Sample · 32 traders over 18 months

Usability testing

Task-based testing with a think-aloud protocol. Time-on-task, error rates, and subjective satisfaction on the System Usability Scale.

Sample · 15 traders per major feature

Behavioural analytics

Hotjar session recordings, heatmaps and funnel analysis to find where users struggle — then interviews to learn why.

Sample · 147 session recordings

Depth over theatre

Why n = 15 — and what it can't claim.

Sample size is a design decision, not a default. I size the study to the question — and I'm explicit about the ceiling of what each size can prove.

Retail usability studies run at n = 15 — enough to surface the recurring friction that drives a redesign, and the point where new participants stop revealing new problems. It is the right size to generate insight.

Institutional research runs the opposite way: n = 5, deeply. A relationship manager or quant developer shadowed through a real trading morning yields more signal than fifty superficial survey responses. The unit of research is a workflow, not a click.

What neither claims: statistical proof. Where a number needs it — like the Finlogix paired study — it carries the test and the effect size. Where it doesn't, I say so rather than dress qualitative insight as significance.

✓

n = 15 can

Surface recurring, prioritisable friction; reach saturation on task-level problems; validate a redesign direction.

n = 15 cannot

Prove a population-level effect or a precise conversion lift. That needs a powered A/B test, named as such.

✓

n = 5 deep can

Map an institutional workflow end-to-end — where latency, SLAs and audit clauses become design specs.

The evidence · four composites

Meet the traders.

Composite personas built from 32 real interviews — names changed for privacy. Retail voices express frustration emotionally; institutional voices express it in SLAs, latency, and audit clauses.

Samantha Dumas

Novice retail trader · 28 · Melbourne, AU · Marketing Manager, no finance background

Forex beginnerMobile-firstRisk-averse

I felt like I needed a finance degree just to understand what "leverage" meant. Every platform assumed I already knew everything. I just wanted to trade EUR/USD without feeling stupid.

Samantha's journey · overwhelmed → confident

01 · Account setup

Onboarding

"What's KYC? Why do they need my passport?"

02 · First trade

Execution

"I clicked Buy but nothing happened. Did it work?"

03 · Risk

Understanding

"How much can I lose? I don't understand 'margin call'."

04 · Proficiency

Confidence

"Now I get it. I can actually do this!"

Pain → design response

Key pain points

Platform assumed trading literacy — no onboarding tooltips
Jargon everywhere ("pips", "spread", "stop loss") with no explanation
Unclear feedback after placing orders — "Did it execute?"
Fear of losing money because risk wasn't visualised

My design solutions

Onboarding tooltips: contextual glossary for every financial term
Progress indicators: "Order submitted → executed → confirmed" stepper
Risk visualisation: "You can lose up to $X" shown before execution
Plain-language disclaimers: legal jargon replaced with clear warnings

Order placement · task timing (LogixTrader, moderated study)

Legacy8.2s

Redesigned2.9s

−65%

Faster order placement (8.2s → 2.9s) ^†

SUS score post-redesign, from 52 ^‡

40%

Fewer order-status support tickets

How these numbers were measured — and their limits

These are not persona narrative constructs. They come from a controlled usability study on the legacy and redesigned LogixTrader order-placement flow. The persona situates the finding; the numbers are independently measured.

† Task timing · 8.2s → 2.9s

Protocol: moderated think-aloud, same 15 participants tested both flows sequentially
Task: "place a market order for 1 lot EUR/USD as you normally would"
Timing: manual stopwatch + screen recording, dual-verified (±0.2s human reaction variance)
Start/end: click 'New Order' → order-confirmation modal appears
Limitation: legacy flow tested first (no counterbalancing); learning effect may understate improvement. Lab ≠ live trading. n=15 suits qualitative insight, not statistical validation.

‡ SUS score · 52 → 85

Instrument: standard 10-item System Usability Scale (Brooke, 1996)
Participants: same n=15 cohort (5 novice, 7 intermediate, 3 expert). Pre-score after legacy flow; post-score after redesign, same session.
Benchmarks: 52 = "Poor / D" (below the 68 acceptability threshold); 85 = "Excellent / A", top quartile (Bangor et al., 2009).
Limitation: potential order bias (legacy first), no washout period. Full methodology and session recordings available on request.

Michael Garnier

Intermediate day trader · 34 · Singapore · 3 years trading, follows market signals

Technical analysisDesktop power userData-driven

I need to make decisions in seconds. If your platform makes me click 5 times to see my P&L, I'm losing money while I wait. Every millisecond counts when markets move fast.

A typical trading day · 6am – 2pm

6:00amOpens Finlogix → scans 50+ market signals across 12 currency pairs
7:30amIdentifies 3 high-probability setups → sets price alerts
9:00amAlert triggered → opens LogixTrader → executes trade in <3 seconds
9:15amMonitors open positions across 3 charts simultaneously
12:00pmCloses profitable trades → reviews P&L attribution in TradingCup

Friction → design response

Workflow friction

Market data scattered across 3 platforms — context switching kills speed
No keyboard shortcuts — forced to use the mouse for every action
Chart customisation resets between sessions — reconfigured daily
Risk metrics hidden in dropdowns — couldn't see exposure at a glance

My design solutions

Unified dashboard: Finlogix aggregates signals + charts + news in one view
Keyboard-first execution: F9 buy, F10 sell, Ctrl+R close-all (industry-standard mapping)
Persistent workspace: chart configs and indicators saved per user
Real-time risk: P&L, margin usage and open positions always visible

40%

Faster market analysis (usability testing, n=15)

−67%

Finlogix "Data not found" support tickets (internal tracking)

Research method · usability testing + funnel analysis

The Finlogix "40% faster market analysis" figure comes from the same moderated n=15 protocol as the retail study — measured, not modelled. The ticket reduction is internal support-desk tracking before and after the aggregated-data redesign, not a third-party audited metric.

James Liang

Relationship Manager — Prime Brokerage · 41 · Hong Kong · 12 years institutional sales, manages 8 prime-brokerage accounts ($10M–$500M daily flow)

Prime brokerageInstitutional salesAccount oversight

My clients don't call me when a trade executes. They call me when it doesn't. I need to see every open order, every FIX session status, every credential expiry — before my clients see it first. Your platform is my early-warning system.

The accountability model

What was failing

FIX session downtime discovered by the client before the RM — trust erosion
No unified view: order status, credit limits and connectivity on 3 separate screens
Credential renewal: manual email chain, 5-day lead time, no self-service
Compliance queries needed an IT ticket — 48h SLA; clients expect minutes

Design outcomes · ACY Connect

Unified dashboard: FIX session health, credit exposure, order volume — one view
Proactive alerts: latency spike → push notification before the client sees it
Self-service credentials: RM generates API keys and resets passwords without IT
Audit exports: one-click compliance reports formatted for ASIC / SFC review

Research method · contextual inquiry + shadowing

Shadowed 3 RMs during live trading hours (9am–12pm HKT) across 4 sessions — real screen workflows, not simulated tasks. Key insight: RMs have zero tolerance for latency in information retrieval, because any delay is felt by their institutional clients as service failure. Task-based usability testing was insufficient — the research required being present when the stress was real.

Ravi Mehta

Quant Developer / Systems Integrator · 33 · Singapore · Python/C++, connects hedge-fund OMS to broker infrastructure via FIX 4.4

FIX 4.4 protocolAPI integrationLow-latency systems

I don't use your UI — I use your API. But when something breaks at 3am during Tokyo open, I need documentation that tells me exactly which FIX tag is causing the OrdStatus rejection. Ambiguous docs cost me hours. Clear docs cost me minutes.

FIX session lifecycle · where design decisions live

CREDENTIAL SETUP

CompID, SenderID, password — RM self-service portal

SESSION INIT

Logon (MsgType=A), heartbeat interval, sequence reset

ORDER FLOW

Tag 150 ExecType → Tag 39 OrdStatus state machine

RECONCILIATION

EOD position match, reject-code audit trail export

Developer experience → portal outcomes

DX failures

FIX tag documentation: PDF, no search, no code examples
Error codes undocumented — meaning discovered by trial and error
Test environment shared with other clients — sequence-number conflicts
Credential rotation required email to ops — 3-day SLA in pre-production

Developer portal outcomes

Interactive FIX spec: searchable tag reference, OrdStatus state-machine diagram
Error-code glossary: every reject code → plain-English cause + resolution
Isolated sandbox: dedicated test environment per client, no sequence conflicts
Self-service key rotation: RM portal rotates credentials without an ops ticket

Research method · developer interview + API journey mapping

5 semi-structured interviews with quant developers and systems integrators at institutional clients. The primary artifact was not a journey map but an API integration audit — walking every step of the FIX session lifecycle and recording where developer time was lost. Key finding: documentation quality affected integration time more than API design itself.

↗

This persona is a composite — the full institutional research runs deeper

FIX session lifecycle mapping, API credential UX, IP-whitelist flow analysis and integration-time-as-a-metric are documented in the ACY Connect case study →

The methodological insight

Different users, different instruments.

The biggest research lesson across four years: the method has to fit the user, not the other way around. Force a retail usability protocol onto an institutional developer and you learn nothing that matters.

Retail traders

Emotion, measured

Moderated usability testing, think-aloud protocol
Emotional-state mapping — frustration, confusion, confidence
Quantitative SUS scoring + task-completion rates
Hotjar heatmaps for behavioural validation
n = 15 per feature is right for insight generation

Institutional stakeholders

Workflow, shadowed

Contextual inquiry + live workflow shadowing
SLA and latency requirements as design specifications
API journey audits — integration time as the UX metric
Compliance-clause analysis as user-requirement input
n = 5 deeply is more signal than n = 50 superficially

Insight → decision

How a finding becomes a fix.

Problem discovery

Start with analytics anomalies — heatmaps show clicks on non-clickable elements, funnels show a 40% drop at order confirmation. That is where I dig.

Example · noticed 40% of traders abandoning the order flow at the "Risk Disclosure" step. Analytics told me where, never why.

Qualitative research

Recruit 15 users matching the demographic → run moderated think-aloud testing. Record sessions, ask follow-ups, observe the emotional responses the numbers can't show.

Finding · 12 of 15 traders said "I don't understand why you need my tax ID for a demo account." Legal's compliance text was scaring users away.

Design iteration

Synthesise → create 2–3 variations → validate with real users, measuring both task performance and satisfaction.

Solution · redesigned the risk disclosure with progressive disclosure — minimal text by default, "Learn why" for the full legal copy. Completion rate: 60% → 92%.

Same rigour at both ends — emotion and audit clause alike.

Retail novices need think-aloud protocols and emotional mapping. Institutional developers need API journey audits and integration-time metrics. What holds constant is the discipline: size the study to the question, and show the working behind every number.

LogixTrader · n=15 paired study ACY Connect · developer audit Finlogix · 40% faster analysis Data verification framework

Related work

Research-led decisions in shipped work

Case study Christie's — Private Banking UHNW client interviews and 5 persona variants shaping advisor-client flows. Case study ACY Securities Four years of trader workflow observation across 5 platforms. Case study LogixTrader MT4/5 trader observation — order-entry friction and 5-platform workflow audit. Case study PawsRoam B2B2C research — pet owner and venue operator interviews across 40+ countries.