Trading Design

Anti-Patterns:

Density First

Default compact, scale up only for readability. Every element must earn its screen space.

• Pixel accountability — decorative elements (gradients, shadows, rounded corners, excessive padding) must justify themselves against the data they displace
• Simultaneous visibility — a panel that requires scrolling to show its core content has failed
• Compact ≠ cramped — 4px base unit with consistent multiples creates rhythm even at tight spacing

Benchmarks:

Hierarchy through density:

• Primary data (price, P&L) — slightly larger, full opacity, prominent position
• Secondary data (labels, quantities, timestamps) — standard density, reduced opacity
• Tertiary data (metadata, IDs) — smallest size, lowest opacity

Signal Through Noise

The signal is price action, position state, and order status. Everything else is noise.

High-value attention spend:

• Directional color on P&L and price changes
• Stale data indicators
• Error and disconnect states
• Direction icons alongside color (redundant encoding)

Minimize or eliminate:

• Decorative borders (1px at low opacity is enough)
• Box shadows (near-black elevation handles depth)
• Animated transitions (instant state changes are faster to process)
• Color-coded categories that aren't directional

State communication — must be obvious without searching:

Animation: Use only when it communicates information otherwise missed. Brief flash on price tick — acceptable. Panel slide-in transitions — not acceptable. Transitions under 100ms.

Visual Language

Two-Hue Directional Color

Exactly two chromatic hues: one for positive direction (buy/bid/profit/long), one for negative (sell/ask/loss/short). All other visual variation from a single neutral at graduated opacities. No blue, orange, yellow, purple in the base palette.

Neutral variation:

When you need a third color:

1. Prefer neutral treatment first — opacity, icons, or position instead of a new hue
2. If truly needed — low saturation, never confused with directional color
3. One additional hue total, not one per semantic

Opacity as Primary Visual Variable

Opacity is the primary tool for hierarchy, state, and depth. Not new colors.

Directional hue variants:

If reaching for a new color value — stop. Can this be achieved with an opacity variant? If yes, use opacity. A new color in the palette is an architectural change.

Surface and Elevation

