What Trading UIs Actually Need

I spent most of 2022 building interfaces for a multi-asset broker. Forex, crypto, indices, commodities — traders switching between instruments all day, watching numbers change in real time, making decisions that have immediate financial consequences.

The interface conventions I'd learned building marketing sites and SaaS dashboards almost all broke here.

The whitespace problem

I'd internalized "generous whitespace = good design." That's broadly true for marketing pages, blogs, and SaaS onboarding flows where cognitive ease is the goal.

Trading dashboards are not those things.

A trader watching five currency pairs wants to see all five at once. They do not want to scroll. Whitespace that signals "premium" to a SaaS user signals "I can't see my positions" to a trader.

Information density is not the enemy of good design in high-stakes, high-expertise contexts. It's the requirement. The job is to make density legible, not to reduce it.

What "legible density" actually means

A dense interface becomes illegible when elements compete visually at the same weight. Everything bold is nothing bold. When every row in a data table looks the same, the eye has no path through it.

Legible density is density with hierarchy. The three numbers a trader looks at most — current P&L, open exposure, margin level — need to be immediately scannable. Everything else is supporting context.

The technique is heavy use of secondary color for supporting information. When the primary data is full-opacity and the secondary data is 50–60% opacity, the hierarchy reads even at high density. The eye knows where to go.

Live data is a UI state, not just a number update

In a normal interface, data is mostly static — it was fetched, it rendered, it sits there. Occasional updates come in and some numbers change.

In a trading interface, dozens of prices are ticking continuously. Every number is live. And a number changing is information — the change itself is the event.

I learned to treat price updates as UI states: positive change, negative change, neutral. Each gets a distinct visual treatment. Not just color (green/red) — a subtle flash animation on update, so the eye knows something happened even when looking at a different part of the screen.

This sounds small. It changes the experience of the interface entirely. Traders talk about "feeling" the market — part of that feeling comes from a UI that communicates movement, not just current value.

Performance is a design constraint

A table rendering 50 live prices, updating multiple times per second, will destroy your frame rate if you handle it naively.

The naive approach: update state on every tick, re-render the table, React diffs the DOM. At 50 rows × 5 updates/second, you're doing 250 renders per second on that table alone.

The right approach is to bypass React for the price numbers. Grab the DOM node directly and update textContent. No virtual DOM, no diffing, no reconciliation. The cell changes, nothing else does.

This is not "good React" in the conventional sense. It's the right tool for the constraint. Design decisions and engineering decisions are the same decision at this level — how you update data is how the trader experiences time.

What I took from this

Different users in different contexts need fundamentally different things. Designers trained on one context can accidentally import its assumptions into contexts where they don't apply.

The traders I was designing for were experts. They'd spent years learning this domain. The interface's job was to serve their expertise, not to reduce it — not to simplify what they already understood, but to put information where they expected it, as fast as possible.

Designing for expertise is different from designing for onboarding. The rules almost invert.