The real design flaw wasn’t on the screen. It was far upstream.
When asked to improve a complex, data-heavy product, the instinct is often to polish the existing UI. But in a domain as dense as financial reconciliation, designing a smoother surface layer over an inherently unreliable process only hides the core friction.
Instead, using research and systematic reframing, I turned a standard feature request into a structural solution.
At a Glance
- Upstream Focus: Shifted feature from the known pain point to the actual issues, far upstream.
- Flow Efficiency: Consolidated fragmented screens into a unified, modular workspace tailored to user mental models.
- Edge-Case Coverage: Systematically mapped and designed for dozens of edge cases before entering high-fidelity UI.
Role
Sole Product Designer, doing research, wireframes, and final designs. Worked closely with PM and engineering
Domain
Financial UX
B2B Data Reconciliation
Skills
Problem Reframing Research Planning Information Architecture B2B Product Design
Context
Skipping the Zero-to-One Phase (with Prior Domain Knowledge!)
Financial reconciliation is notoriously complex. It involves untangling multi-layered transaction chains, handling system mismatches, and accounting for dozens of failure modes across ledgers.
Having previously worked on large-scale data reconciliation, I entered this project with deep domain context, allowing me to skip the basic learning curve and ask sharper questions immediately.
Initial Assumption
Taking the initial brief at face value would have meant optimizing a flow that was fundamentally flawed from the start.
Through user research and competitive auditing, it became clear that the current screens were not failing because of poor visual design. They were failing because transaction-level errors were making accurate reconciliation impossible in the first place. Trying to fix broken inputs late in the chain is a losing battle.
Initial brief:
“Just improve the Reconciliation UI”
Redesign existing screens to make matching easier.
Research audit: “Reconciliation is impossible”
Transaction errors upstream were blocking accurate matches.
The reframe:
“Solve the problem upstream”
Shift design focus to logic builders & root-cause fixes.
The Reframe
Problem Statement
How might we design a system that catches and resolves transaction discrepancies at the source, so that complex reconciliation becomes a seamless byproduct rather than a manual chore?
The Strategy
Sorting Complexity into Structure
Given how easily financial data can overwhelm a screen, I audited every input, task, and edge case in the existing system, grouping them into three buckets:
- Automation Opportunities (Logic Builders)
- Approach: Adapted validated rule-building patterns so users can set matching conditions up front rather than repeating manual actions.
- Core Tasks (Focused Workspaces)
- Approach: Replaced dense data tables with task-focused queues that surface unmatched bank data and priorities first.
- Complex Exceptions (Side-by-Side Comparison Views)
- Approach: Designed clear evidence-based comparison views between bank feeds and internal records to guide users smoothly through dense edge cases.
The Architecture
From Fragmented Screens to One Flow
Sorting the requirements allowed me to collapse a disjointed, multi-screen process into a clear three-part architecture:
OLD FLOW (Fragmented)
[ Step 1: Entry ] ──> [ Step 2: Data Search ] ──> [ Step 3: Manual Fix ] ──> [ Step 4: Final Review ]
NEW FLOW (Integrated)
1 Bank Account Overview ──> High-level balances, feed status, and immediate priorities
2 Logic & Rules ──> Upstream rule creation to prevent recurring matching issues
3 Exception Workspace ──> Side-by-side view built specifically for complex edge cases
[INSERT DIAGRAM: Bank-Account-to-Matching Flow]
Show the step-by-step structural transition from account overview into logic matching.
The Validation
Testing Mental Models Over Assumptions
To validate the reframed flow, I ran synchronous and asynchronous usability sessions using interactive wireframes:
- The Assumption: I assumed users would want to jump straight into configuring automated rules to save time.
- The Reality: Users wanted to see side-by-side evidence before trusting an automated rule.
- The Pivot: I updated the layout to keep comparison context visible alongside rule controls, matching how finance teams naturally evaluate complex data.
[INSERT SCREENSHOT: Side-by-Side Comparison UI & Usability Findings]
Annotated UI demonstrating how verification data is presented alongside action triggers.
The Takeaway
System Design Over Screen Design
- Current Status: The project is currently in development. Early usability testing and stakeholder reviews show strong positive validation for the task-based structure and reduced manual overhead.
- Reflection: The most impactful part of product design isn’t visual refinement. It’s having the research discipline and domain confidence to challenge the initial brief, find the real problem upstream, and design for the system instead of just the screen.