Homebase — Fixing Onboarding Drop-Off by Rebuilding the System Underneath It
The number that started everything
Only 28% of employees were completing their onboarding packets. But the part that worried me more than the number itself was what it implied — managers were still getting people onboarded somehow. If 72% of employees weren't finishing in-product, where was the rest of the process happening?
Our hunch was that the product wasn't just losing users. It was pushing them elsewhere.
"Drop-off" wasn't the real story
Once we traced the onboarding journey end to end, the experience wasn't one flow. It was a chain of disconnected moments: employees completing forms on mobile in short bursts, managers needing to approve documents before people could work but lacking visibility into what was missing, and a system that treated every document — from tax forms to employee handbooks — as the same kind of upload.
Because packets weren't configurable by role or worker type, managers were sending the same generic bundle of forms regardless of context. When employees got stuck, the fallback was predictable: texts, email, paper, "send me a picture of that document" — anything that got the job done outside the product.
That's when the project changed shape. We weren't dealing with confusing screens. We were dealing with a system that didn't reflect operational reality.
We stopped looking at screens and started looking at the ecosystem
Instead of redesigning the UI, I led an audit of the onboarding ecosystem with Product, Engineering, and Compliance. We mapped every document and data point collected, who needed access to it, when that access was required, and where the experience broke for each user type.
The engineering partnership mattered early. I held technical working sessions to understand storage constraints, permission logic, and state management — because it didn't matter how clean the UI was if the system couldn't reliably answer basic questions: Is this complete? Who can see this document? Can a manager share this with the team, or is it sensitive? What should be requested for this worker type?
Mapping out the various document types and data points collected at the employee on boarding and tying it back to what information does each user type need to access and for what reason
Identifying what data and documents did each is a persona need to get the job done in their boarding and day-to-day work cycle
Defining the user flow for a manager adding a new employee to the roster
The turning point: we were mixing two different document worlds
A lot of the mess in onboarding came from the product treating all documents identically. But we were actually dealing with two fundamentally different categories:
Sensitive employee documents — identity and compliance materials requiring restricted access and careful handling. Organizational documents — policies, handbooks, and general materials meant to be shared across a team.
That distinction sounds obvious in hindsight, but naming it unlocked everything else. Once we agreed these were different document types, the next step was aligning the product with that reality — separate storage logic, separate permission structure, clearer ownership. This is the moment the work stopped being "onboarding UX improvements" and became "rebuilding the model that onboarding sits on."
The second turning point: managers weren’t “sending packets”—they were running a workflow
The other major gap was how packets were created. Managers weren't trying to send a generic bundle of forms — they were trying to get different kinds of workers ready for work, each with different requirements. But the product forced one static packet for everyone, which meant managers were doing the real configuration in their heads.
I shifted the goal: onboarding packets needed to become configurable without becoming complicated. That meant enabling managers to create packets by worker type, request certificates when relevant, share company documents separately from sensitive items, and track completion per employee in a way that made blockers visible at a glance.
The scope call that kept us from boiling the ocean
Once you touch documents and permissions, you can end up redesigning the entire HR platform. I made a deliberate scope call with Product: we would not build a generalized document management system or a centralized knowledge hub. We defined the project tightly as onboarding as a structured workflow. Make packets definable. Make employee completion easy on mobile. Make manager visibility clear. Build permission boundaries into the system architecture, not as a checklist item.
Designing the system before designing the screens
This was the most collaborative phase with Product and Engineering. We whiteboarded the data model and state logic before polishing UX, because the UI needed to reflect real states — required vs. optional, started vs. submitted, approved vs. missing — without confusing people.
Employee experience (mobile).
Employees were the ones dropping off, and mobile was the primary touchpoint. I redesigned onboarding around a checklist-based flow that works in short sessions: requirements broken into manageable steps, completion state that feels achievable, focused upload flows, progress that persists across sessions, re-entry from multiple places without losing context, and the ability to review what's been submitted. The surface simplicity is deceptive — the real work was making it reliable: secure handling, correct permissions, stable state persistence so people didn't feel punished for leaving mid-flow.
Mobile onboarding screens that gather all the essential onboarding information and allow users to upload and share the required documents with their employer.
Manager experience (packet creation)
I rebuilt packet creation to match how managers actually think: choose the packet type aligned to the worker type, add dynamic requirements including certificates, attach organizational documents separately, and see completion clearly per employee with fewer guessing moments. Product helped keep it usable instead of a settings maze. Engineering ensured configuration mapped cleanly to storage and permission logic.
What this project was really about
The best part of this project wasn't a single screen — it was that we stopped treating onboarding as "forms UX" and treated it as what it actually is: a workflow that connects employees, managers, compliance requirements, and data ownership. We took something fragmented and easy to abandon and turned it into a structured system that could scale across worker types and future HR workflows — without trying to rebuild the entire platform at once.
Impact:
Identified the root cause of 72% onboarding drop-off — a system-level architecture problem, not a UI problem.
Projected 3× improvement in completion rates based on industry benchmarks for structured onboarding flows.
Estimated 40% reduction in manager follow-up burden through checklist-focused upload flows with clear progress visibility.
Established a scalable onboarding foundation with permission-aware document handling that matched how managers actually hire and how employees actually finish.