Crypto · Fintech · Web & Mobile · 2025

Pay.io

Four actions were 78% of every session. I made those four the architecture.

View the product

Role

Product Design · Research

Year

2025

Outcome

40% faster to the actions operators use daily

Read

10 min read

Pay.io is a multi-currency crypto payments platform for businesses. Operators use it to fund payouts, move funds to treasury, and reconcile balances across currencies. Their players use it to deposit and withdraw.

I joined a brief about breadth. Session recordings pointed the opposite way, and the redesign that shipped came out of that disagreement.

Over twelve weeks, two decisions shaped the system: I won the argument to rebuild navigation around the four actions that represented 78% of sessions, and I lost the argument to remove a balance check. Both decisions made the shipped product safer and faster—and changed how I lead design disagreements.

My role and mandate

Product Designer, end to end. I ran the interviews and the session analysis, built the personas and the task-frequency picture, argued the architecture down from four levels to two, designed both interfaces and the design system behind them, and sat with engineering through the latency trade-offs that reshaped the funds transfer flow.

Team

1 designer, 1 PM, engineering, QA, Compliance

Timeline

12 weeks to ship redesigned core transaction flows

Tools

Figma, Loop11, session recordings and heatmaps

Discovery: nobody had watched the job being done

The stated problem was that operators could not clearly manage, track or reconcile financial actions across deposits, withdrawals and multi-currency balances. Errors, delayed reconciliation, eroding trust.

All true, and all symptom. Before designing anything I wanted to know which actions actually carried the weight, so I ran four methods in parallel against the twelve-week clock.

Four methods against a twelve-week clock

Four methods run in parallel against a twelve-week clock: interviews, session-recording analysis, task-frequency measurement, and a competitive read.

Tap to inspect the full-resolution artifact

Four actions were 78% of every session

The recordings settled it. Operators were not exploring the product. Four actions accounted for 78% of observed sessions, and almost nothing else was reached unless a specific business need forced it.

Two failure signals came out of the same data. Sessions were abandoned when a transaction state was ambiguous, and trust was lost when the same figure appeared with different decimal precision in two places.

The three operator roles I profiled — treasury, payments ops, and support — disagreed about almost everything except this. All three defined a disaster the same way: money that moved without the interface saying so.

Four actions, 78% of sessions

Observed session analysis. Four actions account for 78% of sessions, and almost nothing else is reached unless a specific business need forces it. This is the evidence that turned the brief from breadth into depth.

Tap to inspect the full-resolution artifact

Three roles, one definition of disaster

Treasury, payments ops and support. They disagree on almost everything except the definition of a disaster: money that moved without the interface saying so.

Tap to inspect the full-resolution artifact

That formatting signal mattered more than it looks. Operators read inconsistent decimal precision as an unreliable system, regardless of whether the arithmetic was correct.

“Fintech users do not want more features. They want fewer steps, clearer feedback, and absolute confidence in every financial action they take. Execute, do not explore.”

The walls I designed inside

I wrote the immovable constraints down before anyone fell in love with a layout, because in a payments product the fixed rules decide the interface.

Compliance, KYC and AML
Mandatory identity verification on every business account. AML screening above defined thresholds. Full audit trail for regulatory reporting across jurisdictions.
Technical limits
Real-time balances constrained by asynchronous blockchain confirmations. Multi-provider routing added latency to state syncing. Legacy reconciliation created gaps between displayed and actual balances.
Security expectations
Visible confirmation of every fund movement, no silent failures. Strict access control for multi-user console environments. PCI DSS rules constraining what could be displayed at all.
Time
Twelve weeks, running parallel to an API v2 migration, with a phased rollout that had to stay backward compatible with live merchant integrations.

Four levels down to two

I rebuilt the architecture around the four actions instead of around the feature list. Balances and pending transactions are visible on login, so the most frequent check requires no navigation at all.

The split is by intent rather than by feature. Managing covers oversight and configuration. Executing covers active money movement. That is how operators described their own day back to me.