The default canvas is near-black (3-6% brightness, not pure #000000). Data is the brightest thing on screen. Depth comes from a structured elevation system — not shadows, not gradients.

Elevation ladder (5 levels):

Elevation in context:

Principles:

• Every background maps to one of these five levels — no custom backgrounds
• No shadows — elevation through brightness
• No gradients on surfaces
• Borders at low-opacity neutral (8-15%) where brightness alone isn't enough

Borders: Use the neutral at very low opacity rather than a distinct border color. Borders define panel boundaries without drawing attention.

Theming beyond dark:

• Use established community palettes only — Tokyo Night, Catppuccin, Dracula, Nord, Solarized, Rosé Pine, Gruvbox, One Dark
• Light mode is a supported variant — elevation principles apply in reverse
• All rules still apply regardless of palette: two directional hues, opacity-based variation, density-first
• Dark is the design target — design and test dark first, other themes are adaptations
• Theme switching changes only token values, never layout, density, or information architecture

Typography & Density

Dual-Font System

Two font categories. No exceptions. No third font.

The monospace font must support tabular figures (all digits same width), lining figures (baseline-aligned), and clear zero/O distinction at 11px. Recommended: JetBrains Mono, IBM Plex Mono, Iosevka, Berkeley Mono, Cascadia Code.

The boundary — where sans meets mono:

Rule: if it contains a number the user needs to compare or scan, it's monospace.

Data Alignment and Size Hierarchy

Decimal alignment — the single most important typographic rule for trading data. In any numeric column, decimal points must align vertically.

Implementation: right-align numeric columns with consistent decimal places, use tabular figures, pad with non-breaking spaces if needed.

Size hierarchy:

Column layout:

• Right-align all numeric data
• Left-align text data (symbols, names, labels)
• Fixed column widths — columns must not resize when data changes
• Header alignment matches data alignment

Semantic Token Architecture

No component should contain a raw color value, pixel measurement, or font specification. All visual properties reference semantic tokens.

Naming — by semantic role, not appearance:

In code review, any hardcoded color value, pixel measurement, or font name in component code is a defect. The only place raw values should exist is in the design system's token definition file.

Layout & Panels

Panel Architecture and Docking

Professional trading interfaces are modular panel systems, not page layouts.

• Tiling, not floating — panels tile to fill available space with no gaps
• Priority-based space allocation — the chart gets remaining space after other panels claim minimums
• Defined minimums — every panel has a minimum useful size; below it, the panel collapses
• User-controlled layout — layout state is saved and restored reliably

Panel priority ordering:

Collapsed panels show compact indicators with key counts (e.g., "Orders (3)").

Shell structure:

1. Header bar (fixed, 24-32px) — symbol, account, connection status, global controls
2. Content area (flexible) — dockable panel grid
3. Status bar (fixed, 24-32px) — system status, latency, clock

Panel internal structure:

1. Panel header (20-28px) — title, actions, collapse/close
2. Panel content — primary function
3. Panel footer (optional) — summary data

Required Panel States

Every panel must implement all five states:

Disconnected state requires special attention:

• All data visible but at reduced opacity
• Stale data warning visible without scrolling — timestamp of last update, reconnection status
• Order entry disabled — cannot submit on stale data
• Order modification/cancellation remains enabled
• Transition from live to disconnected must be instant and obvious

State transitions are immediate. No fade animations between states.

Responsive Collapse Strategy

When viewport shrinks below combined minimums:

1. Collapse lowest-priority panels first into compact indicators
2. Stack remaining panels vertically
3. At smallest viable size, tabbed view — one panel at a time

Rules:

• Chart and order entry never collapse
• Breakpoints defined in design system, not hardcoded
• Collapsed panels show data counts
• Transitions are instant
• User can override collapse priorities

Minimum panel sizes (reference):

Data Display

Trading Data Display Conventions

Price:

• Always monospace, decimal-aligned in columns
• Direction indicator: icon + color (never color alone)
• Show both absolute and percentage change
• Consistent decimal places per instrument

Position:

• Direction badge ("Long"/"Short" in directional color)
• Quantity in monospace, right-aligned
• Entry price in secondary text
• P&L with directional color + icon — most important number in the row
• Row tint at 5-10% opacity of directional color

Order:

• Side indicator with directional color
• All prices and quantities in monospace, right-aligned, decimal-aligned
• Status: pending (neutral), filled (positive flash → neutral), rejected (negative), cancelled (dimmed)
• Cancel action always visible on working orders — no hover required
• Time priority visible in secondary text

P&L:

• Directional color + icon
• Monospace, right-aligned
• Include currency symbol ("$+1,234.56")
• Clearly label realized vs unrealized
• Daily/total toggle

Alerts:

Errors must never auto-dismiss.

General:

• Stale data — gray out with "Last update: HH:MM:SS" timestamp
• Empty columns — show "—" not blank (blank is ambiguous)
• Loading — skeleton for known layouts, spinner for unknown
• Confirmation dialogs for orders above configurable threshold — show side, quantity, symbol, price, estimated cost

Interaction Design

Keyboard-First Interaction

Every critical action must be reachable by keyboard. The mouse is a fallback.

• Every action has a shortcut
• Shortcuts discoverable via tooltips and help overlay (?)
• Focus always visible — high-contrast ring on every interactive element
• Focus order follows visual layout
• Escape always cancels

Trading-specific shortcuts:

Focus management:

• Focus trap in modals
• Return focus on close to triggering element
• Panels have visible "focused" state (subtle border highlight)

Tooltips on every icon-only button: action name + keyboard shortcut. Appear after 300-500ms hover, disappear immediately on leave.

Error Prevention and Confirmation

Confirmation requirements:

Confirmation dialog design:

• Show full details — "Are you sure?" with no context is useless
• Primary button uses directional color (buy = positive, sell = negative)
• Cancel always available and keyboard-accessible
• No nested confirmations
• Configurable size thresholds

Prevention over confirmation:

• Quantity validation — reject obviously wrong quantities
• Price validation — warn on limit price far from market
• Symbol verification — highlight mismatch with current chart
• Side verification — emphasize buy vs sell throughout order entry

Recovery:

• Cancel always one action away on every working order
• Undo before exchange submission
• Clear error messages with rejected order details

Component Philosophy

Component Design Approach

Two approaches:

Composed — from existing primitives (text, row, column, button, input). Use for most widgets: PriceDisplay, PositionBadge, PnlDisplay, AlertBanner, NumericStepper, SymbolSearch, StatusIndicator.

Custom-rendered — canvas, WebGL, GPU primitives. Use only for performance-critical visualization: charts, DOM/order book with high-frequency updates, heatmaps, volume profiles.

Threshold: if composed maintains 60fps with your data volume, use composition.

ShadCN model compressed for trading:

Standard trading widgets:

Component checklist:

• All visual values from semantic tokens
• Numeric data in monospace with tabular figures
• Directional data has both color and icon/text indicator
• All five panel states handled
• Keyboard accessible with visible focus
• Tooltips on all icon-only elements
• Tested at target density

Accessibility

Accessibility and Cross-Platform

Contrast requirements:

Test every text opacity level. Tertiary/disabled text most likely to fail.

Never color alone — every directional color needs reinforcement:

Focus indicators:

• Every interactive element, visible against dark background and any surface level
• High-contrast color (accent/brand since it's not directional)
• 2px minimum width
• Never remove for aesthetics — restyle if needed

Cross-platform rendering:

• Design at 1x (96 DPI) baseline
• Test at 100%, 125%, 150%, 200% scaling
• Use vector assets — raster blurs at non-integer scales
• Font rendering varies across FreeType/DirectWrite/Core Text — test at 11-13px on all targets
• Custom window chrome must support native window management (snap, resize, minimize)