Enter Password
Cryptio
My Role
Solo designer working across 3 squads.
End to end discovery , design & delivery support.
MVP & phased delivery definition.
Design system contribution.
The Team
Deliverables
Timeframe
2 months | 2025
Problem
It was clear the dashboard had usability issues — but a cleaner UI alone wouldn’t make it a product teams could trust or sell.
Treasury users weren’t blocked by interface friction — they were blocked by an inability to make confident decisions.
To create real value, the design needed to focus less on polish and more on purpose.
Approach
I analysed support tickets, interviews, and competitor benchmarks to understand what decisions users were trying to make.
Four key questions emerged:
What do I hold? Where is it held? How is it performing? What risk am I exposed to?
These became the design principles that guided structure, content, and prioritisation across the product.
Outcome
I rapidly prototyped early dashboard concepts using Replit, focused on bringing the four core questions to life.
This allowed me to test ideas quickly, gather targeted feedback, and start validating which patterns best supported decision-making — long before high-fidelity design began.
Problem
The dashboard showed asset and wallet data, but the relationships between them were opaque.
Users couldn’t easily trace which assets were held where, which wallets belonged to which clients, or what data was sourced on-chain versus manually imported.
This lack of structure blocked meaningful investigation — the product showed what was happening, but not why or where to act.
Approach
To design for clarity and action, I stepped back to map the underlying object relationships: assets, wallets, sources, and client ownership.
I collaborated with backend engineers and finance stakeholders to understand how these entities were stored, joined, and displayed.
I then tested these models against real-world user behaviours — tracing example portfolios through the system to uncover where expectations broke down.
From this, I defined a navigational and data structure that aligned with how treasury teams actually think and work: from high-level views, to drilldowns, to individual actions.
Outcome
The result was a shared design model built around a simple principle: Surface → Drill Down → Act.
This shaped the dashboard’s structure — from filters and grouping to drill-in logic and contextual metadata.
It enabled users to move seamlessly from an overview of their portfolio, into wallet- or asset-level views, and ultimately to the decisions that mattered — with clarity and trust at every step.
Problem
The dashboard showed current balances — but nothing about how those assets had performed over time.
There was no way to track historical value, realised gains, or shifts in portfolio allocation.
To understand performance, users had to export data or rely on external reports — a slow, manual process that undermined the product’s value as a decision-making tool.
Approach
I collected a set of reports that customers relied on to assess performance outside the app.
By analysing the structure, language, and metrics in these reports, I identified the key signals treasury teams cared about: historical valuations, P&L on disposal, and performance by token or wallet over time.
This helped me map what “performance” actually meant in practice — and how it could be surfaced directly in the interface.
Outcome
This work provided a concrete foundation for designing performance insights into the dashboard.
It clarified which metrics mattered, which needed context, and where historical comparisons would add value.
It also helped align teams around a shared definition of performance — turning a vague need into a clear, actionable feature set.
Problem
The dashboard showed live on-chain data — accurate, but lacking critical off-chain context like manual transactions or adjusted cost bases. For treasury teams, this meant balances often didn’t match internal reports. The result was confusion, mistrust, and a reliance on external tools to validate what the interface couldn’t fully explain.
Approach
Users repeatedly flagged mismatches between dashboard figures and internal reports. To investigate, I partnered with engineers to trace how data was being sourced and surfaced. This revealed that the dashboard relied solely on live on-chain data, omitting any off-chain adjustments or manual imports — the root cause of the confusion.
Outcome
To rebuild trust, I created content and interface guidance that helped users interpret what the dashboard was showing.
This included plain-language explanations, contextual tooltips, and source-level labels to clarify whether data was on-chain, imported, or adjusted.
A Framework That Scaled Beyond Design
The dashboard shipped with a structured model for supporting institutional decision-making — driven by the Surface → Drill Down → Act framework and anchored in the four core user questions identified during research. This model not only shaped the interface, but also aligned cross-functional teams on what the product needed to support: not just visibility, but clarity, traceability, and action. While adoption metrics are still emerging, the work has already shifted internal conversations — from surfacing data to supporting decisions — and laid the foundation for upcoming features in risk analysis, reconciliation, and audit readiness.
Insight: Trust Is a Product Experience Problem
One of the most valuable insights was that trust in data isn’t just a technical issue — it’s a product experience problem. Users needed to understand what they were looking at, where it came from, and whether it reflected operational truth. By bridging the gap between raw on-chain inputs and real-world accounting needs, the design work helped position the dashboard as more than a reporting layer — it became a strategic enabler for the finance teams using it.
What’s Next
Looking ahead, we’ll be monitoring adoption among priority institutional clients and gathering feedback on how users interpret performance and provenance cues. The core model is already being explored for other modules, and there’s an opportunity to build on this foundation with alerting, forecasting, and higher-order decision support in future releases.