Flattened hierarchy
From four navigation levels to two. Any action is reachable within two taps.
Explicit states
Every transaction carries a real-time status: Pending, Processing, Completed, Failed. The ambiguity that killed sessions had to be designed out, not worded better.
Two interfaces
Merchant Console for asset control, transaction management and reports. Cashier UI for deposits, withdrawals and history.

Rebuilt around frequency, not features

The architecture rebuilt around the four high-frequency actions instead of the feature list, split by intent — managing versus executing — which is how operators described their own day.

Four levels down to two

Navigation flattened from four levels to two: any action within two taps, with balances and pending transactions visible on login so the most frequent check needs no navigation at all.

Transaction states made explicit

Four named states, each with its own visual treatment, so an operator never has to infer progress from the absence of a message.

A design system that formats money correctly

Tokens to core components to variants, powering Cashier, Dashboard and API interfaces from one place.

The part that mattered most was the least visible: multi-currency formatting variants handling symbol placement, decimal precision and locale patterns. Given that inconsistent formatting was one of the two trust failures in the research, this was not housekeeping.

Numerical legibility
Typography chosen and tuned for reading figures, not for reading prose.
State-specific variants
Default, hover, active, disabled, error and loading for every interactive element.
Compliance-ready patterns
KYC and AML cues built into component behaviour rather than bolted on per screen.

The system that formats money correctly

Tokens through to component variants. The least visible part mattered most: multi-currency formatting handling symbol placement, decimal precision and locale patterns, because inconsistent formatting was one of the two trust failures the research found.

Spec

The money-formatting rules, written down

Inconsistent decimal precision was one of the two trust failures the research found: operators read the same figure rendered two ways as an unreliable system, regardless of whether the arithmetic was right. So formatting stopped being a per-screen decision and became a specified component behaviour.

Rule	What is specified	Why it is a rule and not a preference
Symbol placement	Per currency, as a formatting variant on the numeric component — never hand-placed in a layout	A symbol that moves between screens is the cheapest possible way to look untrustworthy.
Decimal precision	Fixed per currency and per context; the same figure renders identically everywhere it appears	This is the specific failure the research surfaced. Two renderings of one number cost more trust than a slow page.
Locale pattern	Separators and grouping follow the operator’s locale, not the currency’s origin	Operators reconcile across currencies in their own reading habits; forcing a foreign pattern makes scanning error-prone.
Numeric typography	A face chosen and tuned for reading figures rather than prose, with tabular alignment	Columns of money are scanned vertically. Proportional digits make that a guessing game.
Transaction state	Pending, Processing, Completed, Failed — always explicit, never inferred from absence	Sessions were abandoned when a state was ambiguous. The ambiguity had to be designed out, not worded better.
Balance provenance	A confirmed figure and a provisional one are visually distinct, with a manual refresh rather than a silent live update	The outcome of losing the live-balance argument: an honest provisional number beats an authoritative one that is sometimes wrong.
Interactive state	Default, hover, active, disabled, error and loading, on every interactive element	In a product where one action moves six figures, a control whose state you cannot read is a hazard.
Compliance cues	KYC and AML affordances live in component behaviour, not per screen; PCI DSS constrains what can be rendered at all	Bolting compliance on per screen guarantees it drifts. Putting it in the component means it cannot.

Pay.io · money display and state · handed to engineering as spec

Two consoles, opposite briefs

Merchant Console is for someone who lives in the tool. Onboarding gets an operator live fast — enable the assets and networks your players transact with — and the homepage answers the most frequent question in the research before it is asked: hot wallet balance, activity across timeframes, asset allocation, recent transactions, all above the fold. Transaction management got the most explicit design in the product, because it is where the money actually moves: clearing withdrawals manually within a threshold, retrying failures, monitoring player activity.

The Cashier had the opposite brief. One task at a time, relentless status feedback, network selection made hard to get wrong.

Live in one screen

Merchant onboarding: enable the assets and networks your players transact with, and you are live. The shortest path to the moment of value.

The most frequent question, pre-answered

The console homepage answers the most frequent question in the research before it is asked — hot wallet balance, activity across timeframes, asset allocation and recent transactions, all above the fold.

