The onboarding problem that was actually a growth problem

Ignite Reading was scaling from Series A to B, $10M to $36.75M in funding, with a tutoring product reaching 200,000 students across 22 states. The product worked. The operational design around it did not. School districts were onboarding through spreadsheets emailed back and forth between Ignite and district administrators. Every new district launch was a multi-week negotiation across three stakeholder groups, conducted in cells. I was the first design hire. The first thing I prioritized was not the product. It was the process around it.

I spent the first six weeks talking to three groups of people, because the platform had three real users and they wanted different things, and the onboarding flow had to serve all three or it would not work.

Districts were the buyer. They were on the hook to their school boards for academic outcomes. They needed reporting, accountability, and evidence the program was working before they could approve the budget for the next cohort. They were patient with paperwork and impatient with vendors who could not show progress.

Teachers were the operator. They were going to live with whatever process Ignite gave them, every day, in classrooms with twenty-five other things to do. They needed the rollout to happen in the background of their existing workflow, not on top of it.

Students were the end user. They were not in the onboarding loop, but they were in the consequence of it. Every week the onboarding took to complete was a week the students did not get tutoring. The cycle time was not an operational metric. It was an academic outcome.

The diagnosis: the spreadsheet workflow was not just slow, it was actively pulling against the company's mission. Every cell that bounced back and forth between Ignite and a district was a child not getting a reading session. The operational design was the academic design. They were the same problem.

Replace the spreadsheet exchange with a guided in-platform flow. Districts complete enrollment, scheduling, and program configuration through a step-by-step interface designed around their actual workflow, not around the database schema underneath.

Three opinionated calls shaped the design.

First, the platform absorbs the operational complexity. The product's job is not to ask the customer to fill in a clean dataset. The product's job is to take a messy real-world workflow and structure it without making the customer learn a new mental model. The form fields are written in district language, not Ignite language.

Second, design for the buyer, the operator, and the end-user simultaneously. The flow surfaces what each group cares about at the moment they need it. Districts see progress dashboards. Teachers see schedule integration with the existing school day. Students never see the onboarding flow at all, which is the point.

Third, treat the cycle time as an academic outcome metric, not just an ops metric. Every design decision in the flow was evaluated against the question: does this cut a day off the launch?

The redesigned onboarding flow replaced an emailed spreadsheet workflow with a seven-step guided experience inside the platform. Districts complete school selection, roster connection, teacher confirmation, student enrollment, detail completion, tutoring block assignment, and final review — all in one connected experience. The flow saves state between sessions because real district administrators do not finish onboarding in a single sitting — they finish it across a week of meetings. Validation happens inline so errors get caught at the cell instead of at submission.

Underneath the flow, I built the design system the rest of the platform would inherit. The onboarding components shipped first because they were the most-used surface in the first month of any district relationship. Getting them right meant the rest of the platform had a credible baseline to extend from.

The onboarding flow cut district launch cycle time from a multi-week back-and-forth to a process districts could complete in their own time, in days instead of weeks. The operations team stopped firefighting onboarding tickets and started scaling. The growth ceiling that had been the spreadsheet workflow moved off the critical path.

The downstream effect mattered more than the operational metric. The platform the onboarding fed into, Ember, was the subject of an independent Johns Hopkins study (n=1,872) that found students achieved 5.4 months of additional reading growth per student, with zero achievement gaps across demographic subgroups. The 200,000+ students who ran through the platform were able to start tutoring sooner because the onboarding flow had moved out of the way. The operational work and the academic outcome were the same work, just measured at different layers of the company.

The hardest part of being the first design hire is resisting the urge to design everything at once. There were forty things broken. I picked the operational onboarding work first, ahead of the more visible product redesigns, because the bottleneck was not in the product, it was in the path to the product. The instinct that turned out to be right was treating operational design with the same care as consumer-facing design. The unsexy infrastructure work is often where the leverage actually lives. If I were hiring my replacement, the trait I would screen hardest for is whether they are willing to design a spreadsheet replacement with the same care they bring to a hero screen. Most senior designers are not.