Acquired by Kahoot! (2021)
Identity, access & interoperability
Identity, access & interoperability
25M+ users / 90K+ schools
25M+ users / 90K+ schools
At a glance
Role: Founding UX lead (identity, access, onboarding)
Surfaces: District discovery → authentication choice → login → portal/app launcher
Users: Students, teachers, staff, district admins
Core challenge: Standardize a predictable login experience across districts with wildly different identity systems
Outcome focus: Reduce time-to-learning by removing login friction and the support burden around credentials
Background & constraints
In classrooms, “login” isn’t a minor annoyance—it’s a hard stop. When a few students can’t get in, instruction pauses, teachers troubleshoot, and devices sit idle.
K–12 has constraints that make traditional credential patterns unreliable:
Devices are often shared, so “remembered passwords” aren’t dependable.
Many younger students don’t have email, so common reset loops fail.
District identity infrastructure varies (Google, Active Directory/ADFS, local patterns), and IT capacity ranges widely.
The result: even when schools want to adopt more digital learning tools, authentication friction becomes the limiting factor.
Design thesis: this wasn’t primarily a “login screen” problem—it was a system definition problem: identity, access, provisioning, and recovery needed to work reliably across thousands of districts.
The problem (in practice)
Districts introduced variability at every step:
Different identity providers and password policies
Different expectations for student vs teacher access
Different “first day” onboarding realities
Different support constraints when something goes wrong
If we designed for full flexibility, the system would collapse under complexity. If we over-standardized, we’d break real district workflows.
My job: define the balance—a consistent core that schools could trust, with controlled flexibility at the edges.
What we built: Instant Login
Instant Login provided a simple model:
Users identify their district/school context
They authenticate using the method their district supports
They land in a personalized portal where connected learning apps are available with one click
This reduced the cognitive load of “Which account do I use?” and replaced repeated password entry with a single, predictable flow.
Experience walkthrough (what the UI proves)
1. District discovery: “Start here”
The first failure mode in K–12 is starting in the wrong place. District discovery created a clear entry point that:
Anchored users to the right context
Reduced confusion across multiple login methods
Made recovery (“Not your district?”) an explicit, low-friction action
2. Authentication choices without complexity
Once the district context is known, the UX needs to support different identity providers while still feeling like one coherent system.
The pattern:
Present only the methods the district supports (e.g., Google, Clever, Badges)
Separate “help” and “admin” pathways from student/teacher pathways
Keep the choice understandable for non-technical users
3. Clever Badges: designing for young students and shared devices
Badges weren’t a novelty feature—they were a direct response to K–12 constraints:
Minimal typing
Works even when students can’t reliably manage passwords
Faster “get everyone started” moments in real classrooms
This is where the system moves from “SSO in theory” to SSO that works for the youngest and most variable user base.
4. Portal: identity → access
The promise of Instant Login is delivered after authentication: a personalized portal that turns identity into immediate access.
The portal experience needed to:
Make “what I can access” obvious
Support role-based differences (student vs teacher vs staff)
Provide stable navigation while letting districts add local resources
Judgment call: standardize the core (even when districts wanted “their way”)
One of the hardest decisions was where to say “no”.
Districts and partners frequently pushed for highly customized login paths (district-branded entry pages, unique credential rules, special-case routing, bespoke portal layouts). On paper, each request sounded reasonable. In aggregate, it would have created a brittle ecosystem where:
support and recovery became unpredictable
new districts took longer to onboard
product quality degraded as exceptions compounded
security posture became harder to reason about and audit
The decision: we standardized a small set of core patterns—even when it meant declining certain “nice to have” customizations.
What I chose to standardize:
a consistent entry model (district context → auth choice)
a constrained set of authentication methods (only those we could support reliably)
predictable recovery pathways (help + admin access separated from student/teacher flows)
a stable post-login landing expectation (portal → apps/resources)
What I allowed to vary:
which providers a district could use (e.g., Google, ADFS/SAML, Badges)
district-specific portal content and local links (within the navigation model)
support contacts and escalation paths
The product’s real promise wasn’t “perfect fit for one district,” it was reliability at national scale—a system teachers could trust during the first five minutes of class.
System decisions
Consistent core, controlled flexibility
We standardized the parts that must be predictable:
Entry point and district context
Authentication selection model
Post-login landing expectations
We allowed flexibility where districts truly differ:
Which identity providers are available
Portal content and local resource structure
District-specific support escalation and admin pathways
Recovery and support as first-class UX
In K–12, failure isn’t rare—passwords get mistyped, accounts get out of sync, devices rotate. The UX needed clear recovery without dumping users into technical jargon.
Accessibility and trust
Identity flows are high-stakes: the experience must be clear, stable, and accessible. Accessibility was treated as a system requirement, not a polish pass.
Outcomes
Login completion time reduced ~60% (measured through iterative onboarding experiments and rollout learnings)
Support tickets reduced ~30% by moving districts toward predictable, self-service setup and clearer recovery paths
National scale adoption: the system supported identity and access patterns across tens of thousands of schools and millions of users
These outcomes reflect system-level decisions that improved access, reliability, and adoption at scale.
What I’d want a reviewer to take away
I design identity flows as systems.
I translate messy constraints into a coherent interaction model.
I optimize for outcomes that matter operationally: time-to-learning, support burden, reliability, and trust.
Appendix: Evidence & references
Market framing and the “lost class time” problem were widely documented in K–12 discussions of credential management and SSO during this period.
Public-facing product pages and press coverage reinforced the need for simpler, secure access patterns in schools.
Role
Founding UX Architect & Design Lead
Partnered with the CTO, product, and engineering to architect Clever’s identity and onboarding UX, establish early design systems, and scale user access from a few districts to 25 million users nationwide.
