FOMOED - Trading Dashboard
Designing a High-Velocity Decision Environment Through Product, Service, and Interface Precision
Industry
Web3
Role
Product Designer
I led the redesign of FOMOED dashboard. FOMOED is a trading platform where users operate under time pressure, financial exposure, and constant data movement. Execution speed and clarity directly affect outcomes.
The existing interface created friction in decision-making, particularly during volatile conditions.
Summary
This was a shift from a data-heavy dashboard to a decision system designed for clarity, speed, and reliability under pressure.
Problems
Trading platforms are cognitive workspaces. Users operate under time pressure, financial exposure, and constant data movement. In this environment, interface structure directly affects decision quality.
Research and workflow analysis exposed 4 tensions:
Information Density vs Comprehension
Depth is necessary, but visual competition slows interpretation.
Real-Time Expectations
Interfaces must feel stable despite volatile inputs.
Signal vs Noise
Without hierarchy, critical data can get lost in the noise.
Attention Economics
Traders scan, not read. Layout governs perception speed.
TEAM
Product, engineering, QA, and trading stakeholders
Approach
The dashboard was treated as a frontstage layer of a live ecosystem
Market data ingestion
Execution engines
Latency handling
Risk calculations
Portfolio synchronization
Failure and recovery logic
I mapped the service blueprint end-to-end to ensure UI states always reflected system truth. No visual feedback existed without backend alignment. This was foundational to trust.
Design Principles
Elements were evaluated by decision value, not aesthetics.
Hierarchy as Risk Management
Action-critical signals dominated; secondary data receded.
UI Detail as Functional Infrastructure
Spacing, typography, and contrast were treated as performance tools.
Deterministic State Communication
Every system state used explicit, consistent visual language.
Information Architecture Strategy
Data was organized by decision relevance, allowing users to interpret market conditions without unnecessary attention switching. The dashboard evolved into an attention management system — supporting rapid parsing while preserving depth. Reducing noise was not about minimalism.
Key decisions
Removed non-essential data from primary views to improve decision speed
Prioritised execution clarity over interface flexibility
Aligned all UI states with backend behaviour to eliminate uncertainty
Research-Driven Structure
We examined how traders scan information, how attention shifts under volatility, and how hierarchy influences reaction time. Prototype simulations with live-like data allowed us to observe hesitation patterns and cognitive friction.
Hierarchy changes were validated by reductions in decision latency.
Componentized Dashboard
A modular framework replaced rigid layouts. Panels, widgets, and indicators functioned as reusable primitives governed by consistent spatial logic, interaction rules, and state behavior.
Micro-level UI decisions — alignment, typography scale, contrast hierarchy, motion restraint — were treated as performance considerations. Collectively, these refinements reduced visual friction and improved interface trustworthiness.
Trade-offs
Reducing visible data limited flexibility for advanced users. This was accepted to improve clarity and execution speed in high-pressure scenarios. Depth was deferred to secondary layers.
OUTCOME
The redesigned FOMOED dashboard improved decision readability, reduced attention conflicts, and increased interaction predictability. Users could interpret signals faster, while consistent system feedback reinforced trust during execution.
The most important shift was behavioural.
Behavioural impacT
Before:
Users paused to interpret competing signals.
Execution decisions were delayed by ambiguity.
Traders relied on external tools to validate actions.
After:
Faster and more consistent execution patterns.
Reduced reliance on secondary validation.
Increased confidence in acting during volatility.
What I would improve
Introduce measurable tracking of execution time and error rates
Test behaviour under extreme market volatility scenarios
Adapt interface density based on user expertise