Where the risk actually sits

Transaction management, the surface carrying the most risk: clearing withdrawal requests manually within a threshold, retrying failures, monitoring player activity.

Treasury and asset control

Asset management — enabling and disabling assets, treasury setup, transfers and withdrawal limits.

The Cashier’s opposite brief

The Cashier has the opposite brief to the console: one task at a time, relentless status feedback, and network selection made hard to get wrong.

Same system, opposite end of the dial

The confirmation step, where the Cashier diverges furthest from the console: one decision on screen, the network restated, and no way to proceed without reading it.

Density is a feature for someone who lives in a tool and a hazard for someone visiting it while anxious about their own money. Same design system, two opposite settings of the same dial.

Where I was wrong and someone else was right

The balance check we removed

My position: I designed the funds transfer flow around live balances. Certainty was the whole thesis of the redesign, and to me a live figure was what certainty looked like.
What actually happened: Engineering flagged the latency of fetching balances across multi-currency accounts in real time. They were right, and I had specified something the rail could not deliver. The synchronous balance check came out.
What I did about it: We rebuilt the flow around optimistic UI updates with background validation, and replaced the live check with a deliberate manual refresh. I specified annotated prototypes covering every transaction state, error path and edge case, with expected responses and data dependencies documented per screen, then ran joint QA walkthroughs against them and kept a shared decision log of each trade-off and its reasoning.
What I hold now: The interface got more honest than my version would have been. It now distinguishes a confirmed figure from a provisional one — a distinction the live-balance design would have hidden behind a number that looked authoritative and sometimes was not. I was optimising for the feeling of certainty; the constraint forced me to design the real thing.

Every state, documented before build

The annotated state coverage behind the rebuilt transfer flow: every transaction state, error path and edge case, with expected responses and data dependencies documented per screen.

Tap to inspect the full-resolution artifact

Impact

What I measured

my work, my instrumentation

40%

Faster to critical actions after the navigation hierarchy was resurfaced

How: Loop11 task timings, pre- and post-redesign, same task set

4.2 → 3.3

Minutes to complete core transactions such as sending funds and issuing cards

How: Moderated task timings, same operators on both builds

4 → 2

Navigation levels, putting every daily action within two taps

How: Counted against the shipped IA

What the business reported

company outcomes my work contributed to

Merchants queued for onboarding in the first week of launch

Reflection

The research finding I nearly missed was the formatting one. It arrived looking like a styling nit and turned out to be a trust mechanism, which is why the design system spent real effort on decimal precision instead of on colour.

The thing I got wrong was density. My first transaction detail view showed everything at once, which overwhelmed operators who were there for a five-second status check. I also underestimated multi-currency edge cases, where simultaneous balance updates produced UI state conflicts and stale figures. And my first confirmation patterns were too quiet for high-stakes actions, so people repeated transfers because they could not tell whether the first one had landed.

What I learned
Rounding errors, pending states and failed retries are not exceptions in a payments product. They are the core scenarios, and designing them last means designing them twice. Users equate visual precision with platform reliability. Operators think in workflows, not screens.
What I would build next
Scheduled exports and dashboards so cash flow monitoring stops being manual. Searchable, time-stamped records of every action and approval chain for compliance. Proactive alerts on anomalies, failed payments and balance thresholds. Role-based default views, because a finance manager and an account admin should not open the same screen.

Result

40%

faster to the actions operators use daily and core transactions down from 4.2 to 3.3 minutes.

Restructured the whole platform around the four actions that made up 78% of observed sessions, flattened navigation from four levels to two, and made every transaction state explicit.

Worked with me

“Joseph was a member of my global UX design team for 18 months. During that time, I was grateful for the thoughtfulness he brought to every design challenge and his positive attitude which continuously elevated the results of the cross-functional team he worked with. He brought both a consumer and business-savvy mindset to his design decisions, and is committed to leveraging design systems to drive consistent and efficient digital experiences.”
Erin SkurdalDirector, Global UX Design & Content · Kenvue Inc

Back to work