elo
designing a finance-critical system that scales with accuracy
overview
built to replace manual vigilance with system-led reliability
talking to users made it clear the problem wasn’t tools, but trust
user’s pain points
3. clarity & communication
financial data is scattered and hard to interpret
reports are manual, slow, and inconsistent
non-finance users fear touching the data
1. workflow connection & efficiency
invoices and documents are linked manually
finance is a bottleneck for access and validation
ad-hoc channels cause confusion and duplication
subvisual
client
timeline
10 weeks / 2025
elo is designed to support subvisual’s internal operations across finance, leadership, and delivery teams. Built as part of a structured apprenticeship, the project involved designing an internal product in close collaboration with finance and engineering stakeholders, focusing on creating a shared system that remains reliable as financial complexity and access increase.
product design. ux research. branding
scope of work
fintech. web app
project type
when financial accuracy depends on people, growth becomes a risk
discovery
problem
process
solution
iteration 1
information architecture & terminology
during testing, users couldn’t locate or understand ‘Reference Data’, and high-frequency tasks like projects and cost centres were hidden behind configuration language. This blocked task completion early and created confusion across roles.
the decision to remove ‘reference data’ and replaced it with domain-specific navigation, elevated high-frequency areas to the top level and clarified account-level versus workspace-level settings. This was prioritised because it was a systemic blocker, and fixing it unblocked multiple workflows at once.
after usability testing
after usability testing
this project tackled a common scaling problem in finance-critical systems: accuracy that depends on people rather than the system. At Subvisual, financial workflows worked, but only because errors were manually caught before they compounded.
success criteria weren’t fully defined on day one; they emerged through early discovery and stakeholder conversations. I defined success in terms of outcomes, not features:
accurate reconciliation with less manual oversight
safe access across roles with different financial literacy
reduced cognitive load when reviewing and reporting data
clear visibility into company and project health for leadership
some of these goals were intentionally in tension - particularly simplicity vs finance-heavy workflows and speed vs safety. Designing Elo meant making explicit trade-offs rather than trying to optimise for everything.
develop a desktop financial management app organised around reconciliation as the core principle, structuring workflows to prioritise clarity, review, and control. By embedding safeguards directly into the system, it enables safe cross-role access, reduces reliance on manual oversight, and provides a scalable foundation for finance-critical work.
success
to understand how financial information was managed and shared across roles, I conducted 5 in-depth user interviews with finance, leadership, and engineering stakeholders. Sessions focused on walkthroughs of the company’s existing spreadsheet-based workflows, surfacing where friction, errors, and uncertainty emerged in daily work.
these interviews reinforced that users weren’t asking for better spreadsheets or more automation. they needed a system they could trust, understand, and grow with.
key questions I asked:
how is financial data currently managed and shared across roles?
where do friction, errors, or inefficiencies occur in daily workflows?
how do users access and trust the information they rely on?
what factors influence whether they adopt or abandon financial tools?
2. data accuracy & trust
manual checks lead to cascading errors
inconsistent classifications break data integrity
accuracy depends on individual vigilance
4. system adaptability
current tools can’t flex for crypto or new models
automation fails without clean, consistent data
spreadsheets make scaling fragile and risky
how existing tools failed to support real workflows
define
prioritising a trustworthy foundation over feature breadth
low-effort / high-impact quadrant (MVP focus)
this quadrant became the focus for the MVP, allowing to deliver meaningful value early while protecting the system’s foundation.
feature list grouped by similarity (IA exploration)
this grouping revealed natural relationships between concepts, making it easier to see how the information architecture could take shape and evolve over time.
the site map was the first concrete translation of these decisions into product structure. Navigation was organised around the core financial flow: importing, reviewing, and reconciling data with supporting areas intentionally separated to reduce cognitive load.
high-frequency, high-risk workflows were elevated and made difficult to bypass, while configuration and secondary actions were kept out of the critical path.
in parallel, I mapped dense end-to-end user journeys to surface edge cases, irreversible actions, and risk points. These journeys weren’t designed for visual presentation, but to pressure-test assumptions and validate where guardrails were required.
the outcomes of this work are reflected in the structure and interaction patterns of the designs that followed.
low-fidelity wireframes focused on validating structure and workflows rather than visual detail. Design decisions at this phase were shaped closely by engineering constraints to ensure feasibility and reduce rework later in the process.
moderated, task-based usability testing focused on validating whether users could complete core financial workflows safely and confidently, before investing in visual polish. The goal was to surface structural, terminology, and workflow risks that could undermine reconciliation and trust in a finance-critical system.
testing was conducted with 4 internal participants representing different levels of financial involvement.
testing indicated that core flows were directionally strong and aligned with user mental models, but several high-impact structural issues needed to be resolved for the system to support real operational work.
an analysis of existing financial tools surfaced consistent gaps across the market. While most platforms handled financial data accurately, they were difficult to interpret outside accounting roles. High-frequency workflows such as cost allocation and splitting were often complex, error-prone, and reliant on manual workarounds. Emerging workflows, including wallet transactions and multi-project expense allocation, were poorly supported, forcing teams to stitch together multiple tools.
this analysis clarified what not to build: feature-heavy platforms that increase complexity without addressing how trust, access, and reconciliation are distributed across roles.
effort vs impact matrix (full matrix)
matrix was created collaboratively with engineering to assess feasibility alongside user and business value, helping ground prioritisation decisions in real delivery constraints.
design
designing structure around financial risk, not screens
the sitemap reflects both the MVP focus and the wider product vision. Greyed-out sections indicate features deliberately excluded from the MVP while remaining part of the long-term product scope.
mapping the edge cases before they became failures
end-to-end flows across sign-in, reporting, transactions, invoices, and management.
pressure-testing core workflows through low-fidelity testing
before usability testing
before usability testing
core flows that aligned with users’ mental models
before usability testing
confirming the foundations were strong enough to build on
refining the product to match real financial operations
test
testing reinforced confidence in the product direction
navigation & structure:
core sections (transactions, invoices, projects, dashboard) were easy to locate and aligned with expectations.
iteration 2
editing model misalignment reduces speed & accuracy
users tried to edit data inline, especially in high-volume workflows. The side edit-panel slowed them down and broke momentum.
because of this, I designed for an inline-first editing model for common actions, while keeping the side panel for multi-step or higher-risk changes. This was prioritised because editing speed directly affects accuracy and efficiency, and this approach balanced speed with safety, aligning with the core principles of clarity and control.
iteration 3
split invoice logic
testing showed that the split invoice logic didn’t match real workflows. Because splitting is both high-frequency and high-risk, this misalignment directly affected data accuracy.
i updated the defaults, made amount-first splitting the primary interaction and expanded split dimensions. This was prioritised to reduce manual work and error potential in one of the most critical reconciliation tasks.
after usability testing
while usability testing surfaced important issues to fix, it also validated several foundational decisions. Users confidently navigated between Dashboard, Transactions, and Invoices, and understood the core flow from importing through review and reconciliation. Filtering and reviewing both data aligned with existing mental models.
this validation gave me confidence that the structure and interaction patterns were sound, which made it safe to move forward into visual design without reworking the foundations.
from validated structure to designed experience
branding that reflects the company’s ethos:
fun people doing serious work
once testing validated the underlying structure, the product moved into visual design. The UI was guided by a ‘friendly intelligence’ visual language - professional, calm, and approachable - designed to support collaboration without undermining trust in a finance-critical context.
the final prototype brought together validated decisions across structure, interaction, and visual design, with key refinements after testing, such as enabling exports across cash, crypto, and invoices in a single action to better reflect real reporting workflows.
two moderated high-fidelity usability sessions focused on whether the product could support real financial operations across transactions, invoices, projects, exports, and reporting. Testing was highly positive: users found the interface clean, intuitive, and trustworthy, with core flows aligning well with their mental models and most tasks completed without guidance.
high-fidelity testing confirmed several foundational choices made earlier. These signals confirmed the product was directionally strong and ready for refinement rather than rework.
trust-building workflows:
import - review - confirm flow felt intuitive. The “double-check” moment before saving was perceived as a safeguard.
visual language:
UI was described as simple and fresh - reinforcing trust, differentiating the product from spreadsheets and traditional finance tools
iteration 1:
export clarity
usability testing revealed that export behaviour lacked clear intent, creating uncertainty around what data would actually be shared. Users expected exports to mirror real reporting workflows, including the ability to combine multiple data sources in a single action.
the export flow was restructured around explicit modes and clearer system intent, aligning reporting behaviour with how financial data is used in practice and reducing risk at a critical point of decision-making.
iteration 2:
linking logic: reflecting real finance patterns
usability testing showed that users expected splitting to happen directly on transactions, where they already work, rather than being limited to Invoices, and needed clearer feedback when split amounts didn’t reconcile with the original total.
splitting was moved into the transaction flow and reinforced with validation to ensure allocations always matched, reducing errors and unnecessary context switching in one of the most frequent and risk-sensitive workflows.
after usability testing
at a product level, Elo replaces fragile, spreadsheet-driven workflows with a shared source of truth.
at a team level, it enables safer access to financial data across roles, reducing bottlenecks and dependency on finance specialists.
at an organisational level, it establishes a scalable foundation that reflects how Subvisual works today and supports where it’s going next.
this project reshaped how I approach product design in operational and finance-heavy contexts. I learned that designing for ideal workflows doesn’t hold up in reality - financial data is often incomplete, delayed, or inconsistent, and good UX doesn’t try to hide that. Instead, it supports people in working through uncertainty with clarity and guardrails.
working closely with engineering reinforced how constraints aren’t blockers, but tools that sharpen decision-making. I also learned the importance of simplifying and prioritising core workflows over completeness, even when pressure exists to add more.
most importantly, this experience shifted my mindset from designing screens to designing systems, and from executing tasks to owning product judgement under uncertainty.
the next phase would move into development, including design handover and close coordination with engineering to translate the prototype into a production-ready system. Alongside this, broader validation across additional roles, edge cases, and real operational pressures would help ensure the product holds up in day-to-day use, with a continued focus on clarity and trust rather than premature feature expansion.
success would be measured through behaviour: finance workflows happening inside the product by default, reduced reliance on parallel spreadsheets, and leadership engaging confidently with financial data without additional explanation.
editing model:
inline editing supported speed for quick changes, while the side panel felt appropriate for more complex actions like multi-allocations
before usability testing
after usability testing
before usability testing
impact
the primary impact of elo isn’t a feature -
it’s confidence
key learnings
next steps
i facilitated a cross-functional brainstorming session with designers, developers, product owners, and product managers using the lotus method, which helped expand the problem space before converging on a focused set of feature ideas.
rather than competing on feature breadth, I prioritised where usability, trust, and business value intersected. Working closely with engineering, I aligned user impact, feasibility, and time constraints to define a focused MVP.
reconciliation was treated as the primary job of the system. Automation, edge cases, and secondary workflows were deliberately deferred to protect trust, reduce engineering risk, and ensure a solid foundation. This meant saying no to tempting additions in favour of clarity, safety, and control.
