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.

I was the first design hire. There were forty things that needed design attention: the tutoring interface, the tutor dashboard, the reporting layer, the parent communication flow, the internal scheduling tool, and the onboarding process that sat upstream of all of it. Every team had a case for why their surface should be first.

I prioritized by asking one question: what is the binding constraint on growth? The tutoring product worked. The Johns Hopkins data proved it. The reporting layer was manual but functional. The tutor dashboard was ugly but usable. None of those were preventing the company from scaling. The onboarding process was. Every new district launch bottlenecked at the same point: the spreadsheet exchange between Ignite's ops team and the district administrator. The ops team was spending 60 percent of their time managing onboarding for existing districts, which meant they could not support new ones. The company could not grow faster than the ops team could email spreadsheets.

The prioritization framework was simple: fix the ceiling before you fix the floor. A better tutoring interface would make existing students' sessions marginally better. A faster onboarding flow would let new students start getting sessions at all. The second-order effects were not close. I chose onboarding over every surface that was more visible, more interesting to design, and easier to get internal support for. The unsexy operational work was the highest-leverage work available.

The decision was validated within the first quarter. Once onboarding moved off the critical path, the ops team's capacity freed up and the company onboarded more districts in Q2 than in the previous two quarters combined.

Three approaches were on the table before I committed to the full platform flow.

Approach A: Templatized spreadsheets. Keep the email-based workflow but standardize the spreadsheet format, add validation macros, and build an import pipeline on Ignite's side. This was the fastest to ship, about two weeks of engineering. I rejected it because it optimized the wrong side. The spreadsheet was not the problem. The back-and-forth was the problem. A better spreadsheet still required a district admin to fill it out, email it, wait for Ignite to process it, receive error corrections, fix them, and re-send. Every round trip was a week. A cleaner spreadsheet might save one round trip. The flow needed to eliminate them.

Approach B: Phased self-serve. Build the onboarding in phases: start with school selection in the platform, keep roster upload as a spreadsheet, add each step to the platform over time. Lower risk, faster first ship. I rejected it because the handoff between platform and spreadsheet created a seam that confused district admins. In testing, admins who completed Step 1 in the platform and then received an email asking for a spreadsheet for Step 2 thought something had broken. The hybrid was worse than either pure approach.

Approach C: Full guided flow in the platform. Seven steps, all in-platform, with inline validation and state persistence between sessions. The longest to build. The only one that eliminated the back-and-forth entirely. This was the direction I committed to because the cycle time was an academic outcome metric. Every day saved on onboarding was a day of tutoring gained for the students.

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.

We tested the flow with four districts before general release. Each one surfaced a different failure mode.

District 1 (small, 2 schools, 180 students). The admin completed the flow in one sitting, 45 minutes. No issues. This was the easy case and it taught us nothing about the hard case. But it confirmed the flow was completable, which mattered because the internal assumption had been that district admins would not self-serve at all.

District 2 (mid-size, 8 schools, 1,200 students). The admin started the flow, got to roster upload (Step 2), and stopped for six days. When they returned, the session had expired and they had to restart. We added persistent state. The flow saves progress at every step and resumes exactly where the admin left off, regardless of how much time passes. Real district admins do not finish onboarding in one sitting. They finish it across a week of meetings, approvals, and data pulls from other systems.

District 3 (large, 22 schools, 4,800 students). The roster upload crashed. The admin was pasting 4,800 rows from a SIS export that included columns the system did not expect. We rebuilt the roster step to accept messy data. The system maps columns intelligently, flags rows that need attention, and lets the admin fix individual records inline instead of re-uploading the entire file. Error rate on roster submissions dropped from 67% to 12%.

District 4 (multi-stakeholder, 14 schools, 3 different admins). Three people at the district needed to touch the onboarding: one for school selection, one for roster data, one for scheduling approval. The flow assumed a single user. We added role-based handoff. An admin can complete their steps and pass the flow to a colleague with a link. Each person sees only the steps they own. Completion time for multi-stakeholder districts dropped from 18 days to 5.

The pattern across all four: every assumption about how district admins worked was wrong in at least one district. The flow that shipped was not the flow we designed. It was the flow four districts taught us they needed.

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.