Anatomy of a Trading Interface: The UI Components Every Trading Platform Needs

Open any trading interface, from a retail crypto exchange to an institutional execution platform, and you will find the same handful of components arranged in slightly different ways. The order book is on one side, the chart takes the middle, there is an order form within reach, and a strip of tables sits along the bottom. The visual language is so consistent across the industry that traders can sit down at an unfamiliar platform and be productive in minutes.

That consistency is useful for anyone building a trading UI, because it means the component list is known in advance. What varies is how well each one is executed. This post walks through the standard components of a trading interface, what job each does for the trader, what data it consumes, and the detail that separates a good implementation from a merely functional one. The examples come from the Hedge UI demo, which ships nine dockable panels and a header, and each section links to a deeper write-up where one exists.

The component map

The update rate column is the one to study. A trading interface is a set of components that each run at a different speed, and most performance problems come from treating them all the same.

Header ticker and product selector

The header is the only part of the interface that is always visible, so it carries the two things every other component depends on: which market is selected and what its headline numbers are.

The demo's header shows last price, 24-hour change, high, low, and volume, all read from a single <symbol>@ticker stream. Two details are worth copying. First, the last price is coloured by tick direction, green if it rose since the previous value and red if it fell, with a ref holding the previous price so the colour persists when a message arrives with an unchanged price. Second, the stats disappear progressively on narrow screens: last price and change show from the md breakpoint, high and low from lg, and volume only from xl. The least important number goes first.

The product selector is a searchable combobox built from cmdk inside a popover, with a star on each row to add the market to the watchlist. The list comes from the exchange's exchangeInfo endpoint, filtered to an allow-list of 31 base assets so the demo is not offering several thousand illiquid pairs. Keyboard-first navigation matters here more than almost anywhere, as argued in the post on command palettes for trading UIs.

Order book

The order book is the component that tells a trader where liquidity sits. It shows resting sell orders (asks) above resting buy orders (bids), each row a price level with the quantity available there and usually a running total.

It is the most demanding component in the interface. It updates fastest, it has the densest layout, and traders read it with more attention than anything except the chart. The demo subscribes to Binance's depth10@100ms stream, which pushes the top ten levels of each side every 100 milliseconds, and renders three columns: price, amount, and cumulative total. A depth bar behind each row shows relative size.

What a good order book gets right:

• Stable row positions. Prices move, but the rows should not jump. Asks are rendered reversed so the best ask sits directly above the best bid.
• Aligned decimals. Every price is formatted to the same number of fraction digits, taken from the product's tick size, so digits line up in a column.
• Cheap depth bars. The demo scales a full-width element with transform: scale3d(...) rather than animating width, which keeps the update off the layout path.
• Interaction. Clicking a price, amount, or total writes it into the order form.

The data modelling and rendering approach is in the real-time order book deep dive.

Market trades

The trades feed, sometimes called time and sales or the tape, lists executions as they happen: price, size, and time, coloured by which side was the aggressor.

It answers a question the order book cannot. The book shows intent. The tape shows what actually happened. A wall of bids that never trades is information, and so is a run of large buys lifting the offer.

The implementation challenge is that trades are bursty. A calm market prints a few times a minute and a volatile one prints hundreds of times a second. The demo seeds the list with the 20 most recent aggregate trades over REST, then appends from the aggTrade stream in batches of five, de-duplicating by trade ID and capping the list at 20 rows. The reasoning behind batching rather than rendering each print is in the piece on throttling and batching market data.

Market chart

The candlestick chart is where traders spend most of their attention, and it is the component with the widest gap between a basic version and a professional one. Candles and a volume histogram are a weekend. Indicators, drawing tools, multiple timeframes, and saved studies are a year.

That gap is why most teams should not build it. The options, from lightweight canvas libraries to embedded commercial widgets, are compared in choosing a charting library. The pipeline behind a self-built chart, aggregating ticks into candles and handling the partial candle, is in streaming candlestick charts.

The demo embeds TradingView's Advanced Chart widget. The React component is under thirty lines, traders get a charting experience they already know, and the cost is that the chart lives in an iframe and cannot share state with the rest of the workspace. For a starter kit that trade is right. For a platform whose differentiator is charting, it would not be.

Order form

The order form, or order ticket, is the only component where a mistake costs the user money directly. Everything about it should favour correctness and clarity over cleverness.

