Product design case study · Dashboard · 5 min read

The old dashboard showed how much happened.
It didn't show whether it was working.

The platform dashboard told merchants and operators how much activity there had been: transaction counts in four coloured panels, and a geo chart. It never showed approval rate — the share of attempted transactions that actually complete, and the number a payments business runs on. The rebuild starts from that number.

The problem
The dashboard counted how many transactions happened. It did not show whether they worked.
The decision
Lead with approval and decline rate by payment method, then provider, region and bank performance.
What I built
A dashboard that opens on approval and decline rate by payment method, under one shared date range, with explicit empty states and provider, region and MID tables below.
The outcome
Live in the React platform.
Product
Payments orchestration platform (anonymised)
Role
Senior UX/UI designer
Timeline
February – March 2026
4
coloured panels showing the same metric at four time ranges.
Before
2
of them rendering empty, with no explanation.
The problem
0
places approval rate appeared on a payments dashboard.
The argument
1
date range, set once for the whole screen.
The rebuild

01 The problem

It counted activity, not success

You could see that four hundred transactions happened. You could not see that a third of them failed, which payment method was failing, or in which country.

The old dashboard: four coloured panels labelled Today, Weekly, Monthly and Yearly, two of them empty, above a large world map titled Geo chart. The new dashboard: approval rate and decline rate cards with a bar per payment method, a row of five metric cards with trend lines, and an approval rate by day chart.
Fig. 01 — Before and after. The old screen spent its four panels on one metric at four time ranges, and two of them rendered empty. The new one opens on approval and decline rate, so the first thing a merchant reads is whether payments are completing. All values on these screens are sample data. View full screen: before · after

02 The users

Approval falls overnight. They should hear it here first.

The person who opens this is a payments lead at a mid-size operator. It is the first screen they look at, because approval rate falling overnight is money already lost by the time anyone picks up the phone.

What they are trying to avoid is finding out from somebody else — a customer complaint, a provider's status page, an email from us. The dashboard is the tool that is supposed to tell them first.

03 The changes

What I changed, and why

  1. Old

    Counts answered “how much”, not “is this working”.

    New

    Led with approval rate and decline rate, each broken down by payment method, so a drop can be traced to its cause at a glance.

    Approval rate card at 85.59 percent and decline rate card at 11.59 percent, each with a column per payment method — Visa, Mastercard, JCB, Apple Pay, Klarna and others — labelled with its own rate.
    Fig. 02 — Each headline rate carries its own breakdown by payment method, so a drop in approval can be attributed at a glance rather than only noticed. View full screen
  2. Old

    Four panels showed the same metric at four time ranges, in four different colours.

    New

    One row of metrics under a shared date range, each with a trend line, so the comparison is between metrics rather than between periods of the same one.

    Five metric cards in a row: total transactions, average order amount, approved amount, chargeback count and chargeback percentage, each with a change badge and a sparkline for the same date range.
    Fig. 03 — Five different measures over one date range. The period is set once for the whole screen, so the cards can be read against each other. View full screen
  3. Old

    Colour was decoration — orange, green, red and teal panels with nothing attached to them.

    New

    Colour has a job wherever it appears. Green and red mark only the direction of change against the previous period, on the trend badges and sparklines.

  4. Old

    Two of the four panels rendered empty, with no explanation.

    New

    Explicit empty states that say what is missing and offer a retry.

  5. Old

    A geo chart showed where transactions came from, but not how they performed.

    New

    A region table with approved amount, average order value, chargeback rate and volume share per country, so a bad market can be found, not just a busy one.

    Region wise payments: a table of countries with approved amount, average order value, chargeback rate and transaction volume share, beside a dotted world map.
    Fig. 04 — The map stayed, but the table does the work. A country with high volume and a high chargeback rate reads as a problem here, where the old map could only show it as busy. View full screen
  6. Old

    Nothing showed how the payment providers were performing.

    New

    A PSP performance table with approval rate and volume per provider, and a MID-level summary per bank.

    PSP performance table listing four providers with their approval rate and volume. Summary table by MID: bank name, share of traffic, successful orders, amount approved, approval rate and chargeback rate.
    Fig. 05 — Provider performance and the MID summary below it. When approval drops, these tables are where an operator finds out whether one provider or one bank account is responsible. View full screen: provider table · MID summary

04 Diagnosis

Approval is down. Where do you look?

This is the flow the dashboard was designed for, not a recorded incident.

  1. The approval card reads 85.59%, down 3.1% on the previous period — both sample figures from the design — and its bars break that rate down by payment method, so the method that dropped is visible straight away.
  2. The PSP performance table shows whether one provider is behind it: approval rate and volume, provider by provider.
  3. The region table shows whether it is one market: approved amount, average order value, chargeback rate and volume share, country by country.
  4. The MID summary narrows it to a bank and a MID.

On the old dashboard the same question ended at “transactions are down,” with four coloured panels and no way to ask why.

05 Iterations

More data first, then less on purpose

  1. v1 → v2 · density

    The first version carried more: a provider comparison table with difference columns, a transaction success rate donut, and an approval chart split by brand with five lines and four filters.

The first version of the new dashboard: empty headline cards, an approval rate by brand chart with five coloured lines and four filter menus, a PSP performance comparison table with difference columns, and a transaction success rate donut. The final dashboard: approval and decline rate cards with per-method breakdowns, a metric row, an approval rate by day chart, PSP performance, region table, chargeback ratio, payment methods and the MID summary.
Fig. 06 — The first version beside the one that shipped. The brand comparison, the donut and the five-line chart were removed for clarity; approval and decline moved to the top, broken down by payment method. View full screen: the first version · the shipped one
Fig. 07 — The animation prototype. The static first version became an animated one: each metric reveals itself with motion as the page scrolls. The recording still shows the provider comparison table from the earlier version. View full screen

06 The rules

Clarity over density, and a library that had to grow

The dashboard brought features the platform did not have, animated components among them. The component library had to be extended to support them before the screen could be built.

The dashboard is live in the React platform.

07 Reflection

What I learned

  1. A dashboard is the order of the questions

    The old dashboard wasn't badly designed; it answered a different question — how much happened. When approval drops, a payments lead asks a chain of questions: which method, which provider, which market, which bank. The layout follows that chain, from the headline rate down to the MID. That is also the test for what stays: a panel that answers none of those questions is decoration, however good the data in it.

Next case study · 6 min read No new features allowed. Every improvement had to come from structure. Migrating a rule engine to React without changing what it does.