Securities Trading

Building a unified trading experience across crypto and securities

I worked on core trading flows across crypto and traditional securities, including order entry, execution states, and position management. The focus was to create a unified experience across asset classes with different behaviours and risk profiles, while preserving the conventions traders rely on in each market.

Details are presented at a high level due to confidentiality.

Context

AMINA offered clients access to both crypto and traditional securities within the same product. Users expected a consistent trading experience across asset classes, but the underlying behaviours differed meaningfully between markets (e.g., order types, execution expectations, trading hours, and risk conventions).

The project goal was to reduce cognitive load and prevent trading errors by aligning interaction patterns wherever possible, while explicitly preserving asset-specific behaviour where it materially affected user outcomes.

Problem

Trading is a high-stakes environment where users depend on learned behaviours and predictable feedback. Inconsistent interaction patterns across asset classes increases the likelihood of user error, especially when switching between markets.

At the same time, forcing identical patterns across crypto and securities can introduce a different class of risk: removing meaningful market-specific cues and reducing clarity at decision points (e.g., limit/market behaviour, expiry, execution status).

The challenge was to unify core trading interactions across crypto and securities without:

  • increasing error rates or re-learning costs

  • flattening important differences between asset classes

  • reducing clarity around execution and position state

Solution

The approach focused on establishing a shared interaction model across markets, then defining controlled divergence where the underlying market behaviour required it. Rather than redesigning trading screens in isolation, we treated trading as a behavioural system composed of entry, feedback, and state transitions.

1. Defining a shared interaction model

We aligned foundational interaction patterns across markets to reduce relearning and support muscle memory, including:

  • consistent layout and hierarchy for order entry

  • shared terminology where meaning matched across markets

  • predictable placement of key variables (quantity, price, balances, fees where applicable)

The intent was to support fast, repeatable actions without requiring users to re-interpret the interface when switching assets.

Shared structure, with inputs and constraints exposed only where they materially affect execution.

2. Preserving meaningful market-specific behaviour

Where market behaviour differed materially, the UI made those differences explicit rather than hiding them behind uniform controls. This included areas such as:

  • order types and constraints

  • time-based parameters (e.g., expiry)

  • execution expectations and settlement behaviours

This prevented “false consistency”, where identical UI implies identical outcomes.

Example execution state transitions for a cancellable order.

3. Designing execution states as a coherent state machine

We treated execution feedback as a system of states rather than individual screens. States were mapped and normalised to reduce ambiguity and ensure users could answer:

  • Has the order been placed?

  • Is it pending, partially executed, filled, or failed?

  • What action (if any) is required next?

This reduced uncertainty during execution and improved interpretability across markets.

Errors are handled as reversible states, not dead ends.

4. Error prevention and recovery

Because trading errors are costly, we prioritised prevention and clear recovery paths, including:

  • validation and constraint messaging at the point of entry

  • clear, actionable error states aligned to user intent (change vs cancel vs retry)

  • consistent confirmation patterns to reduce mis-taps and misreads

Where possible, error handling was designed to preserve context and avoid forcing users to restart a task.

The same execution states are reflected consistently across in-progress and historical views.

5. Consistency across the full trading loop

Beyond order entry, we ensured that the experience remained coherent across the full trading loop:

  • from order placement → execution feedback → order history

  • from filled order → updated positions → transaction records

This reduced “state confusion” after execution, especially for users managing multiple positions across asset classes.

Constraint and trade-off

A key trade-off was deciding where consistency should yield to market truth.

In several areas, unifying controls would have simplified the surface UI but risked hiding meaningful market differences. In those cases, we prioritised clarity of outcome over visual uniformity, even when it introduced minor divergence in interaction patterns.

The guiding principle was: consistency where it reduces error and relearning, divergence where it prevents misunderstanding.

Design Contributions

  • Owned design of core trading flows across crypto and securities, including order entry, execution feedback, and related state transitions.

  • Defined shared interaction patterns across asset classes to reduce relearning and prevent behavioural errors.

  • Mapped execution states as a coherent system to improve clarity and reduce uncertainty during order placement and fulfilment.

  • Partnered with Product and Engineering to align design decisions with market-specific constraints and backend capabilities.

  • Improved error prevention and recovery patterns to support high-stakes actions without forcing users to restart flows.

  • Ensured end-to-end consistency across the trading loop, from entry through confirmation, execution feedback, and position updates.

  • Owned design of core trading flows across web and mobile, including order entry, execution feedback, and position state transitions for both crypto and traditional securities.

Impact

  • Reduced trading errors when switching between asset classes

  • Improved clarity of execution state and next actions

  • Established a shared interaction model used across subsequent trading features

Learnings

Unifying trading across asset classes is primarily a behavioural design problem. Consistency reduces cognitive load, but over-standardisation can introduce risk if it masks market-specific outcomes.

The most effective approach was to treat trading as a system of decisions and states, and to design consistency around predictable behaviour and feedback — not purely around shared UI components.

© 2025 Rico Smith. All rights reserved.