A tool that looks simple, until you're the one accountable for the money.
A mid-size company hands corporate cards to a few hundred employees. Someone has to decide who gets a card, how much each person can spend, whether a payment goes out this week, and what happens when an account slips past due. At SVB, that someone opens SVB Go.
This project reimagines the admin portal behind it, built as a single, fully-wired prototype, to SVB's real brand, and pushed to production fidelity so the flows could actually be tested rather than just admired.
The interesting problem was never drawing screens. It was untangling a workflow where a single missed approval or a wrong limit is real money, and doing it inside a brand system that fights accessibility at every turn.
How do you give a finance lead total control over other people's spending, without making control feel like friction?
Money moves on trust
Employees submit payments; the admin releases them. Approving blind, with no evidence in view, is how errors and fraud slip through.
Signal buried in noise
Past-due accounts, cards nearing limits, requests waiting on a decision, all easy to miss in a wall of 220 rows.
Brand vs. accessibility
SVB's signature cyan can't meet the highest contrast standard. The two requirements physically collide.
A double-diamond, run honestly.
Diverge to understand the real job, converge on the sharpest problem, explore widely, then ship something that holds up when you actually click it. No automated browser to lean on, so every flow was validated by using it.
Discover
DivergeMap the admin's real jobs, study SVB's brand from source, audit the domain: what actually happens in a corporate card program.
Define
ConvergeRank the jobs by stakes and frequency. Name the one that everything orbits (payment approval) and frame the guiding question.
Develop
DivergeDesign the approval flow, restructure the IA, prototype real interactions, and stress-test decisions against edge cases.
Deliver
ConvergeBuild to production fidelity, snap every token to the brand, and take the whole thing to WCAG AAA where the brand allows.
Frame the user
Who the admin is, and the four jobs they can't avoid.
Empathize
Says / thinks / does / feels, what the role actually feels like.
Prioritize
Insights, how-might-we, and the thing to protect above all.
Architect & design
IA, the approval flow, and the decisions behind each cut.
Systemize
Brand fidelity, accessibility, and craft at the detail level.
Grounding the design in evidence, not assumptions.
Before a single screen, I needed to understand three things cold: the job the admin actually does, SVB's real brand system, and exactly where the existing experience broke its own promises. Here's how I got there and what it told me.
What does the card admin actually do, in what order, how often, and where does a wrong move cost real money?
What is SVB's genuine brand system, the exact palette and type, rather than a lookalike approximation?
Where does the current flow break its own promises: dead ends, mismatched data, buried signal?
How do mature enterprise tools pattern approval queues, at-risk surfacing, and role-based access?
Domain & workflow modelling
Mapped the corporate-card program end to end: the roles (PCAM, Admin, User), the money path (submit → review → release), the account lifecycle, and every point where a wrong decision has a financial cost.
Brand forensics, from source
Pulled the exact palette from SVB's official logo SVG and brand-guidelines PDF rather than eyeballing it. Identified Neue Montreal as the brand face, and its commercial licensing constraint, up front.
Heuristic & flow evaluation
Walked every screen and followed every link the way the admin would, logging each break against Nielsen's heuristics: system status, match to the real world, error prevention, consistency.
Comparative reference scan
Studied how established finance and admin platforms handle the same jobs (approval queues with inline evidence, at-risk surfacing, role-based access) to separate genuine conventions from cargo-cult patterns.
The highest-stakes, highest-frequency task, approving payments, had no home in the product.
Make approval a first-class, default surface. Everything else is context around it.
The interface made promises it didn't keep, a "10 pending approvals" link led to a page with no approvals, and alert counts didn't match the rows they opened.
For someone moving other people's money, honesty is the primary trust lever. Every link and count must hold.
Signal was buried, six at-risk cards hidden inside a 220-row roster, with no way to isolate them from an alert.
Alerts must carry their filter all the way to the destination, with a clear way back.
Two different concepts of "activity" (one per-cardholder, one program-wide) were conflated behind a single link.
Separate them structurally and name them distinctly, or the whole IA reads as duplicative.
Brand and accessibility were on a collision course, SVB's signature cyan can't meet the strictest contrast bar.
Resolved by role: cyan stays for scale and decoration, small compliance-critical text runs in the deeper Bandana blue instead, so nothing readable falls below AA.
Where this research ends, and what comes next
This exploration is built on secondary research, domain modelling, and heuristic evaluation: rigorous, but not a substitute for hearing from the people who live in the tool. The next layer is moderated sessions with practising card admins to validate the assumptions I'm making here: that 85% is the right "nearing limit" threshold, that the evidence set on the approval screen is complete, and that the alert model matches how they actually triage a morning. I've noted these as open questions rather than settled facts.
Meet the Primary Card Account Manager.
Not a banker, a finance or ops lead at the company itself, running the card program alongside a dozen other responsibilities. This is who the product answers to.
Marie Conti
"I don't need a dashboard to admire. I need to know what needs me today, deal with it, and get back to my actual job."
Motivations
- Keep every account in good standing, no surprises at statement close
- Release legitimate payments fast, catch the wrong ones
- Be able to prove why any decision was made
Frustrations
- Approving payments with no supporting evidence in view
- Hunting through 220 rows to find the 6 that matter
- Links and alerts that promise something and lead nowhere
Primary goals
- Clear the approval queue with confidence
- Spot at-risk accounts before they slip
- Issue and adjust cards without a support call
Success looks like
- In, resolved, out, in minutes, not a morning
- Zero payments approved she couldn't explain
- Never surprised by a past-due account
What the role actually feels like.
Before deciding what to build, I mapped the admin's headspace across a normal week, the gap between what they say and what they quietly feel is where the design opportunities live.
Says
- "Is this payment actually legit?"
- "Just show me what's overdue."
- "I approved it, where's the record?"
- "Why does this link go nowhere?"
Thinks
- "If I get this wrong, it's real money."
- "I don't have time to read every line."
- "I need to trust what the screen tells me."
- "There's probably something I'm missing."
Does
- Checks the dashboard first thing, in short bursts
- Expands a payment to read the memo & docs
- Filters the roster to find at-risk cards
- Cross-checks amounts before releasing money
Feels
- Accountable, the buck stops here
- Time-pressured, pulled in many directions
- Wary of approving something blind
- Reassured when the tool is honest & clear
Three insights that shaped every screen.
Approval is the product
Every other feature is context around one act: releasing money. If that flow isn't trustworthy and fast, nothing else matters.
Honesty beats density
An admin managing other people's money needs the interface to never lie, not by a broken link, not by a count that's off by three rows.
Cut the helpful-looking noise
Redundant shortcuts and decorative panels tax attention. The strongest edit was often removal, not addition.
How might we let the admin release money with total confidence, inspecting the evidence in one motion, while surfacing exactly what needs them, and nothing that doesn't?
Eight screens, one lean spine.
The sidebar stays disciplined, only the destinations the admin needs daily. Depth lives one level down, reached through context rather than clutter.
The daily triage screen: needs-attention alerts, spend, and recent activity.
220-person roster with balance, limit, utilization & status filters.
Pending approvals (default), single, auto & accounts.
View & bulk-download up to 24 months of history.
One cardholder's transactions & authorizations.
Issue cards, set limits & delivery, track requests.
Portal users, roles (PCAM / Admin / User), access.
Program-wide feed. Reached via "View all", deliberately kept out of the sidebar.
The path that had to be flawless.
Approving a payment is the task the whole product exists to serve, so I mapped it end to end before designing a single screen: where the admin enters, what they need to see before deciding, the decision itself, and a safety net on both outcomes. The flow is what drove the two P0 fixes, evidence-before-decision and a reversible action.
Why the flow matters: mapping it exposed the two riskiest gaps before pixels existed. The admin was being asked to decide without the evidence in view, and once they decided, there was no way back. Every screen downstream was designed to close those two gaps, which is why "inspect before deciding" and "undo on every outcome" became the non-negotiables.
The thinking behind the cuts.
Make approval the center of gravity
The dashboard advertised "10 payments pending approval" and linked to a Payments page where those ten payments didn't exist anywhere. A dead end that survives a hundred polished mockups, because each screen looks fine alone; it only shows when you wire it and follow your own links.
I made Pending Approvals the default tab and designed the interaction around one rule: you should never approve money you can't inspect. Each payment expands in place to reveal requester, memo, funding account, reference and supporting documents. Approve confirms cleanly; Decline requires a reason, so a rejection never becomes a mystery support ticket.
Cut the helpful-looking, do-nothing links
An "Account Information" panel carried three tidy shortcuts. Two of them just re-navigated to pages already permanently in the sidebar, pure duplication dressed as convenience. The third carried a live count, so it earned its place as an alert.
I removed the two redundant links and reframed the survivor as an actionable alert, not a nav shortcut. Every element is a small tax on attention; links that do nothing the sidebar doesn't are noise wearing a helpful costume.
Make alerts carry their filter all the way
Clicking "past due" used to dump the admin into all 220 rows and a shrug. Now each alert carries its filter to the destination, with a visible chip explaining why you're seeing a subset and a one-click clear.
This surfaced a data-integrity bug worth owning: "nearing limit" had been wired to a flag that actually meant "limit recently increased", nearly the opposite. I recomputed it from real utilization (balance ÷ limit ≥ 85%) and reconciled every count, so the dashboard number and the rows you land on finally agree. Copy that lies, even by three rows, erodes trust in everything else.
Build the program-wide Activity Log
"Recent activity" is program-wide, mixed people, mixed events. But "View all" pointed at the single-cardholder Card Activity page, dropping you into one random person's transactions.
Rather than the cheap repoint, I built a proper Activity Log: a filterable, time-grouped feed of every event across every cardholder, each row routing intelligently to where you'd go next. Kept out of the sidebar so it doesn't compete for daily attention.
What the decisions produced.
Real screens from the working prototype, each tied to the reasoning behind it. Every screen is fully wired and built to SVB's brand with the exact palette and type.
Get in, see what's on fire, act
The triage screen. Each alert deep-links to the exact filtered view, so "6 nearing limit" lands you on those six, not all 220 rows.
Never approve money you can't inspect
The product's center of gravity. Rows expand to show docs before you release funds, and every action has an undo window, the Sev-4 fix.
Isolate the signal, sort it, act
Filtered from a dashboard alert, with a chip explaining why. Real column sorting (shown on Balance) replaced a header arrow that used to do nothing.
The riskiest action gets the strongest guard
Bulk approve once committed in one click. Now it shows count, total, and every cardholder before any money moves, added straight from the heuristic findings.
Explore the real thing
The screens above are captured from the working build. Open the live, fully-wired prototype to click through all eight screens yourself.
I graded my own work against Nielsen's ten.
Before calling anything finished, I ran a full expert inspection of the prototype, walking every screen and following every link the admin would, and logged each usability violation against Nielsen's heuristics, rated 0–4 for severity. Nineteen issues surfaced, plus four accessibility items. Here's the honest scorecard.
Expert inspection
One evaluator, every screen, following real task paths, not a scripted click-through.
Nielsen's 10
Each violation mapped to a specific heuristic and screen, so every finding is traceable and fixable.
Severity 0–4
From cosmetic to catastrophe, weighted by frequency, impact, and, for a money tool, real-world risk.
Prioritised backlog
A P0/P1/P2 roadmap, so remediation followed risk rather than whatever was easiest.
You could move money with no way to take it back.
Approving a payment, declining one, suspending a card, and removing a user were all immediate and irreversible, and bulk approve, the riskiest action of all, had the weakest guard. In a tool whose entire job is releasing other people's money, a single mis-click had no safety net. Everything else in the report mattered; this is the one that had to be fixed before anything shipped.
Then I fixed every one of them.
A findings report nobody acts on is just a nicely-formatted complaint. I worked the backlog top-down by severity and closed all nineteen issues plus the accessibility items, then proved it, rather than assuming it.
Approve, decline, suspend, and remove were instant and irreversible. Bulk approve released many payments in one click with no confirmation.
An undo window on every reversible action; a pre-commit modal for bulk approve showing count, total, and each cardholder before any money moves.
The New Card and Add User forms had no validation. Removing a user or suspending a card gave no warning and named no one.
Required-field validation with inline errors; destructive actions now name the person and spell out the consequence before you confirm.
Column headers showed a sort arrow that did nothing, and only on one table. Deep screens had no way back but the sidebar.
Real, reusable sorting across all eight data tables; breadcrumbs on every drill-down screen; a focus trap and live announcements for screen-reader users.
The evaluation also flushed out live bugs that only surface when you actually use the thing: a dashboard alert that linked to a page where its payments didn't exist, a "nearing limit" filter wired to the wrong flag, and a statements filter that showed every cardholder regardless of the status selected. Each got traced to its root and fixed, because in a money tool, a count that's wrong by three rows quietly erodes trust in every other number on the screen.
Brand fidelity, done from source.
The brief was unambiguous, do not deviate from the brand. So I didn't guess. I pulled the palette from SVB's official logo SVG and brand-guidelines PDF, then snapped every token to an exact value.
Two things stuck.
The hardest enterprise-UX problems aren't visual.
They're about what to remove and what to make honest. The redundant links, the dead-end approval, the two-kinds-of-activity confusion, none are pretty-pixel problems. They're clarity problems. And clarity is exactly what someone managing other people's money actually needs.
The best critique of my work was my own.
Before calling anything done, I ran a full heuristic evaluation and found the one catastrophe-level flaw myself: money moving with no way to undo it. Catching what you can before anyone else has to, then proving the fix, is the difference between a demo and a product.