Client project · B2B payroll
PayRun
A web platform that lets a CPA review and run payroll for many client businesses, from pay stubs to quarterly tax filings. I own the product design; an engineering partner builds it.
- Role
- Product designer (discovery to UI)
- Platform
- Web app (desktop-first), mobile views in design
- Tools
- Figma, stakeholder interviews, service blueprints
- Timeline
- 2026 – In progress
The problem
Our user is a CPA who runs payroll for many small businesses. Everything arrives by email and phone call, and the numbers get typed into an aging desktop tool. He tried the big platforms, and his reasons for leaving kept coming back to three things:
- Scattered. No single view of where every client stands.
- Crowded. Wide tables that are hard to read at a glance, and page after page just to add one employee.
- Wrong user. Built for one business owner running their own payroll, not a CPA managing many.
Two design goals
Clear hierarchy. Everything he needs on one screen, with the most important thing read first.
Follow the CPA’s mental model. When he talks through his week, it is always which client first, then which employee, then which period. So PayRun is organized the same way: client → employee → pay period.
“Whose payroll needs me right now?”
The day starts at the client list, sorted by process-by deadlines, not paydays. Paychecks take two days to land, so a Friday payday is really a Wednesday deadline, and today’s work rises to the top.
Step inside a client
One click deep, everything about one business is in one place: company details, roster, runs. Nothing about a client lives anywhere else.
Down to the person
The calendar does the remembering. Only the first paycheck date is set by hand. After that, runs schedule themselves from the pay frequency.
Review is the main event. The full calculation is previewed before anything is finalized, because the real job is confirming this period looks like last period.
Finalized runs become receipts. Drafts invite editing; finalized runs read as records.
Creating a run: one form on desktop, four steps on a phone
On desktop the whole form sits in one modal, with tax fields pre-filled from the W-4, so most of it is confirming, not typing. On a phone the same form becomes four steps with a stepper. Same data, same order, different pacing.
The same structure on a phone
The hierarchy stays the same: client → employee → pay period. Tables become cards, and the sidebar folds into a bottom bar. Mobile is designed; the desktop app is what he tests today.
Quarter end, without retyping the calendar
A CPA’s year runs in quarters, so the date filter has one-tap quarter presets next to the custom range. Filings build from finalized runs only, so a form can never be built on half-finished data.
Filings: his mental model, plus a batch view
The first version was one flat list of every form due. When I walked him through it, he corrected me: here too he thinks per client. So the page has both views: By Client, grouped the way he thinks, and List, sorted by due date for filing days.
Working with engineering from day one
My design partner on PayRun is the engineer building it. Research and interviews came first, and the flows and UI that followed are shaped by the real data model.
Where it stands
PayRun is a work in progress, tested hands-on with the CPA it’s designed for. It’s scoped in three phases:
- Phase 1 (in progress). The core tool for one CPA to run payroll across all of his clients.
- Phase 2. Clients enter their own employee and hours data instead of emailing it.
- Phase 3. A product other CPAs can run their practices on.