The minimum viable ticket has a price, an amount, a computed total, and buy and sell buttons. The demo's version is exactly that, a limit order form, and its help text explains why it stops there: order parameters differ so much between venues that anything more elaborate would be guesswork.

What it has to get right:

• Arithmetic. Totals are computed with decimal.js, never native floats. See decimal precision in trading order forms.
• Input discipline. Values are truncated to the product's price and quantity precision as the user types, and characters that a number input would otherwise accept (e, E, +, -) are rejected.
• Unambiguous actions. Buy and sell are separate, full-width, colour-coded buttons. There is no shared submit button with a side toggle that can be left in the wrong position.
• Feedback. Submission produces an immediate, specific confirmation. The patterns are in building a notification system for trading alerts.

Watchlist

A watchlist is a compact table of markets the trader cares about, with live prices and daily change, where clicking a row switches the whole interface to that market.

It is the main navigation device for anyone who trades more than one instrument. The demo calls it Favourites: starred symbols appear in a sortable table with last price and 24-hour change, each fed by its own ticker stream over a shared connection. Sorting state is saved per panel, so a watchlist sorted by daily change stays that way after a refresh.

The detail that matters is what happens before data arrives. A row with no ticker yet shows a dash, not a zero. A price of 0.00 is a claim about the market, and a dash is an honest "not yet". The broader principle is in connection status, loading, and empty states.

Balances

The balances panel shows what the account holds and what it is worth: asset, quantity, average entry price, current price, market value, and profit or loss.

It combines two kinds of data that move at different speeds. Holdings change when the user trades. Valuations change every time the market does. The demo hardcodes quantities and average prices, since there is no real account behind it, and computes value, allocation, and P&L live from ticker streams. An allocation column with a small progress bar shows each asset's share of the portfolio at a glance.

For platforms spanning more than one asset class, the modelling questions get harder, and they are covered in handling multi-asset portfolios.

Open orders

Open orders lists everything the trader has working in the market: product, side, type, limit price, quantity, how much has filled, and when it was submitted.

It is a table, and it should be a good one. Sortable columns, a sticky header, right-aligned numbers, and a fill progress indicator. The demo's version renders 100 generated orders across seven symbols, with a live current price beside each limit price so the trader can see how far away the market is. Prices in this table are throttled to one update a second, which is the difference between a table that feels calm and one that flickers. The table architecture shared by balances, open orders, and the watchlist is described in headless tables with TanStack Table.

Price and volume widgets

Smaller analytical widgets fill the gaps the main chart leaves. The demo has two: an area chart of price and a bar chart of volume, each with interval buttons from five minutes to one week and a manual refresh.

These are deliberately simple. They load candles over REST through TanStack Query, render with Recharts, and store the selected interval per panel. They exist to show that not every chart in a trading interface needs to be a streaming candlestick engine. A lot of useful context is a static series that refreshes on demand.

The workspace that holds it together

The components above are only half of a trading interface. The other half is the surface they sit on. Professional traders arrange their screens deliberately, and a platform that forces one fixed arrangement is telling them how to work.

In the demo every component is a panel in a dockable layout. Panels can be dragged, tabbed together, resized, maximised, and closed, and the arrangement can be saved as a named layout. Each panel also has a help popover explaining what it shows and where the data comes from. The layout engine is covered in resizable, dockable panel layouts, saving it in persisting UI state to localStorage, and the registry that connects panels to the layout in feature folders and the panel factory.

What ties the components together

Three things are shared by every component, and they are what make a set of widgets feel like one interface.

One selected product. The order book, trades, chart, order form, and header all follow a single selected market held in context. Change it anywhere and everything follows.

One precision model. Price decimals come from the product's tick size and quantity decimals from its step size. Every component formats through the same helper, so a price looks the same in the book, the tape, and the tables.

One colour language. Bid and ask, buy and sell, up and down all draw from the same small set of theme tokens. Green means the same thing everywhere. The token setup is in designing dark mode for trading interfaces.

Where to start

If you are building these components yourself, the order to tackle them in is covered in the trading UI development roadmap. The short version: data layer first, then the order book, then everything else.

If you are evaluating an existing platform or a starter kit, use the table at the top of this post as a checklist. For each component, ask what happens when the feed is slow, when the symbol changes, and when the number has eight decimal places. The answers tell you more than the screenshot does.