Challenge
A dashboard that had grown organically for years. Merchants, admins, and support staff shared the same cluttered screens, and critical actions were buried three levels deep.
Case Study
Web · B2B SaaS · Product Design
LIVERUM
Merchant & Admin Dashboard
Rebuilding a merchant and admin dashboard so finance and operations teams can monitor payments, reconcile transactions, and manage risk from one calm surface.
Project Snapshot
Solution
A role-aware information architecture with a consistent table system and restrained color, plus a focused step-based reconciliation flow with inline validation.
Responsibilities
- Design lead
- Information architecture
- Component & table system
- Reconciliation redesign
Outcome
Teams reconciled 41% faster and new operations staff onboarded in days, not weeks. The design system became the foundation for every Liverum surface.
Context
One dashboard, too many jobs
Liverum's dashboard had grown organically for years. Merchants, admins, and support staff all shared the same cluttered screens, and every new feature added another tab. Critical actions were buried three levels deep.
I led the redesign of the core operational surface — the place teams live in all day — with a mandate to make dense financial data legible without dumbing it down.
Approach
Designing for density without noise
I built a role-aware information architecture so merchants and admins each saw a workspace tuned to their tasks. A consistent table system, clear typographic hierarchy, and restrained use of color let people scan thousands of transactions without fatigue.
Reconciliation — the most painful workflow — was rebuilt around a focused, step-based flow with inline validation, cutting the number of screens a user had to touch to close their books.
Outcome
Faster operations, fewer errors
Teams reconciled transactions significantly faster, and onboarding new operations staff went from weeks to days because the interface now taught itself. The design system that came out of the project became the foundation for every Liverum surface.
Project Context
Liverum is a merchant and admin dashboard for a crypto payments platform — the operational surface where finance and ops teams monitor payments, reconcile transactions, and manage risk.
Why this project mattered
The dashboard was where trust in the whole platform was won or lost. Slow, error-prone operations directly cost merchants money and eroded confidence in the product.
Who it's for
Merchant finance teams, internal admins, and support staff who live in the product all day and need dense financial data to stay legible under pressure.
Business goals
- Cut reconciliation time and errors
- Speed up new-staff onboarding
- Support role-specific workflows
- Establish a scalable design system
Market context
B2B payments tooling was functional but hostile — inherited enterprise UIs where every team shared the same cluttered screens. Modern SaaS had reset expectations for clarity and speed.
Problem Statement
How might we make a dense, multi-role operations dashboard legible enough that finance teams reconcile with confidence and new hires onboard in days?
01
User Problems
- Merchants, admins, and support share one cluttered surface
- Critical actions buried three levels deep
- Reconciliation demands cross-referencing scattered screens
- No visual language separates gains, losses, and pending states
02
Business Problems
- Slow reconciliation directly costs merchants money
- New staff take weeks to become productive
- Errors erode trust in the whole platform
- Every new feature widens an inconsistent UI
03
Technical Constraints
- Years of organically grown legacy components
- Large financial datasets rendered in real time
- Role-based permissions gate most actions
- Must integrate with existing back-end APIs
04
Product Constraints
- No downtime migration for active merchants
- Backward compatibility with saved workflows
- Accessibility for all-day operational use
- Design system must scale to future surfaces
Goals
01
User Goals
- Reconcile transactions with confidenceDiscrepancies surfaced inline, not hunted across screens
- Reach any critical action fastKey tasks within two clicks of the dashboard
- Read financial state at a glanceConsistent color language for gains, losses, pending
02
Business Goals
- Lower operating cost per merchantFaster reconciliation and fewer errors per account
- Shorten staff onboardingNew operators productive in days, not weeks
03
Product Goals
- Serve three roles without clutterRole-aware views hide irrelevant controls
- Establish a reusable systemShared table and component library across surfaces
Success Metrics
-41%
Reconciliation time
per session
5 days
Onboarding time
down from 3 weeks
≤ 2 clicks
Task depth
for critical actions
-52%
Reported errors
quarter over quarter
Research & Discovery
This was an operations tool, so we researched where it was used: shadowing finance teams, interviewing admins and support, benchmarking B2B dashboards, and mining usage logs to see which paths were actually worn.
01
Stakeholder Interviews
Interviews with ops, engineering, and account management exposed a tool everyone patched but no one owned.
- Feature-by-feature growth had erased any coherent structure
- Onboarding time was the metric leadership felt most
- Roles had very different needs forced onto one screen
Every team asked for one more column, and now nobody can find anything.
Onboarding a new analyst takes weeks because the interface has no logic to it.
02
User Interviews
Shadowing eight operators during real reconciliation showed the work was detective work — hunting for discrepancies across disconnected views.
I keep four tabs open just to match one transaction. It should be one screen.
I've memorized where everything is. A new hire is basically lost for a month.
Context
Discrepancies were scattered, forcing constant tab-switching
Legibility
No visual system separated states or severities
Expertise
The tool rewarded memorization over clarity
03
Competitive Analysis
We benchmarked against modern B2B financial dashboards and legacy enterprise tools.
Modern SaaS dashboardsClean tables, clear hierarchyRarely handle deep financial density
Legacy enterprise toolsPowerful and completeHostile, memorization-heavy UIs
Analytics platformsStrong data visualizationWeak on transactional workflows
Opening
Combining SaaS-grade clarity with real financial density was the underserved middle.
04
Analytics
Usage logs quantified how much effort routine tasks actually cost.
6 clicks
Avg. to reconcile
Critical path was buried deep
4 views
Opened per task
Operators juggled multiple screens
3 wks
Time to proficiency
New hires ramped slowly
05
User Journey Insights
The reconciliation journey revealed friction concentrated in locating and cross-referencing data.
- 01Open dashboardOverwhelmed by undifferentiated data
- 02Locate transactionSlow search across cluttered tables
- 03Cross-referenceManual matching across multiple views
- 04Resolve & confirmConfident once data was finally aligned
Key Research Findings
- 01The core cost was navigation and cross-referencing, not the actual decisions
- 02A consistent visual language for states would remove most guesswork
- 03Role-aware views could de-clutter without removing capability
- 04A shared component system was the only way to stop future entropy
Design Strategy
Research showed the cost was navigation and cross-referencing, not the decisions themselves. So the strategy centered on legibility and structure: a shared system, role-aware views, and inline context — reducing effort before adding any new capability.
01
Key Insights
- Operators lost time locating and matching dataBring discrepancies and context inline, not across tabs
- No visual language separated statesDefine one strict system for severity and status
- Three roles were forced onto one screenTailor views per role instead of one crowded surface
02
Design Principles
Clarity over density
Legibility mattered more than fitting everything on screen
One system, many surfaces
Consistency was the only defense against future entropy
Right tools for the role
Each role needed focus, not the full toolset
03
Prioritization Framework
We prioritized by frequency and pain — the tasks operators did daily and dreaded most came first, and foundational system work was sequenced to unblock everything after it.
NowTable system & reconciliation flowThe highest-frequency, highest-pain workflow
NextRole-aware navigation & viewsDe-cluttered without removing capability
LaterAdvanced admin & reportingImportant but lower daily frequency
04
Success Criteria
- An operator reconciles a transaction on a single screen
- State and severity are readable without training
- A new hire is productive within days, not weeks
- Every surface draws from one shared component system
Design Process
A loop shaped by operational reality. Every round of testing happened against live reconciliation work, which kept sending us back to the information architecture until each role could see only what it needed.
- Step 01
Discover
Shadowed finance, ops, and support staff to see how a dashboard grown over years actually got used under deadline.
- Observed reconciliation and payment-monitoring sessions live
- Mapped which critical actions were buried three levels deep
- Interviewed merchants, admins, and support on their shared pain
- Catalogued every table, filter, and status inconsistency
- Step 02
Define
Reframed the problem as role clarity, not more features — each user needed a legible view of only their own work.
- Separated merchant, admin, and support jobs-to-be-done
- Defined a single reconciliation task as the make-or-break flow
- Set onboarding-in-days as an explicit success measure
- Agreed a consistent table and status language
- Step 03
Ideate
Explored a role-aware architecture and a reusable table system that could tame density without dumbing it down.
- Sketched role-based navigation and default landing views
- Explored one table pattern flexible enough for every dataset
- Tested restrained color as a status signal, not decoration
- Prioritized a focused, step-based reconciliation flow
- Step 04
Prototype
Built the reconciliation flow and core tables at fidelity, with inline validation so mistakes surfaced early.
- Wireframed role-specific dashboards and drill-downs
- Assembled the shared table components and their states
- Designed step-based reconciliation with inline validation
- Populated with real transaction volumes and edge cases
- Step 05
Test
Ran the flows with real finance teams to see whether they could reconcile with both confidence and speed.
- Moderated reconciliation tasks with finance and ops staff
- Timed how fast teams closed the loop end to end
- Checked whether new hires could onboard unaided
- Watched for misreads in dense tables and statuses
- Step 06
Iterate
Tuned hierarchy, defaults, and validation, then hardened the patterns into a reusable design system.
- Refined table density, sorting, and empty states
- Adjusted role defaults based on observed workflows
- Re-tested reconciliation to confirm the speed gains
- Codified the patterns as the foundation for every surface
User Flow
Finance and operations teams live in this dashboard to keep payments reconciled. The flow centers on the daily triage decision: is a transaction clean, or does it need investigation before the books can close?
Sign In
Open Payments
Transaction flagged?
Flagged
Review & Resolve
Clean
Monitor & Confirm
Ledger Reconciled
Key Decision Points
- 01
Route by role
Merchants and admins land on different default surfaces, so each team sees only the payments and controls relevant to their responsibilities.
- 02
Triage by risk
Flagged transactions are pulled into a dedicated review queue, keeping the exceptions that need human judgment separate from the clean volume that can flow through.
- 03
Close with an audit trail
Every path — resolved exception or clean match — ends in a reconciled, logged state, so finance can trust the numbers and prove how they got there.
Final Solution
The delivered dashboard gives finance and operations teams one calm surface for high-volume reconciliation. Three views define it: seeing the whole picture, working the exceptions, and closing the books.
01
Payments Overview
Design Objective
Let a team assess the health of thousands of daily transactions in a single glance, without drowning in rows.
Key UX Decisions
Status is summarized at the top with clear counts, dense tables use restrained typography and generous row spacing for scanability, and role-based defaults surface the metrics each team actually owns.
Outcome
Teams triaged the daily queue faster and reported far less time spent hunting for what needed attention.
02
Transaction Review
Design Objective
Give analysts everything needed to resolve a flagged transaction without leaving the screen or losing context.
Key UX Decisions
Selecting a flag opens a detail drawer beside the list rather than a new page, keeping the queue in view; risk signals, history, and actions are grouped so judgment and resolution happen in one place.
Outcome
Exceptions were cleared with fewer clicks and less context-switching, shortening the time to resolve a flag.
03
Reconciliation & Reporting
Design Objective
Turn the messy end-of-period close into a confident, auditable moment finance can stand behind.
Key UX Decisions
Reconciled totals, outstanding items, and a complete audit trail live on one report, with exports and filters that mirror how accountants already think about closing the books.
Outcome
Reconciliation became a repeatable, provable routine, reducing month-end friction and disputes over the numbers.
Design System
An enterprise system tuned for density without fatigue. A disciplined table language, restrained status color, and a strict type scale let teams scan thousands of rows calmly.
- #1A1C21InkText, table content
- #FFFFFFSurfaceCards, table rows
- #25B8E1AccentPrimary actions, links
- #12B76ASuccessSettled, success states
- #C2C6CEMutedSecondary text, meta
Ag
Ag
Radius12pxBase unit4pxGrid8pxFocus ring2px accent
Press to see the active state
Disabled
Input — click to focus and type
Checkbox & switch — click to toggle
Radio — select a payment method
Status badges
SuccessPendingFailedIn ProgressPartialCancelled
Select — open and choose
Tabs — switch views
Transaction rows
USDT
Results & Impact
Consolidating fragmented tools into one calm surface made reconciliation faster, onboarding dramatically shorter, and errors rarer — turning a daily grind into a repeatable, auditable routine.
Business Outcomes
User Outcomes
- Role-based defaults that surface the right surface for each team
- A dedicated risk queue separating exceptions from clean volume
- In-context detail drawer that keeps the transaction list in view
- One reconciliation report with a complete, exportable audit trail
- 01Density and calm can coexist when the table language is disciplined.
- 02Separating exceptions from clean volume is what makes high throughput humane.
- 03An auditable trail turned reconciliation from anxious to routine.
- Reconciliation timePer session-41%
- Onboarding time3 weeks5 days
- Task depthDeep menus≤ 2 clicks
- Reported errorsQuarter prior-52%
Reflection
This project taught me that enterprise design is mostly the discipline of subtraction under pressure. The teams didn't need more features — they needed the existing complexity organized honestly, and getting there meant saying no a lot.
- Investing in a shared component system early paid compounding dividends across every later surface.
- Sitting with finance teams during real close cycles surfaced problems no interview would have.
- Separating the risk queue from clean volume reframed the whole product around how work actually flows.
- I'd bring engineering into the component-system work sooner to lock tokens and behavior together.
- I'd prototype the highest-density views with real data volumes earlier to test the limits.
- I'd build a clearer migration path for the legacy workflows we had to make exceptions for.
Challenges & Trade-offs
Density vs. clarity
Power users wanted everything on one screen; new hires drowned in it. The trade-off was progressive density — calm defaults with depth on demand — which frustrated a few veterans before it won them over.
Consistency vs. legacy edge cases
A unified system collided with years of one-off workflows. We standardized aggressively but had to carve deliberate exceptions, accepting some inconsistency rather than breaking critical, entrenched processes.
- 01In enterprise tools, trust is built by respecting existing expertise, not overriding it.
- 02A design system is an operational asset, not a cosmetic one — it changes team velocity.
- 03The riskiest assumptions live in the exception cases everyone wants to ignore.
- Configurable, role-specific dashboards so each team shapes its own default view.
- Anomaly detection that pre-triages the flagged queue before a human opens it.
- An audit and reporting API so finance can pull reconciliation data into their own tools.
