Designing a Dashboard for Volopay

The design problem

Spend-management dashboards fail in a predictable way: they try to show everything at once and end up legible to no one. Finance operators need an instant sense of company-wide spend health. Card holders need to know their balance and limits. Approvers need to see what's pending. These are three different jobs, often handled by the same person in a fast-moving startup.

The challenge was to design a dashboard that could serve these overlapping needs — surfacing the most critical signals at a glance while keeping the interface clean enough that someone who isn't a finance professional doesn't feel shut out.

Information hierarchy

Raw spend data is meaningless without context. The dashboard needed to distinguish signal from noise — total balance, card-level limits, recent transactions — without flattening everything into equal weight.

Card-grid legibility

Volopay's virtual and physical card grid is central to the product. Representing multiple cards with varying balances, statuses, and limits required a component that scanned fast and scaled cleanly.

Density vs. clarity

Financial dashboards tend to pack in too much. The goal was a layout that felt comprehensive to a power user but didn't overwhelm someone checking in once a week.

Iteration discipline

The brief had two distinct tasks. I completed both, then identified on my own that the first version of the card grid could be stronger — and revised it unprompted.

The approach

I started with an exploration pass — mapping out how Volopay's product model works, what data is available, and which pieces of it a user would care about in the first five seconds on the dashboard. Spend-management products live or die by how well they translate raw numbers into a sense of control.

The brief was split into two tasks. Task 1 focused on the core dashboard layout. Task 2 extended into a supporting view. I treated them as a connected system rather than two separate deliverables.

After submitting both tasks, I went back to the card grid from Task 1. I felt the visual treatment could carry more information density without adding cognitive load — so I redesigned it. That iteration became V2.0 and V2.1.

Card grid V2.0 — initial card component redesign

Card grid V2.1 — refined card component layout

V2.0 (left) tightened the card layout; V2.1 (right) refined it further — cleaner type hierarchy, more breathing room at the limits row.

Card grid V2.1 — dark card variant and full grid view — The full card grid in V2.1 — handling multiple cards, varied states, and balance visibility in a single scannable row.

The final dashboard

Dashboard V2 pulls the refined card grid into the wider layout context. The top section leads with company-wide spend health — total balance, available budget, recent activity — so an operator can assess the situation without scrolling. The card grid sits below as the primary navigational element, letting card holders jump directly into their own spend view.

The layout choices were deliberate: left rail for navigation and quick stats, main content area for the spend timeline and transactions, card grid as a persistent anchor that grounds the whole experience in the actual payment instruments people use.

Volopay Dashboard V2 — full layout with spend overview, card grid, and transaction feed — Dashboard V2 — spend health at the top, the revised card grid mid-screen, and a transaction feed that gives context to the numbers.

What I learned

The most useful decision in this project wasn't in the brief — it was going back to the card grid after both tasks were done. The first version worked. The revised version was better. That gap only became visible once I had the full layout context to compare against.

Lead with control, not data

The dashboard's job isn't to display all the numbers. It's to give the user the feeling that they have visibility. Those are related but not the same thing.

Components carry the design

The card grid set the visual grammar for the whole product. Getting that component right before scaling the layout out saved significant revision cost later.

Go back unprompted

The revision to V2.1 wasn't asked for. Doing it anyway — and being transparent about the reasoning — is how design judgment earns trust.