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
PayRun employee page on a laptop held in one hand: upcoming payroll preview and run history

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:

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.

PayRun Clients page: total clients and payroll-due-soon cards above active and inactive client tables
The client list: 29 businesses at a glance, with the payrolls due this week counted at 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.

Client detail page for Meridian Construction LLC: company overview, employee stats, and the employee list with withholdings and net pay
The client detail: overview, roster, and every employee’s numbers, one room per client

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.

Employee detail page for Jane Smith: upcoming payroll with full withholding breakdown, itemized payroll run history with draft and complete statuses, and year-to-date summary
One employee, whole story: the next run scheduled and previewed, 36 past runs as records, YTD building underneath

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.

Create Payroll Run modal on desktop: run details, earnings, tax information auto-filled from the W-4, and deductions in one scrolling form
Desktop: all four sections in one modal, tax fields auto-filled from the W-4
Mobile step 1 of 4: run details with run type, pay period, pay date, and pay frequency
Step 1: run details
Mobile step 2 of 4: earnings breakdown with gross, hours, overtime, bonus, PTO, and reimbursements
Step 2: earnings
Mobile step 3 of 4: tax information with filing status and withholding auto-filled from the W-4
Step 3: tax info, auto-filled
Mobile step 4 of 4: editable deductions for 401(k), health insurance, and post-tax items
Step 4: deductions

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.

Mobile Clients page: total clients and payroll-due cards above client cards
Clients on a phone
Mobile employee page for Jane Smith: upcoming payroll breakdown and employee overview
Employee page on a phone

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.

Filter by dates pop-up: calendar range picker with from and to fields and Q1 to Q4 quarter preset buttons
The date filter: custom ranges for any day, Q1–Q4 in one tap

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.

Filings page in By Client view: each client as a collapsible group of its forms, with due dates and statuses
By Client: filings grouped the way he thinks about them
Filings page in List view: every form due across clients, sorted by due date, with upcoming, draft, overdue, and filed statuses
List: every form across clients, 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: