2024

Fusion Markets

A broker with no product of its own — its traders lived inside someone else's platform. One experience, designed across web, mobile and desktop with product and tech.

Product DesignDesign SystemsMobileDesktop

Role

Product Designer

Timeline

6 months

Team

Product and tech

Year

2024

Fusion Markets

the challenge

Fusion Markets is a forex and CFD broker founded in Melbourne by Phil Horner, regulated by ASIC, the VFSC and the FSA. The whole company is built on one promise: get people into the world's markets for radically less than it costs them today. Over 250 instruments, commissions around $2.25 a side, average spreads of 0.0 on the majors — pricing they describe as roughly a third below the competition.

What Fusion did not have was a product of its own. Every client arrived through somebody else's software — MetaTrader, cTrader, TradingView — platforms Fusion could price into but never shape. There was no Fusion mobile app and no Fusion desktop app. The brand ended at the sign-up form, and from the first trade onward the experience belonged to a third party.

That left a gap between the promise and the product. A broker whose two other pillars are a frictionless experience and legendary service had no surface on which to deliver either. The brief was to close it: one Fusion experience, consistent from a phone on the train to a six-monitor desk, without asking a trader to relearn the product each time they switched.

The challenge, 1
The challenge, 2

my approach

The unlock was to stop treating web, mobile and desktop as three projects. They are three viewports onto the same product, and the things that actually differ are fewer than they look: how much fits on screen, how you point at it, and how long you stay. Everything underneath — the instrument list, the order ticket, the position, the account — is one model.

So the work started with the system rather than the screens: the primitives a trading interface leans on over and over, and the rules for how they compress. An order ticket is the same object whether it is a modal on desktop, a sheet on a phone, or a docked panel on a second monitor. Nailing that once is what made three platforms tractable instead of three times the work.

Where the platforms genuinely diverge, they diverge on purpose. Desktop earns density, because someone with the app open all day wants more on screen, not less. Mobile earns speed and thumb reach, because it gets used standing up, in a minute, to check or close something. The design language holds; the ergonomics do not pretend to be the same.

The approach 1

the process

  1. Audit what traders already knew

    Before drawing anything, map what MetaTrader, cTrader and TradingView had already taught Fusion's clients. A broker's first product cannot ignore fifteen years of muscle memory — every convention we kept was a decision, not an accident, and every one we broke had to earn it.

  2. Model the product once

    Name the objects the whole product is made of — instrument, order, position, account — and how they relate. Three platforms only stay coherent if they are three views of one model, so this is the document everything else is checked against.

  3. Build the component system

    Design the primitives a trading interface repeats endlessly, and the rules for how each one compresses as the viewport shrinks. An order ticket is one component with three presentations, not three components that happen to look alike.

  4. Specify each platform's ergonomics

    Decide per surface what changes: density on desktop, thumb reach on mobile, what gets cut and what gets promoted at each size. The visual language holds constant; the ergonomics are allowed to differ, on purpose and in writing.

  5. Prototype the risky screens

    Get the order ticket and the positions list in front of people on real devices, before the rest of the flows depend on them. These are the screens people touch every day and the ones a static mockup lies about most.

  6. Ship and hand over

    Roll out platform by platform alongside engineering, with the system documented so the team could keep extending it without me in the room. A design system nobody can use after handoff is just a very neat file.

web app

The web app is the baseline — the first surface where the full Fusion experience existed end to end, and the reference the other two are measured against.

Fusion Markets — web app 1

mobile app

Mobile is where most traders check in. Built for a minute at a time and one thumb: positions, prices and the close button reachable without a second hand.

Fusion Markets — mobile app 1
Fusion Markets — mobile app 2
Fusion Markets — mobile app 3

desktop app

Desktop is for the people who leave it open all day. More density, more panels at once, and room to lay the workspace out the way they actually work.

Fusion Markets — desktop app 1

design system

The component system underneath all three. Tokens, states and the compression rules that let one order ticket be a modal, a sheet and a docked panel without ever becoming three separate components.

Fusion Markets — design system 1
Fusion Markets — design system 2

the results

Fusion Markets now has an experience of its own, on every surface a trader uses — the first time the brand extends past the sign-up form and all the way through the trade.

What shipped, and what changed because it did. A number here is worth a paragraph — and so is the thing nobody logs.

3

web, mobile and desktop

Platforms shipped

00%

on the metric that mattered

Headline result

Shipped

Rollout

The results, 1
The results, 2
Let's talk

Building something where design and engineering shouldn't be two separate jobs? Send it over. I read every message.

Mao Lop

Mao Lop

Open to Design Engineer, Product Engineer and AI Product Engineer roles — full-time or contract.

1

let's make something together

CONTACTdrop a line