← Back to blog

July 27, 2026

|

5 min read

|

By Silver Owl

What building a trading terminal taught us about data-heavy UIs

Product DesignEngineeringAPEX

We built APEX Terminal because market data is messy, fast, and unforgiving. A trading screen is not a marketing dashboard. If a quote is stale, a chain is slow, or a layout hides the one number that matters, the product fails in the moment it is needed most.

Working through watchlists, options chains, flow, charts, earnings, and briefing views forced us to treat UI as an operations problem. Below is what stuck.

## Density is a feature until it becomes noise

Early layouts tried to show everything: multi-index sparklines, sector heat, conviction lists, macro strips, news, and a chart in one pass. It looked capable in screenshots. In use, the eye had nowhere to rest.

We learned to design for scan paths, not panel counts. A trader opens the terminal and asks three questions in the first two seconds: what moved, what is expensive right now, and what needs attention. Everything else is secondary until one of those answers is clear.

On APEX, that meant:

- One primary surface per mode (chart, chain, flow, briefing), with supporting panes that shrink instead of compete. - Persistent context (symbol, session, account mode) that does not jump when tabs change. - Fewer “always on” widgets. Index cards and macro strips earned their place only when they changed decisions, not when they filled empty space.

If a component cannot answer “what do I do with this in under a second,” it does not belong above the fold.

## Freshness beats completeness

Data-heavy UIs tempt teams into completeness theater: every field from every feed, every Greek, every print. Completeness is expensive. Freshness is the contract.

Quotes, chain updates, and flow prints do not degrade gracefully in the user’s head. They either feel live or they feel wrong. We stopped optimizing for “all columns available” and started optimizing for “the critical path never lies.”

Practical rules we kept:

- Separate **decision data** from **archive data**. Last, bid/ask, size, IV, and key strikes stay hot. Historical footnotes can wait. - Show explicit staleness. A quiet “as of” or degraded badge is better than a smooth UI fed by a dead socket. - Prefer partial honest states over spinners that block the whole board. A chain can render the ATM wing first and fill wings after. A flow tape can append while filters catch up. - Never mix delayed and realtime values in the same visual language without labeling. Mixed latency is how people take bad size.

When feeds disagree, the UI should pick a source of truth and surface the conflict, not average it away.

## Layout should survive stress, not just demos

Demos happen on wide monitors with calm hands. Real use happens on laptop screens, second monitors, and days when three alerts fire at once.

We rebuilt multi-panel charting after static mock layouts failed contact with real tickers. Editable panels, ticker search per pane, and local persistence mattered more than a perfect default grid. People rearrange when the market rearranges their priorities.

Lessons that transferred beyond APEX:

- **Collapse, don’t hide.** Secondary stats should compress into chips or drawers, not vanish behind mystery icons. - **Keyboard and click parity on the hot path.** Symbol switch, timeframe, and order ticket focus need to be fast without hunting. - **Preserve scroll and selection.** Losing your place in an options chain after a minor re-render is a trust hit. - **Design empty and error states with the same density budget as success states.** A blank panel in a terminal reads as outage.

If the layout only works when every request returns 200, it is not a trading layout.

## Tables need product rules, not just virtualization

Options chains and flow tables are where front-end craft shows. Virtualization helps, but product rules matter more.

We found that traders do not want infinite columns. They want a stable skeleton: strike, bid/ask, size, IV, delta, then progressive disclosure for the rest. Column presets beat column pickers during open outcry-style moments.

For flow and prints:

- Default sorts should match intent (recency or premium), not an internal ID. - Filters must be visible as applied state. Silent filters create “where did the data go” support tickets. - Color should encode one job—side, urgency, or unusual size—not three jobs at once.

Performance work followed the same hierarchy: reduce row work first, then paint work, then network chatter. A beautiful cell formatter that runs on every scroll frame will lose to a plainer cell that stays smooth.

## AI belongs beside the board, not on top of it

APEX includes briefing and an assistant layer. The useful version never replaced the tape. It annotated it.

Data-heavy products fail when AI becomes another dashboard competing for attention. They work when AI shortens the path to a human check: summarize overnight moves, point at unusual flow against open interest, draft a watchlist rationale the user can verify on the chart.

Our bar became simple: every generated sentence should point back to a number, a timestamp, or a screen the user can open. If it cannot be checked, it does not ship near execution views.

## What we carry into other products

The same patterns show up in Mahon CRM pipelines, Talon research views, and ops consoles inside EAS. The domain changes. The constraints do not.

1. **Define the two-second question** for each screen before adding widgets. 2. **Budget latency and density** like product requirements, not polish. 3. **Make degradation visible** so operators trust the surface under partial failure. 4. **Persist user layout choices**; experts customize under pressure. 5. **Put explanation next to evidence**, never instead of it.

We still catch ourselves overloading a view when a new feed comes online. The fix is the same every time: remove until the scan path returns, then add back only what changes a decision.

If you are building a terminal, an ops board, or any UI where numbers move faster than meetings, we are always interested in the failure cases—the screen that looked right in staging and fell apart at 9:35. Those are the details worth trading notes on.

Questions about this? Want to discuss your project?

Book a free scoping call →