All work

50K

Margin trading platform · CySEC-regulated · iOS, Android, Web

Making margin trading readable for people who have never traded.

Role
Senior Product Designer
Period
2022 — present
Surfaces
iOS · Android · Web · Admin · Marketing
Team
Sole designer; led two designers at peak
Scale
~1,400 active traders and ~1,600 new positions a day
Visit the live 50K site
01 — What made it hard

Two audiences pulling in opposite directions.

50K had to work for a first-time investor who needs context and guardrails, and for an experienced trader who expects density and speed. The work was never about removing complexity. It was about revealing the right thing at the right moment, and being honest about the rest.

  • Regulation isn't a design preference. As a CySEC-licensed firm, certain risk disclosures must appear, in specific places, at specific moments. You design around them, not over them.
  • Every number moves. Prices, margin and P&L change underneath the layout. Anything that only looks right at rest is broken.
  • 390 points of width. Chart, price, sentiment, funds, controls and disclosure all compete for the same phone screen.
  • Three surfaces, one team. App, internal admin and marketing all had to stay recognisably the same product.
02 — How I worked

Mostly one designer, inside a startup.

The setup

For most of the four years I was the only designer on the product — working directly with product and engineering, from early requirements through wireframes, final UI, implementation and QA. At its largest the design team was three, and I led the other two.

I use HTML/CSS and Flutter UI to close the gap between a Figma file and what actually ships, which means visual QA is something I can fix rather than only report.

The test I kept using

Could my dad understand the risk before confirming? He has never traded. If a screen needed a second explanation to make sense to him, the screen was wrong — not him.

Where I pushed back

Stakeholders occasionally proposed controls because they looked right on a specific screen, even when their behaviour meant something else elsewhere. I pushed back when that would break a familiar UX convention or weaken the system. A control should keep the same meaning wherever it appears.

Where I was flexible

I owned the design recommendation; product owned the final product decision. When a request did not reduce clarity or create inconsistency, I was flexible. When a UX disagreement remained, we built and tested both versions instead of settling it by seniority.

The homework. I also trade regularly on a competing platform with my own money. It is not a substitute for user research, but it makes every delay, ambiguous label and irreversible action feel concrete. I pay attention to what I miss, what frustrates me and which patterns may be worth adapting — not copying.

03 — The journey

Five moments, one continuous decision.

Everything in the product sits on this spine. When a new feature was proposed, the first question was which of these five moments it belonged to — and what it would push out of the way.

Discover

Home, watchlists, movers, market news.

Understand

Instrument detail, sentiment, analyst view, key stats.

Decide

Direction, size, margin, likely profit and loss.

Order

Market and limit orders, confirmation, edge states.

Monitor

Open and closed positions, portfolio, P&L.

04 — Deep dive

Registration and identity verification.

KYC is the highest-friction part of any regulated trading product. It is mandatory, document-heavy, legally worded and very easy to abandon halfway through. 50K's original flow was the conventional one: long forms, several questions per screen, an upload step that punished you for a bad photo.

I rebuilt it around four ideas. The flow below is the shipped one, in order.

The whole mapEvery step visible up front, with how long approval takes — before the first upload.
Show, don't scoldA diagram of a correct scan, so a rejected upload is prevented rather than reported.
Why we askThe risk warning is the screen, not a footnote under it. Regulation used as content.
One questionOne decision per screen, progress always on top. Seven of these beat one long form.

Four screens from the shipped flow. The bar at the top of every question screen is the whole argument: at no point are you asked to trust that this ends.

  • One question per step. A single decision on screen, in plain language, instead of a page of fields.
  • Say why. Every request that feels intrusive — income, experience, whether you're a politically exposed person — explains what it's for before it asks.
  • Complete transparency on progress. Where you are, what's left, and what happens after. No open-ended waiting.
  • Acknowledge small wins. Finishing a step is confirmed, not silently accepted. It sounds small; over seven steps it's the difference between a form and a conversation.

