Redesigning a payment-operations console
An internal tool the team used to turn payment methods and networks on and off in real time. When a provider went down mid-sale, someone had to act fast and confidently. I redesigned it so the tables, data and permissions were clear, and so no one could break something costly just because the interface was hard to read.
Executive summary
Behind the storefront sat an internal console for managing payment methods, networks and operations. The team used it to switch payment options on and off in real time, which mattered enormously during big sales like Black Friday: if a provider went down, someone had to spot it and reroute to another method fast. The tool worked, but it was hard to read and easy to get wrong. As the sole UX designer, I led a systems-led redesign of its tables, data and permissions so that every action was clear, its consequences obvious, and the high-risk ones protected.
Project context
This was the control panel for payments. Product and operations people used it to turn different payment methods on or off depending on what was working and which providers were up or down. During large-scale sales it became mission-critical: if a heavily-used method like cards went down, the team had to switch it off and redirect customers to another method, quickly, without dropping sales.
It was a powerful tool doing important work, but it had never really been designed. It was the kind of internal system that gets built to function and never gets the care a customer-facing product would.
Role & ownership
I was the only UX designer, so I owned the redesign end to end, working closely with the product and operations people who lived in the tool, and with engineering on what was feasible. I:
- Mapped how operators actually used the console, and the moments where a wrong move could cost real money.
- Redesigned the core tables and data so the state of every payment method was readable at a glance.
- Reworked the permissions and the high-risk actions so the consequences of a change were never a surprise.
- Partnered with engineering to keep the redesign grounded in what the existing system could support.
Problem
The console was dense and hard to parse. Tables, permissions and status sat together without much hierarchy, so it took real effort to work out what a given control did, who it applied to, and what would happen if you changed it. In a calm moment that's friction. In the middle of a Black Friday outage, it's a genuine risk.
The core fear was simple, and the one I designed against: I never wanted someone to break something, or take a payment method down for the wrong audience, simply because the interface was confusing and they didn't fully understand the action they were about to take.
Constraints
- High stakes, no room for error. The tool sat on top of live payments, so a confusing control wasn't just annoying, it could cost sales.
- An existing system to work within. This was a redesign of something already in use, so changes had to fit what engineering could realistically support.
- A small internal audience, doing critical work. Few users, but the cost of getting their experience wrong was disproportionately high.
- A team of one. As the only designer, I had to be pragmatic about where the redesign would make the biggest difference.
Understanding the operators
Because this was a tool for a small, expert internal audience, the research was about getting close to how they actually worked rather than running broad studies. I spent time with the product and operations people who used the console, walking through how they managed payment methods, what they reached for under pressure, and where the existing design slowed them down or made them second-guess an action.
That surfaced the real shape of the problem: it wasn't missing features, it was legibility. The information was all there, just not arranged so a person could read the state of the system and act on it with confidence.
Key decisions
I rebuilt the Manage Payment Methods table around the columns that actually matter - display name, access, device and status - so an operator could scan the whole payment estate and see what was live, for whom, in seconds.
A clear online / offline indicator on every method meant the most important question during an outage - what’s up and what’s down - was answered at a glance.
Settings like 3D Secure (On / Off / Smart) carried a short explanation of what each option actually does, so operators weren’t making security decisions from memory or guesswork.
Anything consequential got a double-confirmation and a clear statement of what it would do. ‘Hide’ was favoured over hard deletes, keeping risky moves reversible, with a way to see and restore hidden methods.
Access (who a method is for) and device scope (mobile, desktop or all) were pulled out as explicit, readable controls, so it was always obvious exactly who a change would affect.
I introduced an action / change log that recorded every change - who did what, and when. The team could see exactly what had been adjusted without having to chase the whole group who had access, which made fast-moving sale-day changes traceable and far less stressful.
We built distinct access levels - some people could view, others could edit - and made it very clear who held which. That protected the settings from both genuine mistakes and any malicious intent, so the people with edit rights were always a deliberate, visible group.
Design response
I worked the structure out on paper first, getting the hierarchy and the safety logic right before any visual polish. These early wireframes show the thinking:
Impact
The redesigned console gave operators a tool they could trust under pressure: the state of every payment method readable at a glance, the consequences of an action spelled out, and the riskiest moves guarded by confirmation and made reversible. A change log meant every adjustment was traceable to a person and a time, and clear view-versus-edit permissions kept the settings safe from both mistakes and misuse. It turned a tense, error-prone task into something the team could do quickly and confidently during the moments that mattered most, like a provider dropping mid-sale. As an internal tool the wins were mostly in confidence and safety rather than headline metrics, but that was exactly the point: the best outcome here is the costly mistake that never happens.
Reflection
This project shaped how I think about internal tools. They’re easy to neglect because few people use them, but those people often carry a lot of responsibility, and a confusing interface quietly transfers risk onto them. Designing for clarity here wasn’t a nicety; it was a safety measure.
It also reminded me how much good systems and data design can do without any visual flourish. Most of the value came from hierarchy, plain language and well-placed friction in exactly the right spots.