Case Study — B2B Product Design
How I designed an enterprise spend management platform end-to-end — without a proper brief — and delivered something the CEO now posts about publicly.
Company
My role
Deliverables
Domain
🔥 Outcome
Shipped and live. The CEO of Vroozi actively showcases the product on LinkedIn. A Lead Solutions Engineer at Zip called it publicly: "Platform looks great "
01 — Context
Vroozi is a B2B spend management platform built for mid-market and enterprise companies. It digitizes the entire procurement and vendor invoice management process — from purchase requests to accounts payable — using AI and ML to automate what traditionally required entire finance teams working manually in spreadsheets.
The platform serves two distinct user types: employees who initiate and track purchases, and admins — finance teams, controllers, CFOs — who approve, manage, and report on company-wide spending. That dual-role structure turned out to be one of the defining challenges of the entire project.
The client came to us with a rough production version — functional but visually raw, and by their own admission, hard to learn and harder to love. They wanted it rebuilt. Properly.
02 — The Challenge
Most B2B redesigns come with a discovery phase: user research, flow audits, a defined scope. Vroozi didn't. The client was budget-conscious and wanted to validate the collaboration before committing to a longer engagement. That meant we were asked to jump directly to UI design — figuring out the experience and the visual execution simultaneously.
We were asked to design both the UX and the UI in a single phase, without a dedicated discovery sprint. For a platform with 11 distinct flows, dual user roles, and deep financial domain complexity — this was the hardest version of this project.
Constraint 01
Domain complexity
Spend management isn't intuitive territory. Procurement flows, invoice automation, account coding, and catalogue management required depth I didn't come in with.
Constraint 02
Dual role architecture
Almost every flow had an employee version and an admin version. Two different mental models, two sets of permissions, one coherent design system to hold them both.
Constraint 03
No wireframes first
The process we'd normally follow — wireframe, validate, then apply visual design — was compressed into one phase. Every screen had to earn its structure and its look at the same time.
03 — Process
Without a discovery phase, I had one tool available: extended stakeholder access. I requested deep-dive sessions with Shaz (the CEO) and his development team — longer and more technical than a standard kickoff. The goal wasn't just to understand what they wanted built. It was to understand how the existing product actually worked, flow by flow.
After those sessions, the rest of my team was still unclear on large portions of the product. I had what I needed to begin. That gap in comprehension between me and the rest of the team taught me something about how I process complex systems — I absorb domain knowledge best through conversation with builders, not through documentation.
"The rest of my team wasn't able to understand anything even after the call. I had what I needed to begin."
The catalogue edit flow was the hardest moment. It sat at the intersection of finance logic and technical architecture — deeply unfamiliar territory. Rather than guess, I requested a second technical session specifically with the dev team to deconstruct that flow before proposing an alternative. That instinct — to go back to the source rather than paper over confusion — saved us significant rework.
04 — What I Got Wrong (and Right)
In the early phases, I assumed finance and procurement professionals would want rich data visualization — charts, graphs, dashboards with visual summaries of spending data. It felt like the obvious design move for a platform built around financial insight.
It was wrong. These users — controllers, AP teams, CFOs — spend their days in Google Sheets and Excel. Dense, scannable data tables are their native language. Visual dashboards felt distracting to them, not clarifying. They needed clarity, not beauty.
Catching this assumption early — and correcting course before it affected the majority of flows — was one of the most important decisions on the project. It shaped the entire visual language: clean typography, structured layouts, information density over decoration.
❌ Initial assumption
Finance users want visual dashboards
Charts and graphs would make spending data more accessible and easier to interpret at a glance.
✓ Corrected direction
Finance users want clean, dense tables
Their mental model is rooted in spreadsheets. Scannable data, clear hierarchy, minimal visual noise — that's what earns trust with this audience.
05 — The Output
Over the course of the project, we designed the full product — not a partial redesign. Every flow an employee or admin would encounter was considered, structured, and visually resolved.
01
Home
Both roles
02
Accounts payable workspace
Complex · Admin
03
Product search
Employee
04
Product details
Employee
05
Shopping cart & checkout
Dual role
06
Product compare
Employee
07
Invoice document management
Complex · Admin
08
Content management
Complex · Admin
09
Create catalogue / quote
Dual role
10
Edit catalogue
Most complex · Admin
11
Custom field management
Complex · Admin
06 — Outcome
The redesigned platform went live. Shaz Khan, Vroozi's CEO and Co-Founder, actively showcases the product on LinkedIn — including the Accounts Payable Workspace that was among the most complex flows we redesigned. That's a public endorsement most designers never get documented evidence of.
The feedback from users and the broader market was consistent with what the design was aiming for: clean, easy to scan, trustworthy. Exactly the qualities finance professionals need from a tool they'll use every day to manage millions of dollars in company spend.
07 — What I'd Do Differently
This project worked. But it worked harder than it needed to. With the benefit of hindsight, two things would have made it smoother:
Scope
One complete flow at a time, not screen by screen
Designing across 11 flows in parallel created coordination overhead and made it harder to maintain consistency between related screens. A flow-by-flow approach would have produced cleaner handoffs and a more coherent system.
Process
Wireframes before the design system, not both at once
The compressed brief forced us to validate structure and apply visual design simultaneously. Separating those phases — even slightly — would have reduced the number of times we had to revisit decisions that should have been locked earlier.
Both of these are pushes I'd make on a future project — not complaints about this one. The constraints were real and the outcome was good. But growth means knowing what you'd change.
08 — Reflection
Vroozi is the case study I point to when someone asks whether I can handle complexity. Not because the final product is perfect — it isn't — but because the conditions were genuinely hard. No discovery. No wireframe phase. A domain I had to learn from scratch. Tight timelines. Dual user roles. Eleven flows.
And at the end of it, a CEO is using the product we designed as proof of what his company can do. That's not luck. That's what happens when you absorb the problem deeply enough to design through ambiguity rather than around it.
The skills that made this work aren't visual ones. They're diagnostic — the ability to ask the right questions, recognize when an assumption is wrong, and adapt before it costs you the project.