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 K–12 classrooms, login friction has immediate consequences.
When students cannot access learning applications, instruction pauses. Teachers become technical support. Devices sit idle while classrooms wait for accounts, passwords, or recovery steps.
Clever addressed that problem at the infrastructure level.
The platform connected students, teachers, staff, district identity providers, and learning applications through one identity model. Behind that experience sat thousands of districts, each with different authentication providers, password policies, onboarding practices, and IT capabilities.
Identity and access required a consistent operating model that could support national scale while remaining practical for students, teachers, and administrators.
My role was defining that model: a reliable core experience with controlled flexibility where district infrastructure genuinely differed.
The problem
Districts introduced variability at every step.
Some authenticated through Google. Others relied on Active Directory, ADFS, local credentials, or combinations of multiple providers. Younger students often had no email addresses. Shared classroom devices made traditional password management unreliable. District IT resources ranged from dedicated identity teams to a single administrator supporting an entire school system.
Supporting every local preference would create a product that became increasingly difficult to maintain.
Authentication paths would fragment.
Support and recovery would become inconsistent.
New districts would require increasingly specialized onboarding.
Security would become harder to reason about across thousands of implementations.
The central product decision was determining where standardization created long-term value and where districts needed flexibility.
The experience required a predictable foundation that could scale nationally while supporting legitimate differences in district infrastructure.
Foundation
I approached the work as an identity architecture problem rather than a collection of login screens.
The experience followed one consistent sequence:
1. Establish district context.
2. Present supported authentication methods.
3. Authenticate through the appropriate provider.
4. Deliver immediate access to learning applications.
District context and supported authentication options handled the underlying identity logic, allowing students and teachers to focus on reaching their learning tools. The interaction model remained predictable for users while supporting national scale.
Every subsequent decision reinforced the same principles:
Clear entry points
Predictable authentication
Reliable recovery
Consistent navigation
Immediate access after login
The interface remained intentionally simple because the complexity had already been resolved inside the product architecture.
Experience walkthrough
1) District discovery
Every identity flow begins with context.
Before users could authenticate, the product needed to identify their district and determine which identity providers, authentication methods, and resources applied to them.
District discovery established that foundation. The experience guided users to the correct district before presenting authentication options, reducing confusion across multiple login methods while making district switching and recovery straightforward when needed.
For students, it answered a simple question: Where do I begin?
For the platform, it established the context that drove every decision afterward.
2) Authentication
Once district context was established, authentication became considerably simpler.
The interface presented only the methods supported by that district, reducing unnecessary decisions while preserving a consistent experience regardless of the underlying identity provider.
The interaction model emphasized clarity over configuration:
Show supported authentication providers only.
Keep student and teacher pathways obvious.
Separate administrative functions from everyday login.
Use plain language instead of identity terminology wherever possible.
The product absorbed the complexity of district infrastructure so users could focus on getting into their learning applications.
3) Clever Badges
Clever Badges addressed one of the most practical constraints in K–12.
Many younger students could not reliably type usernames or passwords. Shared classroom devices made persistent credentials unreliable, and many students had no email address to support traditional account recovery.
Badges introduced a faster access model built around classroom realities. Students could authenticate with minimal typing, teachers spent less time resolving login issues, and classrooms transitioned into instruction more quickly.
The interaction remained simple. Supporting it required identity, security, and district provisioning to operate consistently behind the scenes.
4) Portal and application access
Authentication established identity. The portal delivered value.
After login, students, teachers, and staff entered a personalized environment that surfaced the applications and resources available to them.
The portal balanced consistency with district flexibility by:
Presenting available applications clearly.
Supporting role-specific experiences.
Allowing districts to include local resources.
Preserving a familiar navigation model as additional applications were connected.
The experience completed the identity journey:
District context established who the user was.
Authentication confirmed access.
The portal connected that identity to learning.
Judgment
The defining product decision centered on standardization.
Districts regularly requested custom login paths, branded entry pages, specialized credential rules, unique routing logic, and bespoke portal structures. Each request addressed a legitimate local need. Supporting every variation would steadily increase operational complexity across the platform.
I standardized the parts that benefited every district:
District context before authentication.
One authentication selection model.
Predictable recovery pathways.
Consistent separation between student, teacher, administrator, and support experiences.
A stable post-login destination.
Flexibility remained where district infrastructure genuinely differed:
Supported identity providers.
Portal content and local resources.
District-specific support contacts.
Local implementation details within the broader navigation model.
Those decisions protected reliability as Clever expanded nationally.
Teachers needed students learning during the opening minutes of class. District IT teams needed an identity model they could understand, support, and trust. The interaction model served both.
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
Principal Product Designer — Partnered with the CTO and engineering to design Clever’s identity, SSO, and onboarding workflows, clarifying role-based paths and district-specific setup while scaling access to 25M+ users across 90K+ schools.
