Product Design · UX Strategy · Fintech
Designing clarity in a complex financial system.
White-label trading and portfolio review platform for brokerage firms. My work was to define which question each module answers and design the hierarchy that supports that answer without blocking operations.
Test expired
Retake it to resume trading.
$ 12.458.320,50
+2,34% (+$ 284.120,00)
Context
The product already had the right information. What was missing was a reading architecture that helped interpret it.
Virtual Broker is a white-label frontend prototype for brokerage firms, focused on trading and portfolio review. It supports differentiated roles (investor, producer, and configurator) and includes a demo accessible from the investor view.
When reviewing the domain, the problem was not missing data. It was overlap: portfolio, balances, movements, settled amounts, pending settlement, futures, and trading flows coexisted without a clear priority rule. Each concept is legitimate; risk appears when they all compete at the same visual level.
That turns design work into something closer to modeling comprehension than decorating screens. Before defining components, I needed to answer: what does someone need to understand right now? What can wait? Which action is critical now?
The challenge
There was a structural tension: the domain demands precision and density, but everyday reading demands speed. If hierarchy fails, the user misreads a number, and in finance that is not a cosmetic detail.
What was at stake
- Mixing settled and pending settlement as if they were the same
- Forcing the user to rebuild context before every trade
- Treating business alerts (expired profile, contracts) as system errors
- Designing each module in isolation and losing consistency across sessions
Questions the experience needed to support
- What is my current position?
- Which part is already settled and which is still pending?
- Which movements occurred and in what state are they?
- Which instrument am I viewing and what distinguishes it from others?
- What changes if I execute this trade?
- What information needs attention now (expired test, contracts, activation)?
Design constraints
- Maintain precision in figures and states
- Support data density in financial tables
- Work across screen sizes without losing hierarchy
- Avoid ambiguity between temporally distinct values
- Maintain consistency across modules (portfolio, details, trade)
- Allow critical actions without losing prior context
How we framed the problem
I did not start with aesthetics or components. I started with questions. Each product module needed a dominant question; everything else was subordinate or lived in another context.
Principle
One question per screen
Home answers "How am I doing?" Portfolio answers "What is my holdings composition?" Movements answers "What happened?" Trade answers "What am I about to execute?" If a screen tries to answer two primary questions, hierarchy breaks.
Principle
Hierarchy communicates the model
I did not treat the UI as a neutral container. Where data sits (top or bottom, large or small, alone or grouped) is part of its meaning. Total on top, breakdown below; state as a badge, not a footnote.
Principle
Design states, not just happy paths
Operational blocks, pending activation, empty tables, and sensitive confirmations are part of the real product. Designing them later turns business constraints into confusing friction.
Principle
System before exception
When a pattern worked (detail drawer, state badge, summary card), I extended it to other modules. When an instrument required an exception (futures filters, settled-only toggle), I documented it as a conscious variation, not a patch.
Problems we worked through
Problem
The user saw many numbers but did not know which mattered first.
Thinking
I separated position reading (total + change) from composition reading (tabs, tables, drawers). Each layer answers a different moment in the session.
Resolution
Home and portfolio with explicit hierarchy: dominant total, breakdown and detail at secondary levels.
Problem
Settled and pending settlement could read as duplicates or interchangeable.
Thinking
I treated temporal states as an information category, not as extra columns. Explicit naming, nesting under balance, and consistent columns in futures.
Resolution
Visual model where total, settled, and pending settlement have distinct, recognizable roles.
Problem
Trading required remembering data seen on another screen.
Thinking
The confirmation step is not bureaucracy: it is the moment to reduce error. I recontextualized instrument, amount, risk, and acceptance in one place.
Resolution
Trading flow with concentrated review, contextual declaration, and defined loading and block states.
Problem
Account restrictions felt like system failures.
Thinking
An operational block needs to explain what is missing, why it exists, and how to resolve it without permanently interrupting financial reading.
Resolution
Alerts and modals with business copy, clear CTA, and hierarchy subordinate to main content.
Understanding the information model
The first problem was not visual. It was deciding which concepts should coexist, which needed separation, and which information should dominate each context.
Layers derived from the actual investor menu structure, portfolio modules, and instruments.
Designing hierarchy
Problem
Showing all values with the same visual weight forced the user to interpret structure before interpreting data.
Decision
I established a hierarchy where the main total dominates first reading (account or portfolio summary) and breakdowns (settled, pending settlement, available) complete context at a secondary, visually subordinate level.
Trade-off
Explicit hierarchy
Stronger hierarchy means explicitly deciding which information loses prominence. Some relevant data moves to drawers, tabs, or secondary rows.
Home as an orientation point
What does someone need to know first when they enter their account?
The Home module is not a generic summary. It works as an orientation point: account total, change, access to fund flows, and signals that require action (expired investor test, contracts pending signature).
Hierarchy prioritizes total value and its change. Frequent actions (deposit funds, withdraw funds, report deposit, offset portfolio) stay within reach without competing with primary reading. Contextual alerts appear when there are operational blocks, with clear CTAs and dismiss option.
On mobile, the same content reorganizes into action grids and stacked cards, keeping the total as the first reading element.
Test expired
Retake it to resume trading.
$ 12.458.320,50
+2,34% (+$ 284.120,00)
Position, portfolio, and context
$ 8.942.150,00
+1,82%
| Symbol | Quantity | Amount |
|---|---|---|
| AL30 | 1.200 | $ 342.000,00 |
| GGAL | 500 | $ 218.500,00 |
The Portfolio view answers another question: how is my holdings composition structured. The portfolio summary shows aggregate value and its change; below, the instruments section breaks down investments, balances, repo agreements, and futures/options in differentiated tabs.
An isolated figure says little. The challenge was keeping the main result visible without disconnecting it from composition: distribution by asset type, balances by currency with drill-down to detail, and instrument tables with settled and pending settlement columns where applicable.
The balance detail drawer extends reading without leaving context: available, in collateral, and settlement breakdown when relevant.
Designing temporal states
In balances and instruments, settled, pending settlement, and total do not represent the same moment. The experience needed to prevent users from interpreting them as interchangeable equivalents.
The decision was threefold: explicit naming (no ambiguous abbreviations on desktop), hierarchical proximity (settled and pending settlement nested under balance or main row), and column consistency in futures and options tables.
On mobile, dense tables resolve with expandable rows that keep total visible and reveal breakdown on demand.
| Ticker | Position | Settled | Pending settlement | Amount |
|---|---|---|---|---|
| DLR/ENE25 | 10 | $ 45.200,00 | $ 12.800,00 | $ 58.000,00 |
| SOJ/ABR25 | 5 | $ 32.100,00 | $ 8.400,00 | $ 40.500,00 |
Movements: density without noise
The movements view organizes historical activity in three tabs (cash, instruments, and activity) with sortable table, persistent column selector, date filters, and search.
A historical view needs enough density to be useful, but too much information destroys the ability to spot relevant events. I prioritized right-aligned numbers, semantic state badges (pending, available, approved, rejected), and detail drawer to go deeper without saturating the table.
- Tabs by movement type
- Column sorting
- Persistent column selector
- Date range filter
- Search and export
- Detail drawer per row
| Settlement | Concept | Amount | Status |
|---|---|---|---|
| 12/03/25 | Buy | -$ 28.500,00 | AVAILABLE |
| 10/03/25 | Transfer | +$ 150.000,00 | PENDING |
| 08/03/25 | Income | +$ 4.200,00 | APPROVED |
Futures and complex instruments
The Futures/Options module groups four sub-tabs confirmed in the product: A3 Futures, A3 Options, Other futures, and Other options. Each shares table patterns (ticker, position, settled, pending settlement, last price, amount) but with its own categories and filters (financial, agricultural, commodities).
Reusing components does not mean treating all instruments as identical. I kept headers and columns consistent to aid recognition, but preserved specific filters, groupings, and toggles (such as "Settled only" in detailed view, where the instrument required it).
Designing critical actions
The trade flow moves through category selection, instrument, order configuration, and confirmation. The more sensitive an action, the less it should depend on the user remembering information from a previous screen.
The confirmation step concentrates trade data, contextual risk declaration by instrument type, acceptance checkbox, and confirmation CTA with loading state. In producer mode, the flow extends to client selection, assignment, and batch review.
When the investor profile is expired, OperarBlockedModal intercepts the action with explanation and CTA to renew: a restricted state that communicates a business constraint, not a system error.
Account activation
Activate your crypto account
Your crypto account is ready to activate. Accept the terms to start trading.
Activate accountThe crypto module introduces a two-step activation flow: feature announcement and confirmation with terms acceptance. The user can understand the product before trading in that market.
A restricted state should not feel like an error. The modal communicates what is missing, why the restriction exists, and what the next step is (activate account) with explicit terms validation before confirming.
In-product communication
The configurator includes popup management and user-targeted communications. In the investor interface, alerts such as expired test or pending contracts compete with financial information.
In an already dense interface, every additional message competes with data that can have financial impact. Alerts use the same card language as the system, primary orange CTA, direct copy, and dismiss option to avoid permanently blocking primary reading.
You have contracts to sign
Sign them to keep your products up to date.
Main financial content continues below the alert
Designing a system, not screens
The product includes design system documentation (semantic colors, Inter typography, WidgetCard, StatusBadge, drawers, modals, tables, and feedback patterns) that supports consistency across modules.
Consistency mattered because the user alternates between portfolio reading, movement review, and trade execution in the same session. Recognizing a state badge, drawer, or primary button reduces cognitive friction between different contexts.
- WidgetCard for content grouping
- StatusBadge for movement and order states
- Side drawers for detail without navigation
- Modals for blocked actions or confirmations
- DecimalText for figures with typographic hierarchy
- EmptyStateBanner for informative empty states
WidgetCard
Module grouping
StatusBadge
Semantic states
DecimalText
Hierarchical figures
Drawer
Detail without navigation
Responsive and density
Responsive did not mean making the desktop version narrower. It meant redefining which information should remain visible in each context.
In financial tables, mobile prioritizes essential columns and expands detail in the row. Trade drawers go full screen on mobile. The side menu becomes a header with item navigation. Figures keep integer and decimal split for legibility at reduced sizes.
Trade-offs
Trade-off
More information vs. more comprehension
Showing settled, pending settlement, and total in the same view reduces navigation but increases cognitive load. The solution was visual hierarchy and nesting, not data removal.
Trade-off
Consistency vs. specificity
A3 Futures and other futures share table structure, but category filters and the "Settled only" toggle respond to distinct instrument needs. A shared system scales; specialization avoids losing nuance.
Trade-off
Density vs. scannability
Movement tables need volume to be useful. Column selector, sorting, and state badges let users reduce noise without the product imposing a single view.
Trade-off
Simplicity vs. precision
Collapsing settled and pending settlement into one number would simplify the UI but erase a distinction the financial domain requires. I kept both with explicit naming.
Impact
This is a prototype without production product metrics. The impact I can support is design impact: what was resolved in the experience, which decisions were documented, and what foundation was ready to scale.
If adoption data, operational errors, or task times become available in the future, this section can be complemented with quantitative evidence. Today the value of the work lies in model clarity and state coverage.
Deliverable
Applied information model
Five layers (state, activity, instruments, temporality, and actions) translated into navigation, hierarchy, and visual patterns across investor, producer, and configurator.
Deliverable
Critical flows with defined states
Trade, confirmation, profile block, account activation, and in-app alerts have complete journeys: not just the happy path, but restriction, loading, error, and dismiss.
Deliverable
Reusable pattern system
WidgetCard, badges, drawers, DecimalText, and empty states documented in /design-system, reducing improvisation when adding modules such as crypto or new instruments.
Deliverable
Financial density without sacrificing scan
Movement and futures tables with configurable columns, sorting, and numeric hierarchy, useful for users who need volume without losing the ability to spot a relevant state.
Deliverable
Coherent responsive foundation
The same dominant question per module holds on mobile; density changes, not the mental model. Full-screen drawers, expandable rows, and action grids adapted by breakpoint.
Deliverable
Less ambiguity between financial concepts
Settled, pending settlement, available, and in collateral stopped competing visually. That does not remove domain complexity, but it reduces the risk of incorrect interpretation.
For the team
- Shared language between design, product, and engineering to discuss hierarchy and states
- Less rework when extending modules: the pattern exists before the new feature
- Navigable prototype that allows validating flows before development investment
Reflections
Learning
Simplicity is not about showing less
In financial products, removing information produces a visually clean but conceptually incomplete experience. Clarity comes from hierarchy, not emptiness.
Learning
Hierarchy is part of the model
Where data appears communicates its importance and relationship to others. Total on top, breakdown below; state as badge, not loose text.
Learning
States need context
Settled next to pending settlement only works if the user understands they are distinct moments. Naming and proximity matter as much as the number.
Learning
Consistency has limits
A shared system helps scale, but futures, options, and local currency balances should not be forced into an abstraction that erases operational differences.
Learning
Designing actions means designing consequences
Confirming a trade requires recontextualizing the decision: what is being traded, under what conditions, and what the user accepts by proceeding.
The design was developed iteratively on the existing prototype: flow mapping, financial domain constraints, product requirements, and internal feedback. There was no formal access to end users at this stage; decisions were validated against model coherence, technical feasibility, and reading clarity.
Más proyectos
B2B • Marketplaces • SaaS / management tools
Designing the flow that turns campaigns and applications into collaborations
Campaign live, applications in, creator still to pick. I bridged brand and creator without losing context until collaboration starts.
Mass-market products • Own projects
Turning fragmented local information into a scalable discovery product
Scattered local data slowed lodge discovery. I structured filters, trust, and content so the product could scale through organic search too.