The number that mattered was how many people who installed the app went on to finish verification and could actually trade. That is what this rebuild was aimed at, and it is the number at the end of this page.

05 — Deep dive

Order entry, where design becomes money.

This is the screen most trading apps get wrong. It's also the one where an interface decision turns directly into a financial consequence, so it earned the most iteration. The animation at the top of this page is the real flow; here is the same screen, decision by decision.

50K order entry annotated: direction toggle, required margin, amount slider, likely profit and loss, funds, limit order controls and the confirm button
  1. 1Direction first. Short or Buy, with both live prices, before anything else is asked.
  2. 2Required margin is the headline. Leverage splits one decision into three numbers — the money you put in, the position that money controls, and the number of shares that buys. All three move together, and all three are editable: you can size a trade by share count, by position value, or by the money you are actually risking. Margin gets the largest type because it is the only one of the three that leaves your balance.
  3. 3Both outcomes, equally weighted. Likely profit and likely loss over the next hour, shown together. Only showing the upside would be a design choice too.
  4. 4Depth stays one tap away. Limit price and stop levels live under More Options — present for the people who want them, invisible to everyone else.
  5. 5The funds check resolves before the button. Sufficient or insufficient funds is answered above the confirm action, not after you press it.

An earlier version used fixed amount buttons borrowed from the deposit flow. That pattern works when speed is the main job, but sizing a leveraged position requires more control. We tested both variants. The slider performed better and became the order-entry pattern; fixed amounts remained in deposit, where they belonged.

The states below the happy path were designed with the screen rather than patched on afterwards: market closed, price moved since you opened the ticket, insufficient funds, order rejected, limit order pending, and the confirmation itself. In a trading product the edge state is the product — it's the moment someone decides whether to trust you.

The one we got wrong first

The same pattern kept showing up: someone would open a position, close it seconds later, repeat that for about a minute, and then stop trading entirely. It looked like panic. It wasn’t. The market was closed, and when the market is closed an order becomes a future order that fills at the open. People hadn’t registered that, so they were watching positions that never seemed to happen, and trying again.

The market-closed state was already on the screen. It was at the top, it was accurate, and it wasn’t working. I made the header state the consequence rather than the status — orders can be placed, they fill when the market opens — and repeated it directly above the confirm button, with a timer counting down to the open, at the moment the decision is actually made. After the new state was released, we observed a sharp drop in repeated pending orders.

What’s obvious to the person who designed a screen isn’t obvious to the person using it, and text being present isn’t the same as text being read. Moving the same sentence to where the decision happens did more than adding sentences would have.

06 — Deep dive

Making market data answer a question.

Before Market Radar, users could inspect an instrument only if they already knew what to look for. Radar scanned the instrument list for unusual conditions — a period high, an abnormal move or behaviour outside an instrument’s normal pattern — and turned each finding into a card.

Financial data often arrives as a table. That works for experienced traders who know what to scan, but it does little to help a new user understand what is unusual or why it may matter. The insight components lead with the finding and keep the supporting data visible underneath.

Radar card: Apple is at a one month peak, with the price chart, projected up and down paths, and short and buy actions Analyst consensus card: average rating 4.2 on a sell-to-buy scale with a target price, and the data source named Historical returns card: average annual return shown as a bar chart by year, including one negative year in red Get real-time signals card asking to enable push notifications for major market events

The Radar layer as it ships. Each card explains what happened, keeps the supporting data visible and makes Short and Buy equally available. Radar surfaced information; it did not take a directional position.

What users asked for

Later, in-product surveys showed that many users wanted clearer guidance. We treated that as a different product and regulatory problem, not as a reason to distort the original Radar layer.

Ideas

After confirming what could be offered within the company’s framework, we added a longer-horizon Ideas layer. Each idea explains a directional view over months, the market data and analyst input behind it, and the main risks. Users can still review the reasoning, disagree with it and choose either action.

