Senior Product Designer with five years of end-to-end product design experience in fintech and B2B SaaS (Business-to-Business Software as a Service). Owns product direction across two products, leads a team of two designers, and founded a design system used by design and engineering. Strongest in ambiguous, systems-heavy problem spaces: discovery and problem framing, untangling complex workflows, and building scalable design solutions from discovery through delivery.

Volopay helps finance teams control company spend across four core workflows: corporate cards, vendor bill payments, reimbursements and accounting. I worked on design across all four workflows as the product matured from an early, MVP tool into a platform built for mid-market and enterprise finance teams.

This case study covers that evolution: what broke at scale, what we rebuilt, and the compliance-automation layer that tied the four modules together.

The MVP solved a real pain point: no more manual expense spreadsheets. But it was built for small teams making a handful of decisions a month. As customers scaled to hundreds of employees and thousands of monthly transactions, the product's early shortcuts turned into recurring cracks across research and support tickets.

What we built: Corporate Cards gives finance teams a way to extend controlled spending power to employees, instead of routing every purchase through reimbursement. Each card carries its own limits and restrictions, set by the admin issuing it.

What we built: Bill Pay is how finance teams pay vendors and suppliers directly from the platform, domestically and internationally, across multiple currencies. It replaces manual bank transfers and spreadsheet tracking with one place to review, approve, and pay invoices.

What we built: Reimbursements is how employees get repaid for expenses they've covered themselves: submit a receipt, route it for approval, and track it through to payout.

What we built: Accounting is how data from Cards, Bill Pay, and Reimbursements gets synced to the company's accounting software, mapped to the right categories and ledgers automatically, instead of finance re-entering it by hand.

What we built: My Volopay is the employee's personal home base in the product: their own card activity, reimbursement claims, and pending tasks, all in one place. It exists so employees never have to ask "where's my stuff?" or go through finance just to check on their own activity.

Why it mattered: it's a small module by scope but it directly reduced support load and gave every employee, not just finance admins, a reason to open the product regularly, which helped adoption to the rest of the Platform era.

Volopay is a spend management platform built for finance teams, combining all workflows into a single product. As the company scaled, so did the surface area finance teams had to manage, with increasingly complex compliance sitting behind every action. That growth is exactly what made a consistent design language non-negotiable.

Before Fly, Volopay's UI had grown the way most fast-moving fintech products do: organically, and inconsistently. Different workflows across Corporate Cards, Bill Pay, and Reimbursements had been designed at different times, by different people, under different deadlines. There was no shared source of truth.

This wasn't just a visual problem. Inconsistent patterns were quietly making it harder for users to get from Point A to Point B, adding friction to tasks that should have felt instant and obvious.

We knew patching individual screens wouldn't fix this. The product needed a foundational layer everything else could be built on top of.

With the problems clear, we set out with a few concrete goals for Fly:

The name isn't decorative. Volopay takes its root from the Latin verb volo, meaning "to fly." It's the same root that gives us words like volatile and volley, all carrying that same idea of movement, lift, and speed. When we set out to name the design system, we wanted something that echoed the company's own name rather than sitting beside it as an unrelated brand.

Fly became the natural choice: a system built to help the product (and the people building it) move faster, with less friction, and with a shared sense of direction. It was also, quietly, a nod to what we wanted the system itself to do, letting designers and engineers stop rebuilding the same wheel and start moving quickly across the product.

We chose Atomic Design as our methodology because it mirrors how a spend management product actually behaves: small, well-defined pieces that combine into increasingly complex, real workflows. Rather than treating it as an abstract framework, we mapped each layer directly onto Volopay's existing product surface.

Working through the hierarchy this way forced an important discipline: we couldn't jump straight to solving a screen. Every new pattern had to justify itself at the right layer first, which meant far fewer one-off components sneaking into the product over time.

A look at how the building blocks came together across real screens.

We didn't build in isolation. Once we had working drafts of the core library, we ran iterative feedback loops with:

