Acquired by Kahoot! (2021)
Secure access to learning apps
Secure access to learning apps
25M+ users / 90K+ schools
25M+ users / 90K+ schools
Highlights
25M+ users
90K+ schools
50% of U.S. districts connected monthly
$435M acquisition by Kahoot
Supported national platform adoption
Established reusable web patterns for growth
Overview
Clever wasn’t selling another classroom application.
It was becoming the identity layer connecting students, teachers, districts, and digital learning tools across the country.
The product solved an infrastructure problem. The website had to solve an understanding problem.
District leaders needed confidence before they ever requested a demo. IT administrators needed to understand how Clever fit into existing identity systems. Educators needed to understand how it reduced classroom friction without becoming experts in authentication or rostering.
That made the website much more than a marketing property. It became the public product experience for a platform that would eventually support more than 25 million users.
I designed the experience from the ground up, then evolved it through new products, messaging, visual refinement, and continuous iteration as Clever expanded nationally.
The goal wasn’t simply to communicate features. It was to reduce uncertainty before implementation ever began.
The problem
As Clever grew, the platform became increasingly difficult to explain.
Every new integration, partner, product capability, and district success story created another opportunity for the experience to become fragmented.
Different audiences arrived with different questions:
District administrators wanted confidence that implementation would succeed.
IT leaders wanted to understand identity, security, compatibility, and student data.
Teachers cared about classroom efficiency.
Partners wanted to understand how their products fit into the ecosystem.
The website had to answer each of those questions without becoming a collection of disconnected pages built around individual audiences or marketing campaigns.
The larger challenge wasn’t visual design. It was creating a system that could explain a highly technical platform while remaining approachable for people making purchasing decisions.
The public experience needed to:
Establish confidence around student privacy, FERPA, and district security.
Explain a technical platform without relying on technical language.
Support multiple audiences through one coherent experience.
Scale alongside new products, integrations, and partnerships.
Preserve consistency as the company continued to grow.
The challenge wasn’t building pages. It was building a system capable of growing with the platform.
Foundation
I approached the website the same way I approach product design.
Instead of designing individual pages, I started by defining the underlying system.
That meant establishing a repeatable information architecture, shared messaging patterns, modular layouts, reusable proof sections, common interaction behaviors, and a visual language that could extend naturally as Clever expanded.
Every decision supported one objective: reduce cognitive effort.
Visitors should understand where they were, what Clever did, why it mattered, and what to do next without relearning the experience from page to page.
The foundation centered around several reusable principles:
Consistent information hierarchy
Modular page construction
Shared trust and proof patterns
Repeatable navigation behavior
Common visual rhythm through typography, spacing, and component reuse
Accessibility as a baseline rather than a later consideration
The objective was to make every page immediately recognizable without forcing every page to be identical.
As new products launched and new customer stories emerged, the experience could evolve without inventing another structure. That consistency became part of the product itself.
Design thinking in motion
The first design problem was message hierarchy.
District buyers had predictable questions:
Is this safe?
Will it work with our existing identity systems?
Will it reduce classroom friction?
Can we roll it out without creating more work?
Is this already trusted by other districts?
The site needed to answer those questions in the right order.
That meant leading with clarity and credibility before depth. A visitor needed to understand what Clever did and why it mattered before being asked to absorb implementation details.
The page logic followed a repeatable sequence:
Start with the promise
Explain how it works
Support the claim with district adoption, security, integration, and partner proof
Guide the visitor to the next step
That structure became the basis for multiple page types. The exact content changed by audience or product story, but the underlying decision path stayed consistent.
District leaders, IT administrators, educators, and partners could move through the site without the experience splintering into separate models.
This was where the public web system mattered. Reusable sections let the site support different messages while preserving a consistent structure.
Modular page system
Instead of treating each page as a standalone artifact, I structured the site around repeatable modules.
The system included:
Hero and positioning sections
Proof blocks for stats, logos, and district adoption
How-it-works explainers
Trust and security sections
Feature cards
Comparison-friendly layouts
CTA patterns that supported the page narrative
Content blocks that could flex across product, partner, and district stories
The important part was constraint.
The site needed enough structure to prevent drift, but enough flexibility to handle different product stories.
Layout, hierarchy, spacing, proof patterns, visual rhythm, and interaction behavior stayed consistent. Content could change without forcing a new design approach every time.
That made the site easier to expand. New product pages could be launched from existing structures. Partner and customer content could be introduced without breaking the broader experience. Security and implementation messaging could be surfaced where it mattered, not bolted on afterward.
This gave the team a faster way to publish while keeping the experience disciplined. It also made the brand feel more mature.
For a platform asking districts to trust its infrastructure, consistency was not decoration. It was part of the credibility signal.
Judgment
The key judgment was deciding how much detail to show at each layer of the experience.
Clever had many legitimate things to explain: identity, rostering, security, application access, district setup, classroom use, partner value, and implementation confidence.
The risk was trying to explain the full platform too early.
District leaders needed confidence quickly. IT administrators needed enough depth to understand security, access, and implementation. Educators needed the classroom value to feel immediate. Partners needed to see where they fit into the ecosystem.
I structured the site so the first layer created clarity and confidence, while deeper technical detail became available as users moved through the experience.
Show enough to earn trust. Do not expose so much that the platform feels heavier than the problem it solves.
The second call was keeping the structure consistent across page types.
It would have been easier in the short term to let every launch or audience story become its own page pattern. That would have created more local flexibility, but it would have weakened the foundation over time.
I chose shared structure because the company was still expanding. The site needed to support growth, not only the next launch.
Trust and security
Trust could not be treated as a footer link or compliance detail.
For Clever, trust was part of the product story.
Schools were evaluating student data safety, access control, implementation risk, and reliability. Those concerns had to appear inside the primary page architecture.
The design challenge was balance:
Too much technical detail too early would overwhelm non-technical audiences.
Too little detail would fail IT administrators and district decision-makers.
The site needed to surface enough confidence to keep visitors moving, then provide deeper information when the buyer needed it.
Security and implementation messaging became first-class content patterns. That included clearer explanation of how Clever fit into district systems, how access worked, and why schools could depend on the platform across large student populations.
Trust was not only a message. It was a structural requirement.
Scaling up
As Clever expanded, the website needed to support new products, integrations, customer stories, and partner content without rebuilding the experience each time.
The underlying system made that possible. New pages inherited established layouts, messaging patterns, and navigation instead of introducing new structures.
The public experience evolved alongside the platform while remaining familiar to returning visitors.
As new capabilities were introduced, the website could communicate them without sacrificing clarity or increasing maintenance overhead. Teams spent less time reinventing page structures and more time improving the story those pages needed to tell.
The result was a web system that could evolve with the business instead of constantly catching up to it.
Relevant contributions from the broader Clever platform
This public product experience was part of a larger platform initiative.
Related contributions included:
Defined a unified interaction model across dashboards, onboarding, and integrations
Established early design system patterns supporting both product and web experiences
Embedded WCAG 2.0 accessibility standards into core workflows
Partnered closely with engineering to improve implementation quality and front-end consistency
Improved page performance by 28%
Supported adoption across 25M+ users and 90K+ schools
Key initiatives
Public product experience
Designed the public experience that helped districts understand what Clever did, why it mattered, and how it fit within existing K–12 infrastructure.
Information architecture
Organized the experience around the questions district buyers needed answered before adoption, reducing uncertainty before implementation conversations began.
Modular page system
Created reusable page structures that supported products, partner stories, district proof, and trust messaging without fragmenting the experience.
Trust and security
Integrated privacy, security, implementation, and credibility into the primary user journey rather than isolating them as secondary content.
Visual system
Established consistent typography, spacing, iconography, hierarchy, and interaction patterns across the public experience.
Accessibility
Built accessibility and responsive behavior into the foundation so every new page inherited the same quality standards.
Results
Although the website represented only one part of Clever’s broader platform strategy, it became the public face of a product growing rapidly across the K–12 market.
Platform outcomes during that growth included:
25M+ students and teachers supported
90K+ schools nationwide
50% of U.S. districts connected monthly
30% reduction in support tickets through broader self-service onboarding improvements
60% faster login completion through the broader identity platform
Acquired by Kahoot for $435M
Impact
Building Clever’s public experience changed how I think about product design.
The website wasn’t separate from the product. It was the first product experience most customers encountered.
Every decision helped reduce uncertainty before implementation, making a technical platform easier to evaluate, easier to understand, and easier to trust.
That perspective has carried into every design system and platform I’ve built since.
The same systems thinking that creates consistency inside an application can also shape how people understand a company, evaluate its products, and decide to adopt them.
For Clever, that meant creating a public experience that grew with the platform and helped districts evaluate a technical product with more confidence.
