PROJECTS
OrbitPayout - Product Redesign
Client:
OrbitPayout Inc.
Year:
2025
Location:
US-based, remote
Service:
UI/UX Redesign
Project Overview
Category: Fintech SaaS/B2B Finance Ops
Deliverables: UX strategy, dashboard architecture, UI system, component library, finalized UI
Timeline: 3 weeks
DAR Design role: UX/UI design team
A finance-grade command center for payout teams — designed to keep volume moving, surface risk early, and make exception handling fast, defensible, and audit-ready.
What we redesigned in this phase:
Command Center (live health + analytics + queue visibility)
Exceptions & Holds (triage table + case detail + decision actions)
Primary users:
Finance Ops / Payout Ops (throughput, accuracy, SLA)
Compliance / AML (risk & policy enforcement)
Risk / Fraud (coverage, anomaly detection, decision confidence)
Controllers / Finance leads (reconciliation confidence, audit posture)
Core KPI (product-level):
Faster resolution of exceptions with fewer errors and less context switching
UX success criteria:
“I can see what matters in <10 seconds.”
“I can confidently approve/hold/escalate without hunting for context.”
“If someone audits this decision later, it’s defensible.”
The business context (why this mattered)
Payout operations don’t fail politely. When money is moving, teams don’t need “analytics.” They need control, visibility, and decisions that don’t backfire.
The operational reality for payout teams looks like this:
Volume spikes on specific days and routes.
Exceptions cluster around a few recurring patterns (KYC mismatch, IBAN failures, velocity spikes, sanctions flags).
Recon breaks quietly — and only becomes “real” when finance has to close books.
A single bad approval can become a compliance incident.
A single over-cautious hold can break SLA and damage trust.
OrbitPayout had to feel like a mission control system:
calm under pressure
fast to scan
hard to misuse
and structured around real operational work, not feature demos
The hardest constraint was the buyer-user reality:
Ops teams want speed — but not at the cost of risk
Compliance wants rigor — but not a workflow that blocks throughput
Finance leadership wants reconciliation confidence — but not spreadsheets and guesswork
So the UI had to serve multiple roles without becoming multi-headed.
The challenge
The client didn’t need a “cool dashboard.” They needed an interface that:
compresses operational complexity into glanceable signals
keeps exception handling decisive, consistent, and auditable
prevents costly mistakes (wrong approval, missed risk, incorrect assumptions)
reduces context switching between queue > investigation > action
balances density with calm (high information load without visual chaos)
Discovery & strategy
We treated this like an operational product, not a “dashboard UI.”
1) Turn user stories into an execution model
We translated the stories into the real work loop:
Monitor system health and volume
Detect anomalies and backlog risk early
Triage exceptions (what is it, how risky, how urgent)
Investigate with enough context to act
Decide (approve / hold / escalate)
Prove decisions later (audit trail mentality)
That loop became the backbone of both screens.
2) Design for “glance > drill down”
Most payout teams don’t sit and “analyze.” They scan, then react.
So we built a consistent pattern:
Glanceable headline metric
Status + trend (good / attention / risk)
A clear next step (“Review queue”, “Open ledger”, “View failure log”)
Progressive disclosure of detail only when needed
3) Prioritize risk as a first-class signal
In payout systems, risk isn’t a footnote — it’s the main thing that slows teams down.
We made risk visible through:
clear status badges
SLA risk chips in the queue
“Why flagged” reasons in plain language
consistent decision actions (approve/hold/escalate) tied to context
4) Build a UI that feels finance-grade
Finance tools can’t look playful or ambiguous — but they also can’t look like 2009 enterprise.
So the design goal was:
modern, premium, calm
high-contrast readability
minimal decoration
color used only as meaning (state + risk), not “style”
Product principles we anchored on:
Visibility of system status: health, volume, reconciliation, queue — always readable
Progressive disclosure: overview first, detail on demand
Error prevention: actions only after context is present
Consistency: same patterns for labels, risk, time, and next-step links
Audit mindset: every decision should look defensible, not impulsive
Calm density: high information density without visual noise
Overview: Command Center
A true operations home: health, throughput, queue pressure, and risk posture in one place.
What this screen had to answer immediately:
Are payouts healthy right now?
Is anything drifting toward failure or SLA breach?
Where is today’s throughput concentrated?
Are exceptions growing — and do we need to triage?
Is reconciliation on track or quietly falling behind?
Key UX decisions:
1) A “status row” that acts like an ops heartbeat
The top row is intentionally structured as quick diagnostic tiles:
Payout Health (with trend delta + failure log entry point)
Exceptions (count + direct path to review queue)
Today’s Volume (what’s already paid today + direct queue access)
Reconciliation (24h success rate + direct open-ledger path)
Why it works:
It reduces anxiety: operators don’t have to hunt for “Are we OK?”
Every tile has a clear action — not just a metric
The language is operational (“failure log”, “review queue”, “open ledger”)
2) Global search designed for real ops behavior
The search bar is positioned and labeled for what teams actually look up:
payouts
Trace ID
recipients/entities
This is a “get me to the exact thing” tool — not a generic search pattern.
3) Analytics that explains anomalies, not just trends
The line chart isn’t there for aesthetic “data vibes.”
We made it interpretable by:
using a clear weekly time context
adding markers to represent notable events/alerts
supporting quick range switching (Day / Week / Month / Quarter)
Why it matters:
Ops teams need “What happened?” not “Nice chart.”
Markers hint at root-cause moments without forcing deep investigation.
4) Real-time Queue surfaced as operational pressure
Queue is a pressure gauge — not a list.
So it’s designed to show:
how many are waiting
live state indicator
top items with clear statuses (compliance hold / in review / queued)
Why it works:
It tells you whether you’re “keeping up” at a glance
It makes exceptions feel connected to the operational reality (not a separate world)
5) “Top Rails” turns routing into a quick sanity check
Rails are the arteries (ACH, Wire, SEPA, etc.).
This module tells you where volume is flowing and where to look if issues cluster.
ordered list by volume
progress bars for distribution
updated timestamp to imply live awareness
6) Fraud Shield designed as confidence, not fear
Fraud controls are often presented as scary alerts. That creates overreaction.
We positioned it as:
Coverage (how much is protected)
SLA safety (how safe we are operationally)
auto-cleared payout volume (proof of automation working)
status gauge showing review vs holds vs auto-approval
Result: operators feel supported, not panicked.
What this screen communicates (without saying it)
The system is stable, monitored, and controlled
Exceptions are manageable and actionable
Decisions are connected to ledger reality
Risk is present — but governed
That’s what “finance-grade” feels like.
Overview: Exceptions & Holds
A triage-first workflow: list > context > decision, all in one place.
This is where trust is either built or destroyed — because this is where real approvals happen.
The core problem we solved here
Exception workflows usually fail in one of two ways:
Table-only UI: fast scanning, but weak investigation → risky approvals
Detail-only UI: lots of context, but slow triage → SLA pain
OrbitPayout needed both:
fast scanning and confident decision-making
without forcing operators to bounce between multiple screens
So we designed it as a split-view triage system.
Key UX decisions
1) A queue built for scanning under pressure
The main table is structured around what matters in triage:
Case ID + type (AML, Compliance, Bank, Limits, Other)
Entity / recipient (who is involved)
Amount + rail (money + channel context)
Reason (plain-language, not codes)
Age (time since flagged)
SLA risk (low / medium / high)
Action affordance (quick access without clutter)
Why this works:
It mirrors the mental checklist operators use
It supports “scan first, click only when needed”
Risk and time are visible — not hidden in a details view
2) Filtering designed like operational slicing
The top filter pills (All, Compliance, AML, Bank, Limits, Other) aren’t a “nice UI touch.” They are how teams structure workload ownership.
We also added:
Auto-refresh toggle (because exceptions are live)
Date range (Last 7d)
Sort control (Newest)
This turns a static list into a controlled workflow.
3) Split-view case details for zero context switching
Selecting a row reveals a full Case details panel with:
status and case type
amount + currency + rail
entity name and timestamps
“Why flagged” with human-readable bullet reasons
entity profile + risk tier + payout history
decision buttons: Approve payout / Hold / Escalate
notes field for audit log
Why it matters:
Operators can investigate and act without leaving the queue
The UI naturally reduces sloppy decisions
Notes are built in, not bolted on — which matters for compliance culture
4) “Why flagged” is the trust engine
We made “Why flagged” explicit and scannable because:
it reduces second-guessing
it standardizes decision framing across the team
it makes the system feel explainable (crucial for compliance)
This is where the UI stops being “pretty” and becomes operationally credible.
5) Decisions are clear, distinct, and safe
Approve / Hold / Escalate are deliberately separated and styled as primary actions.
Approve is available only when context is visible
Hold is explicit (not ambiguous “pause”)
Escalate communicates process ownership, not panic
The goal: fast decisions that still look defensible.
What this screen enables
Faster triage without missing key context
Fewer “tab ping-pong” loops between the queue and the investigation
More consistent decisions across operators
A workflow that naturally produces audit-ready notes
Clear prioritization via SLA risk + case age
Even with only two screens, the system already reads like a complete product — because the workflow is coherent.
Visual system
This UI is dark by design — but not “dark for aesthetics.”
It’s dark because:
it reduces glare in long monitoring sessions
it supports high-contrast status signaling
it lets the important elements (numbers, states, actions) carry visual weight
Key visual choices that support usability:
Color reserved for meaning: status, risk, live indicators
Soft elevation + controlled highlights: clarity without clutter
Consistent typography scale: headings are calm, data is strong, labels are quiet
Component consistency: chips, pills, table rows, panel sections all share the same logic
The end result is a system that feels:
modern
controlled
trustworthy
and genuinely usable at high speed
Deliverables
Information architecture for both screens (glance → drill-down model)
User-story translation into operational workflows
Component-based UI direction (statuses, badges, tables, split panels, actions)
Interaction logic (filtering, selection state, queue + detail behavior, decision controls)
Visual direction aligned with finance-grade credibility
The result
OrbitPayout now has a foundation that looks and behaves like a real payout operations system:
a Command Center that communicates health, pressure, and risk in seconds
an Exceptions workflow that supports fast decisions without reckless approvals
a UX that feels calm, premium, and audit-ready — not “dashboard art”
It’s the kind of product UI that makes teams think: “This system is controlled. I can trust it. I can run payouts here.”
PROJECTS