This loop of feedback and iteration meant Fly wasn't handed down as a finished artifact. It was shaped by the people who'd actually have to live inside it every day.

Fly wasn't just a component library. It was the first time Volopay's product had one visual and interaction language across every module. Beyond the metrics, what made this project meaningful was watching a two-person effort quietly become the default way the entire design and engineering org built product: a small, deliberate decision at the Atom level rippling out into a faster, more coherent experience for every Volopay user.

Volopay's mobile app exists for one reason: to let finance move at the speed of real life. Approvals shouldn't wait until someone's back at their desk. A claim from a work trip shouldn't have to wait until you're home. The mobile app is, in effect, a portable version of "My Volopay" — the section of the web app centered on your activity, your pending actions, your approvals, your claims — stripped down to what you need when you're away from a desktop.

The MVP app didn't live up to that promise. It was functional in the sense that the APIs worked, but it had a compounding set of issues across the whole app:

Because I was working across every flow rather than owning one narrow piece, my process looked less like a single linear design sprint and more like continuous triage and rebuild:

Not a coat of paint. Every flow was rebuilt from the logic up.

The home screen needed to answer one question immediately: what needs my attention right now? Pending approvals, recent activity, and required actions were restructured to be scannable at a glance rather than buried under general navigation.

Approving spend from a phone needed to feel as trustworthy as approving it on desktop: enough context to make a confident decision, without needing to tap through to five other screens first.

This is the flow that matters most for the app's "finance on the go" promise: someone on a work trip capturing and submitting a claim in the moment, rather than saving receipts to deal with later. The v1 version of this had too much friction for a moment when the user has neither the time nor the patience for it.

This project was less about a single clever redesign and more about raising the bar for what the mobile app needed to be, and being willing to rework things, including work already shipped, when they didn't meet that bar. The result is an app that actually fulfills its purpose: letting people handle finance in the moments when they can't get to a desktop, without the app itself getting in the way.

OXO is an outbound execution platform that takes a sales team from "who should we reach?" to "they replied and want a demo", inside a single connected system. We defined the core mental model, designed the workflows that let a team run outbound at scale without losing quality control.

This wasn't a redesign. There was no existing product, no legacy screens to inherit, and no established patterns to lean on. The job was to take a genuinely fragmented category, one tool to find leads, another to write copy, another to send, another to track, and design a single operating system that could hold all of it together without becoming a maze.

Sales teams running outbound today stitch together 4 to 6 separate tools, and lose context at every handoff between them. The brief was to build one system where a team defines a campaign once, and everything downstream flows from that single definition.

The hard part wasn't any single screen. It was that this is a system design problem before it's an interface design problem.

Before designing anything, I looked at how sales teams actually run outbound today, not the ideal version, the real one.

Organized OXO around one continuous flow, where each module has a single job and feeds directly into the next:

What it does: Sets up the workspace once — connecting mailboxes, defining the company's ICP, and capturing the messaging context every downstream module reuses, so a team never has to repeat itself.

What it does: The shared knowledge base — leads, accounts and reusable assets live here independently of any campaign, so nothing disappears after a single send.

What it does: Where outreach logic is defined — sequences, messaging angles and rules that turn a strategy into something repeatable across campaigns.

What it does: The launch surface — define a campaign once across four steps (overview, audience, sequence, readiness check) and everything downstream flows from that single definition.

What it does: Where replies land — Reply Intelligence pre-classifies every response, so the inbox reads as a prioritized queue instead of an undifferentiated pile.

What it does: The rep's daily to-do — every action a campaign generates (reviews, follow-ups, replies to send) surfaces here as a prioritized queue, so a rep always knows exactly what to work on next.

The core lesson from OXO was that in a 0-to-1 system this interconnected, the interface design is downstream of the information architecture, and the IA is downstream of a small number of conceptual distinctions that have to be gotten right early. Getting those distinctions right made nearly every subsequent screen easier to design, because there was always a clear, defensible answer for where a piece of information belonged and why.