Valuest · Fintech · Portfolio & Decision Systems
Designing decision workflows for data-dense portfolio environments
ROLE
Product Designer
DATE
2024 — 2025
PLATFORM
Mobile · iOS
The hard part wasn't showing the data — it was deciding what a single decision actually needs to see.
Valuest is a fintech app for evaluating and monitoring portfolios across many assets and time horizons. Each company carried nearly 100 indicators. I led the redesign of its decision workflows — replacing maximum data exposure with a structured financial model that surfaces ~9 decision-critical metrics while keeping full depth one tap away.
Context
Portfolio decisions were spread across screens that never resolved into one view
Valuest is an analysis and monitoring tool, not a trading app — positions are entered manually, so every screen exists to support a decision, not to execute one. In the original flows:
insights required scanning multiple dashboards
comparisons across assets had no shared structure
monitoring was inconsistent from screen to screen
synthesis happened manually, in the user's head
In time-sensitive decisions, this meant slow cycles and high cognitive load.
Positions are logged by hand — Valuest records the transactions you made elsewhere, it doesn't execute them.
Problem framing
The first direction was maximum exposure: surface every indicator. With ~100 per company, that produced overloaded screens, weak hierarchy, and visual noise — friction exactly where speed mattered most. The brief shifted from "what can we show?" to "what does one decision need to see?" — and that reframe drove every move below.
Design
I grouped ~100 raw indicators into three financial statements, each its own focused view
The data provider fed nearly 100 raw indicators per company. I grouped them into the statements analysts already think in — income, balance, cash flow — and gave each group one focused chart: its core metrics as bars, plus a selectable metric overlaid for comparison. ~100 raw indicators in; roughly three per statement on screen, the rest a tap away. Depth preserved, noise removed.
The Income statement — revenue, operating and net income as bars, net margin overlaid. Each financial group gets its own focused view, and the overlay metric is selectable.
Design
Decision-critical metrics stay visible; everything else surfaces on demand
I benchmarked TradingView and Yahoo Finance to read how experts expect density on mobile. In informal sessions with 8 colleagues and contacts, hiding secondary data behind collapsible sections cut clutter but added friction for the experienced ones. Final rule: critical metrics always visible, secondary ones progressive.
News, alerts and per-symbol transactions surface on demand, not by default.
Constraints
The structure had to scale across companies without re-introducing overload
real-time data updates
derived metric calculation (composites on top of raw inputs)
scalable grouping logic
one structure that scales from a single company to the whole portfolio, consistent across every company
The system was built to expand beyond the initial indicator set without collapsing back into noise.
A shared component kit keeps the metric hierarchy consistent across every company.
Outcomes
A scalable dashboard system, shipped to TestFlight before real validation
~100 raw provider indicators → ~9 core surfaced (plus composites)
a clear financial hierarchy, consistent across companies
a structure that scales without re-adding overload
launched on TestFlight; tested informally with 8 colleagues and contacts
It was never measured with real users in production — so time-to-insight and decision clarity are design intent, not proven results.
The shipped system at a glance — one consistent structure across the app.
Reflection
Designing for decisions without usage data forces you to prioritize on principle
With no validated production usage, the only defense against overload was deciding what's decision-critical first, then exposing complexity progressively.
Informal tests caught interaction friction — like the collapsible-sections problem — but couldn't tell me whether my hierarchy matched how traders actually decide. That gap is the open question.
If it resumes, the first move is instrumenting the TestFlight build to test the 3×3×3 model against real usage.