Onboarding at scale
Three years on an HR and payroll platform. The work I keep pointing at is the digital onboarding checklist, which moved new organization setup off a CX walkthrough, so one CX person covers several onboardings at once.
My part
I built the digital onboarding checklist, paused and resumed rather than restarted, and worked on the UI standardization effort.
Outcome
50+
inconsistencies resolved
counted from the team's tracking sheet during the work, entries I closed, and not re-checkable now
Problem
Setting up a new organization on an HR platform is a long, branching task with real consequences for getting it wrong. It spans company details, people, payroll settings, and compliance, and it is usually done once by someone who has never done it before.
Anything that long tends to be abandoned in the middle, and an abandoned setup is an account that never becomes a customer.
Constraints
The platform serves businesses of wildly different sizes and configurations, so the flow has to hold up across all of them rather than a happy path.
The interface had drifted. Similar controls behaved differently in different corners of the product, which made every new flow more expensive to build than it should have been.
What I did
I built the digital onboarding checklist: a multi step flow with validation and state that survives interruption, so setup can be paused and resumed instead of restarted. Setting a new organization up used to take a CX person walking the customer through it; the checklist runs that part itself, so one CX person covers several new organizations at once.
In parallel I worked on the UI standardization effort, resolving more than 50 inconsistencies across the product and documenting the results in Storybook so the fixes held.
I owned Webpack and build tooling, and worked on CI and test reliability, which is the unglamorous side of making a large frontend safe to change.
On mobile I worked on the React Native app: two factor authentication, biometric login, and a cross platform carousel.
Decisions
| Decision | Why | What I rejected | What it cost |
|---|---|---|---|
| Leave the existing lock logic in place and add a second version beside it, behind a feature flag | The in place rewrite merged and had to be reverted a day later. A second version running alongside could change behaviour for new organizations without changing it for the ones already set up. | Recursion with cycle detection. The second version drops the visited set for a flat lookup with two explicit rules, trading correctness in graph theory terms for something readable that does not move existing behaviour. | The source of truth did not change. Dependencies still arrive as a flat array of codes and the client rebuilds the graph on every render. Treating an unrecognized code as already complete is deliberate fail open, so a customer is never blocked by it, at the cost of not noticing bad data. A lock state changed on the server still only appears on the next fetch. |
Details that mattered
Standardization work is easy to undersell because the output is an absence: fewer surprises, fewer one off components, fewer decisions per feature. It is also the work that made the onboarding flow cheap to build.
Pricing page iterations came from conversion data rather than opinion, which is the habit I kept when I started running my own products and had to own the funnel myself.