Onboarding redesign for a payroll product

The product sold well and then lost a large share of new customers before they ever ran a payroll, because setup meant entering company details, pay schedules, statutory registrations and every employee's information, in one long sequence, before anything worked. Support was doing setup calls for a meaningful fraction of new accounts, which does not scale and was hiding the size of the problem. The business framed it as an onboarding flow problem; the pattern in the drop-off data said it was mostly about people not having the information to hand at the moment they were asked for it.

Product designer on a squad of six — a product manager, three engineers, a researcher shared across three squads, and me — for about seven months. I owned the design end to end and ran the research sessions myself once the shared researcher's time ran out, with her supervising my first two so I did not lead people. I also sat in on eight support setup calls, which changed my understanding of the problem more than the analytics did.

I owned the flow, the screens, and the writing on them, which in a product like this is most of the design. I restructured setup into a resumable checklist with the parts that need external information split out, designed the states for partly-complete setup including what the product does when you try to run payroll with pieces missing, and wrote the microcopy explaining what each statutory field is for in plain terms. I also built the clickable prototype used for testing and, later, a coded prototype of the checklist so the engineers and I could argue about the resumption behaviour concretely. I did not own the final production implementation, though I reviewed every screen against the design.

The central decision was to let people run a payroll for one employee before setup was complete, which sounds reckless and was the thing that fixed retention. The product manager and I disagreed for about three weeks; his concern was compliance risk from partial data, which was legitimate. What resolved it was scoping it precisely — a draft payroll that cannot be submitted, clearly marked, that proves the product works before you spend two hours on data entry. I also argued to remove the progress bar, because it was measuring our steps rather than the user's, and it made a two-day process look like a failure at every visit.

Statutory fields are statutory: what we ask for and how it is validated is set by regulation, so the design could reorder and explain but not remove. The product had customers mid-setup at all times, so anything we shipped had to migrate people in flight rather than restart them. Engineering could only take the work in slices around a compliance deadline in the same quarter, which meant designing something that could ship in four parts and be coherent after each — that constraint made the checklist structure almost inevitable, and in retrospect improved it.

Completion of setup within the first week went from about forty-four per cent to sixty-eight over the two quarters after the last slice shipped, which is the number the business tracked. Support setup calls dropped by a bit over half. The draft-payroll idea turned out to be the moment people decided to stay: in follow-up interviews, several customers described it as the point where they believed it would work. The progress bar removal was measured separately and made no difference to anything, which was a useful correction to a hypothesis I was confident about.

The researcher taught me how to run a session without steering it and reviewed my first two rounds. The product manager pushed back on the draft-payroll idea until it was properly bounded, which made it shippable rather than an argument with compliance. One of the engineers built the resumable state model and found three cases in my design where a partly-complete setup had no defined behaviour.