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’s value was larger than a classroom application. It served as the identity layer connecting students, teachers, districts, and digital learning tools across the country.
The product solved an infrastructure problem, and the website had to make that infrastructure understandable before districts ever requested a demo.
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.
The website needed to function as 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 was to communicate features in a way that reduced 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 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 work required a system capable of growing with the platform, not a collection of one-off pages.
Foundation
I approached the website the same way I approach product design.
I started by defining the underlying system before designing individual pages.
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 built into the baseline
The objective was to make every page feel recognizable while still allowing flexibility across page types.
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. Visitors needed early clarity on what Clever did and why it mattered, with implementation details available once they were ready for depth.
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
I structured the site around repeatable modules so each page could support a specific story without becoming a standalone artifact.
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 while the design approach remained consistent.
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 as part of the core experience.
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 became 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.
The experience needed to show enough depth to earn trust without making the platform feel heavier than the problem it solved.
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 long-term growth as well as the next launch.
Trust and security
For Clever, trust needed to be part of the product story rather than treated as a footer link or compliance detail.
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 became both a message and 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 could reuse established page structures and focus more energy on improving the story those pages needed to tell.
The result was a web system that could evolve with the business rather than constantly catch 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 functioned as 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 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.