Golden Tip card: an Apple buy idea with expected upside, publication and target price, the reasoning behind it and the main risk, with short and buy actions

Ideas is in early rollout. Measurement is still running, so the case study does not claim an outcome yet.

07 — The system

One product, one visual language.

I joined 50K at the very start, so there was no design system to inherit — the company was young and the first job was a product that worked at all. What existed was a logo, a typeface and a brand green, and the first screens were built straight off those.

The app, the internal tools and the marketing site were drifting into three separate visual products. A campaign would invent a shade of green; admin would invent a table style. Every fix was a conversation about taste rather than a lookup.

I built shared foundations — logo lockups, colour, typography, iconography, illustration and components. The product was designed dark-first, partly to separate 50K from competitors who were mostly light at the time. Once the dark system stabilised, I mapped the same foundations to Light Mode so hierarchy and behaviour remained consistent across themes. The trading product supports both themes, while marketing and internal tools use the same shared foundations.

50K logo lockups in four approved variants: green on dark, dark on green, green on white and white on green The 50K icon library: a grid of forty-two line icons covering trading, account, education and messaging actions The 50K spot illustration set: nine illustrations for statements, market hours, verified identity, referral links, invitations, translation, education, account settings and funds

Logo lockups, the icon library and the illustration set — the light half of the system. Every app screen further up this page is the dark half. Same brand at full strength in both.

The product uses one primary colour role per theme: dark resolves to #1DDE8D, light to #269969 — theme counterparts, not separate semantic greens. The light primary keeps the white label used in the shipped product, and no additional UI greens are part of the system. The tokens, themes and components ship as Flutter code, so the system is the implementation rather than a reference for it.

Keeping the system meant defending what a component means — and extending it, or deliberately breaking a rule, when a real product need earned it. When a disagreement about that remained, we built and tested both versions.

The motion layer

Motion ships as part of the system, not on top of it. I animate the micro-interactions in After Effects and deliver them to the app as Lottie — deposits, rewards, confirmations, empty states — so the product moves the same way everywhere, at a few kilobytes each.

Deposit
Funds arrive
Reward
Boost
Personal details

The second before the screen arrives

We hit a stretch where some screens took about a second to fill. A second is not long. A blank screen for a second makes a product feel unreliable.

I designed skeleton states with a shimmer and built them in Flutter myself. The skeleton holds the real structure in advance — the same sizes, spacing and radii the content will use — so when the data lands it appears exactly where the placeholder was, with nothing jumping. It did not make anything load faster. It made the wait legible, and it stopped the layout rearranging itself under someone’s eyes. That is part of the system too: not only what a screen looks like when it is ready, but how it behaves on the way there.

What the system changed in practice: engineering stopped guessing, visual QA became a check against a spec instead of a matter of opinion, and the gap between the marketing site and the product it was selling closed.

Explore the full 50K Design System The complete light-and-dark colour map, the type scale at seven weights, the button contract, and the components in every state.
08 — Outcome

What changed.

35% → 75%

Internal cohort metric measured over more than three months: the share of new app users who completed identity verification and became active traders increased from 35% to 75%.

One foundation,
three surfaces

Shared foundations and components aligned the trading app, the internal admin and the marketing site, in light and dark.

Design and engineering stopped arguing from taste and started checking against a spec.

What I learned

Removing information can make a screen look cleaner while making the decision less clear. That trade is very easy to make by accident, and in fintech it costs somebody money.

The trade-off

More context helped a first-time trader and slowed an experienced one down. The final approach used a clear default, with the depth one tap away — rather than one flattened experience for everybody.

What I'd do differently

Earlier parts of the product taught me to treat failure and recovery as part of the core flow. By the time we redesigned order entry, those states were designed alongside the happy path. Today I would make them explicit from the first workshop.

Let's build something worth using.

Open to senior product design roles in complex, system-heavy products — especially where design stays close to implementation.