Flagship · UX Strategy · Infrastructure · EdTech
Designing Infrastructure to Stabilize Onboarding
A dashboard request became a platform-wide infrastructure initiative after discovery revealed the real problem was an onboarding process the platform was never built to handle at scale.
Context
The Problem
iCEV is a career and technical education platform serving K-12 school districts across the United States. Following two major acquisitions in the 2022–2023 school year, a rapidly expanding user base exposed critical failures in a manual onboarding infrastructure that the platform had never been designed to scale. Org admin engagement sat at 12%, and nobody could agree on why.
I was brought in as iCEV's first in-house UX Strategist to help figure that out. What followed was a project that started as a dashboard request and became something the organization hadn't known it needed: I identified a misdiagnosed problem, reframed the brief, built organizational alignment around the right solution, and delivered infrastructure that addressed root causes rather than symptoms.
Why org admin engagement matters
Org admins make up the smallest demographic of iCEV's users, but their engagement has outsized implications for everyone else on the platform. An admin who isn't set up is worse than inactive — they're a bottleneck for every user downstream of them.
That's what made a 12% active user rate so consequential, and so urgent.
The initial directive
To bolster org admin engagement, iCEV asked me to deliver an Org Admin dashboard as my first initiative. Leadership wanted to move fast — a whole new admin ecosystem, live before back to school 2025. The problem was that no discovery had been done, no user research existed, and there was no definition of what the dashboard needed to do or for whom.
Before committing to a design direction, I made the case for a discovery phase. iCEV's org admin user base spanned three meaningfully different account types — legacy, SSO, and LTI users — each with different setup requirements and workflows, and there was no internal consensus on how those users differed or what they needed. Designing without that foundation wouldn't just risk a bad dashboard. It would risk solving the wrong problem entirely.
Discovery
Dashboard Discovery
Before any design work could begin, I needed to understand why engagement was low, and whether a dashboard would actually address it. Preliminary audits of the internal admin framework and external platform, coupled with internal stakeholder interviews, made one thing immediately clear: all engagement issues pointed to iCEV's manual onboarding process, which was handled exclusively by internal CSRs.
The significant increase in newly acquired users revealed critical infrastructure failures at all points of the onboarding process, resulting in a 300% increase in support tickets over the previous year — and yet leadership's assumption was still that low engagement was a legacy UI problem. The real culprit was an onboarding process that even our most seasoned internal reps struggled to navigate.
Strategic Pivot
Reframing the Brief
Users who never successfully completed onboarding weren't engaging with the platform because they weren't set up to. The dashboard they weren't using was the least of it.
I reframed the brief: the org wanted a dashboard, but what the platform needed was a self-service onboarding infrastructure that could get users to value before they ever reached one.
iCEV was losing conversions, legacy account renewals, and critical internal staff — all downstream of a single annual process that the platform wasn't built to handle at scale. I built the case for a change of course and secured buy-in to redirect the initiative entirely: fix onboarding, and the engagement would follow.
Research
Internal Research: Diagnosing the Issues
As the only users responsible for both executing onboarding and fielding all end-user support tickets, internal CSRs and account admin staff were the obvious starting point for research. They were not only intimately familiar with the pain points of the current process — they could also accelerate delivery by validating potential solutions before we tapped our notoriously time-strapped school district users for concept testing.
Over the course of four weeks, my research phase focused on rep-guided walkthroughs of the onboarding process for all user types, prioritization workshops to surface, categorize, and prioritize support ticket issues, and interviews with department leads to nail down an airtight list of jobs to be done for self-service onboarding.
Three Problems Masquerading as One
iCEV's org admin user base comprised three meaningfully different account types — each with distinct setup requirements, integration dependencies, and onboarding failure points.
Traditional iCEV accounts predating acquisitions. All user and course management handled manually within the platform.
Single sign-on accounts authenticated through third-party identity providers. User management syncs bidirectionally with external platforms.
Learning Tools Interoperability accounts integrated with district-managed LMS platforms. Highest complexity onboarding path.
Research Findings
A System Failing at Every Touchpoint
iCEV's manual onboarding processes required integration of at least two internal systems, often more, depending on account type. Admin tools, onboarding workflows, legacy iCEV, and acquired products all behaved differently, even when users were trying to complete what should be a singular integrated task.
Where the System Broke Down
Prior to the self-service initiative, iCEV's onboarding process was executed manually by internal CSRs — a fragmented, error-prone workflow sustained entirely by institutional knowledge and rep availability.
Admin Framework
UI inconsistencies with the legacy product, scattered architecture, and no central navigation made the platform practically unusable. No standardized conventions for account management resulted in an unmanageable accumulation of dead and duplicated accounts with no protocol for remediation.
Recognition vs. Recall
Rather than surfacing contextual guidance, the platform required users to memorize inconsistent rules and rely on institutional knowledge to accomplish basic tasks across all workflows.
Account Clarity
Users with multiple roles were not consolidated, meaning internal reps would need to commit to several steps in the onboarding process before realizing they were committing changes to the incorrect account.
Role Ambiguity
Internal reps couldn't clearly explain account types, user needs, or workflows, which made it easy to miss or apply the wrong updates to an account.
iCEV's system was so fractured that the internal reps who knew it best struggled to describe the operational standards or the basic requirements of their own onboarding process. The rapid expansion of their user base was toppling an already fragile ecosystem whose workflows were sustained through inconsistent and often conflicting platform rules.
Synthesis & Recommendations
Research Synthesis & Recommendations
My findings surfaced two problems operating at different scales and directly feeding each other.
Micro level
No standardized onboarding definition
The jobs users needed to complete varied by account type and existed only as institutional knowledge held by individual reps.
Macro level
No stable foundation to build on
Inconsistent UX and interaction patterns across legacy and acquired products meant solving onboarding without addressing both would produce something new that failed in all the same ways.
The argument for slowing down to move faster
My central recommendation to leadership was straightforward: we couldn't design a solution for problems we hadn't fully defined yet. Before a single screen was designed, we needed to journey map the onboarding process across all three user archetypes in close collaboration with the CSRs who knew it best.
Where to build it
Leadership wanted to allocate resources to build an entirely separate product — a direction the dev, design, and product teams were firmly against. I lobbied for a different approach: integrate onboarding directly into the existing end-user admin environment. Its 12% engagement rate meant it was effectively a zero-risk surface for a controlled rollout.
The pitch was simple: treat the first release as a beta. Keep CSRs in a triage role, use their support load as a real-time feedback signal, and iterate from there.
That argument won the room, and the end-user admin environment became the foundation for iCEV's first self-service onboarding infrastructure.
Design Decisions
Building the Infrastructure
Journey mapping with internal CSRs produced the foundational output the project had been missing: a clear, validated list of jobs users needed to complete to finish onboarding, and enough understanding of each user archetype to determine how those jobs differed. Three meaningfully different user archetypes, one coherent process.
One Coherent Process for Three User Types
The redesigned onboarding infrastructure replaced a CSR-dependent manual workflow with a self-service system that routes users into the appropriate flow at entry point and keeps every step independently accessible via sidebar navigation.
The onboarding steps
License Provisioning
Gave districts access to their contracted subjects and course content. Required for legacy and LTI users; handled at district level for SSO.
Rostering
For SSO and LTI users: established sync integrations with Google Classroom, Clever, and ClassLink. For legacy users: assigned subjects to teachers and teachers to courses.
Sharing Rules
Gave org admins control over cascading permissions — proctoring rights, enrollment management, test retake thresholds — determining what teachers needed to complete on their end.
Solving for revisits without re-doing everything
One of the most challenging structural problems was that steps in the process could be skipped but might need to be accessed or corrected later. The existing platform had no solution for this — navigation was essentially "use the back button."
I saw this as an opportunity that extended well beyond onboarding. Neither iCEV nor its acquired product EduThings had a cohesive central navigation system. The onboarding project gave us a contained environment to test a solution: an interactive sidebar navigation that would break the process into its component parts and make each one independently accessible.
Winning the room
Leadership still wanted a dashboard. Rather than spending political capital pushing back on an aesthetic preference, I used it. I demoed an animated drawer-based sidebar with collapsed and expanded states — a clean column of icons that revealed labels on hover, expanding into a full icon-and-title display when open.
The strategic work and the aesthetic win weren't in competition. We could have both. That's what got it green-lit for production.
One additional detail worth noting: "onboarding" was internal language that end users had never encountered. I reframed it as "Account Management" in the sidebar — a UX writing decision that resolved internal language confusion, matched end-user mental models, and simultaneously neutralized leadership's push to build a separate onboarding product. The nav label did three jobs at once.
Process
Constraints & Implementation
With two recent acquisitions, an ongoing .NET conversion, and three products in varying states of disrepair, the development team was already stretched thin on maintenance alone. While iCEV understood they needed design support, they had no frame of reference for what that actually looked like. Getting this work built required constructing one in real time.
How the work was structured
Development and design ran on two-week sprints with Friday releases. I worked with a team of three contract designers on onboarding flow prototypes while handling the navigation architecture exclusively — given its strategic scope and cross-product implications, that work needed a single point of ownership.
To keep the broader organization aligned and surface issues before they became blockers, I hosted two hour-long internal design office hours each sprint. These sessions gave CSRs and the development team visibility into progress and laid the groundwork for the internal training materials that were later repurposed into end-user guides now publicly available on iCEV's platform.
Building alignment without authority
This project validated something I've long believed: the most challenging constraints are rarely technical. Establishing design credibility in an organization that never had a dedicated design process meant that advocacy for establishing those frameworks was as much a part of the job as the work itself.
Moving the work forward required meeting leadership's intuitions where they were — finding the overlap between what they wanted to see and what the research said needed to exist, and building the case from there. The sidebar navigation is the clearest example of that approach in practice.
Results
Outcomes: What the Work Produced
Measuring success for this project came with an inherent constraint: iCEV had no analytics infrastructure in place to capture funnel data or quantitative engagement metrics at the time of launch. Outcome measurement relied on the qualitative and observational data the research and testing phases were designed to produce. Within those parameters, the results were clear.
Usability completion rate
Across all moderated sessions. Users who had never encountered self-service onboarding navigated independently with strong satisfaction scores.
Support ticket reduction
Onboarding-related tickets dropped by more than half during the beta window. Residual volume was largely behavioral — habit, not necessity.
User archetypes, one flow
API-determined entry point eliminated the need for separate flows per account type.
Separate products built
Onboarding integrated into the existing admin environment — no new product, no new maintenance burden.
The sidebar navigation shipped as the structural backbone of the onboarding experience and received positive feedback across all user types. iCEV's own public-facing tutorial library confirms its reach — every org admin tutorial navigates through the same Account Management sidebar structure, demonstrating that the architecture designed for onboarding became the organizational logic for the platform's entire admin environment.
Reflection
What This Project Taught Me About Doing Strategy in the Open
This project was, in many ways, a proof of concept for something harder than the design work itself: what it takes to introduce systems thinking into an organization that had never considered it before.
The work I'm most proud of wasn't just the onboarding flow, but the diagnostic approach that preceded it. Identifying that a sequential onboarding experience couldn't function at the component level without a companion navigation architecture — before anyone else had thought to look for that problem — is the kind of anticipatory systems thinking that doesn't show up in a brief. Nobody asked for the sidebar nav, because nobody knew they needed it. That's the work I want to keep doing.
What I would do differently
The single highest-leverage thing I would prioritize from day one in a similar engagement is analytics infrastructure — not as a nice-to-have, but as a non-negotiable precondition for strategic decision-making. I would also be more explicit earlier about decision-making authority and who has standing to redirect design work.
The deeper lesson is about the relationship between strategic influence and organizational structure. The most sophisticated design thinking in the world doesn't survive an environment where implementation decisions can be overridden without accountability. Protecting the integrity of the work means advocating not just for the right solutions, but for the conditions that allow right solutions to ship as designed.
What this project demonstrates about how I work
I solve problems systemically. I'm looking at what's upstream, what's downstream, and what adjacent problems share the same root cause. The onboarding infrastructure wasn't just a solution to a support ticket crisis — it was a proving ground for navigation patterns, UX writing standards, and interaction conventions the entire platform needed. One initiative, multiple leverage points.
The years I've spent embedded in complex product systems gave me fluency in how they behave and break. But the thing I bring that's harder to teach is the instinct for anticipating structural failures before they materialize. That instinct is what reframed this project from a dashboard request into an infrastructure initiative, and it's unquestionably the part of my job I'm most excited to show up for.