NEW TRADING PLATFORM
Designing the foundations of a new trading platform
The platform already had a live trading ecosystem, but the new platform was being built on a new backend. We had to decide what should carry forward, what needed to change and what could support web, iOS, Android and PWA from the start.
01Starting with the Foundation
We weren’t redesigning one screen at a time
The new backend meant the product needed a new foundation rather than a sequence of isolated redesigns.
Authentication, navigation, trading, search and account experiences all had to make sense as parts of the same platform.
Some existing patterns were worth keeping. Others only made sense because of the old system.
02Planning for Real Life
Login turned into more than ten scenarios
Authentication looked like one of the simpler places to start.
It wasn’t.
Returning users, new devices, recovery, suspicious activity, biometrics and different platform capabilities quickly turned one login flow into a connected set of states.
I had to structure them together before designing the individual screens.
03From Access to Action
Trading had to feel fast without hiding risk
Once users were inside the product, the core job was still trading.
The interaction had to stay quick, but actions such as order type, quantity, stop loss and take profit still needed enough context to prevent avoidable mistakes.
I worked through the trade ticket as a reusable pattern rather than a one-off screen.
04Turning Ideas Into Product Decisions
Some ideas stayed on paper
We explored dashboard, search and AI directions while the wider product was still taking shape.
They were useful for understanding where the platform could go, but authentication became the immediate priority.
A secure, understandable way into the product mattered more than making the future platform look complete in Figma.
05Cross-Platform Thinking
The platforms could not behave identically
Web, PWA, iOS and Android shared the same product logic, but they could not always use the same interaction.
Biometrics made that obvious. Native apps could rely on the device. PWA needed a fallback when the browser could not recognise or trust the device in the same way.
The goal was one understandable security model, not four identical interfaces.
06PROJECT OUTCOME
What changed
- 10+
- Security scenarios mapped
- 1
- Shared authentication model
- 4
- Platforms accounted for
Authentication model established
Signup, login, recovery and security states were mapped as one connected system.
Platform differences resolved
Shared product logic could adapt to native and web capabilities without forcing identical behaviour.
Security states connected
Device trust, biometrics and suspicious-login scenarios were designed as parts of the same journey.
Foundation for later work
The same product structure could support later navigation, trading and account work without restarting from individual screens.
07Looking Back
I couldn’t solve the platform differences alone
Working with engineering early changed some of the solutions before they became expensive to change.
Platform APIs, browser limitations and security requirements made it clear where one interaction could stay shared and where it needed a different implementation.
That collaboration made the product more coherent, not because every platform behaved the same, but because we agreed on what needed to remain consistent.