MegaTrader · Simulated trading platform

MegaTrader · Simulated trading platform

Process

The process started from the client's wireframes as the structural base. Without UX involvement, the focus was on building the design system from foundations and designing the most complex components, especially the plan configurator, with multiple interdependent variables.

Client wireframes
Foundations first
Industry conventions
Complex configurator
Development handoff

MegaTrader's user is a real trader who uses the simulator to practice strategies without risking money. This is not a user who needs trading explained to them, they already know it. What they need is for the platform not to put obstacles in their way: data where they expect it, sector visual conventions respected and the account configuration flow clear and unambiguous. Visual trust is critical in fintech, a design that doesn't convey solidity and professionalism loses the user before they even try the product.

Two flows concentrated the greatest design complexity. The first: the account configurator, selecting the trading type, third-party platform, amount to invest, refund percentage and takeout. Each variable had its own options and restrictions, and the possible combinations were numerous. The challenge was for the user to understand at all times what they were choosing and what the implications of each decision were. The second: metrics and objectives visualisation, the trader being able to read their performance at a glance, with clear visual hierarchy between the main metric and secondary data.

The project scope did not include redefining UX flows, the client's wireframes were the working base. Exploration happened within the boundaries of the design system: how to visually represent the configurator's complexity without overwhelming the user. The first approach to the configurator was a linear step-by-step form. It was discarded because it fragmented the process too much and the user lost the global vision of what they were configuring. The solution was clear widgets with visual emphasis on key decision elements, grouping related variables so the user could see the whole before confirming.

Design decisions

Industry conventions as a starting point, not a limitation. The design system was built so the trader felt on familiar ground from the very first moment, and so the development team could implement it without ambiguity.

Dark mode
Semantic green / red
Monospaced typography
Configuration widgets
Metrics hierarchy
Design tokens

Industry conventions as a trust language

In fintech, visual conventions are not optional, they are part of the language the user already knows and expects. Dark background, green for rises, red for falls, monospaced typography for numerical data. Following those conventions was a client requirement and a correct product decision: an experienced trader who opens the platform and doesn't recognise the visual patterns loses trust immediately. Visual innovation in this project was not about breaking conventions but about executing them with a coherent, well-built system, something that existing trading platforms rarely have.

Clear widgets for a multi-variable configurator

The account configurator was the most complex component in the project: trading type, third-party platform, investment amount, refund percentage and takeout, each variable with its own options and restrictions. The solution was to design widgets with single responsibility, visual emphasis on key decision elements and grouping of related variables. The user sees the full picture of their configuration before confirming, without having to remember what they chose in previous steps. Each widget communicates its state unequivocally, selected, available, not available, without needing additional explanatory text.

Visual metrics hierarchy, the important thing first

A trading dashboard can display dozens of metrics simultaneously. Without hierarchy, everything competes for attention and nothing wins it. The decision was to establish three levels of visual hierarchy: primary metric with maximum visual weight, secondary metrics at an intermediate level, and context data at a third level almost invisible until the user looks for it. That hierarchy was implemented through typographic size, weight and colour, never through unnecessary decoration that would add noise to the dashboard.

A design system built for handoff, not just for design

MegaTrader's design system had to be implemented by an external development team. That conditioned how components were documented in Figma: each component with its explicit variants and states, colour and typography tokens named with technical criteria, and behaviour annotations for cases that a static capture couldn't convey. A system designed only to look good in Figma is useless if the development team interprets it differently for each component.

MegaTrader's visual system follows established fintech sector conventions: dark mode as the base, reduced colour palette with green and red reserved exclusively for market semantics, monospaced typography for numerical data and sans-serif for copy and interface. Design tokens were organised so any future brand change could be applied by modifying the token layer without touching components.

The account configurator generated the most complex edge cases: variable combinations not available depending on the selected trading type, disabled widget states with clear communication of the reason, and real-time validations that guided the user without blocking the flow. Each state, available, selected, disabled, error, had its explicit visual representation in the component system.

Design → code

The design system was delivered to the client's development team with components, variants, states and tokens documented in Figma. The platform reached production and was active for six months.

External development handoff
Documented tokens
Variants and states
Figma as source of truth
Implemented in production

The component architecture in Figma followed a two-level structure. The first level is foundations: colour tokens (primitive and semantic), typography (sans-serif for interface, monospaced for numerical data), spacing and base states. The second level is components: each with its explicit variants (size, state, usage context) and behaviour annotations. Configurator components received special attention, each widget documented with all its possible states: available, selected, disabled due to plan restriction, disabled due to incompatibility with another selection. The goal was for the development team not to have to make any visual decisions on their own.

The project reached production and was active for six months. During that time, the implementation revealed cases the design hadn't fully anticipated, configurator variable combinations that in production generated intermediate states not covered in Figma. Those cases required going back to the system and adding additional variants. It is the most direct validation that a design system is never finished, it is only up to date or out of date. The platform stopped operating for financial reasons unrelated to the product, not due to design or implementation problems.

Tokens followed a technical naming convention designed for the development team to consume directly. Primitive tokens with raw values: color-green-500, color-red-400, font-mono-md: and semantic tokens with usage meaning: color-market-up, color-market-down, font-data-primary. The separation between primitive and semantic tokens allowed changing brand values without affecting the semantic logic of components. The development team could map each token directly to a CSS variable without ambiguity.

The handoff was carried out entirely from Figma. Each component delivered with its variants, states and tokens named with technical criteria. Behaviour annotations covered cases that a static capture couldn't convey, especially in the configurator, where restrictions between variables required explicit documentation of which states were possible in each combination. The goal of the handoff was not for the developer to interpret the design but to implement it without having to ask.