As Clever became the identity backbone for the largest school districts in the country, our existing admin permission model began to show its age. Districts were struggling to give staff and admins the right level of access, maintain least-privileged security standards, and scale operations without error-prone manual processes. With rising cybersecurity expectations and increasingly complex organizational structures, it became clear that our outdated roles framework was becoming a product and security risk. This project set out to redesign RBAC from the ground up to meet the needs of mid-sized and enterprise districts.

Industry

Lead Product Designer

Team

Defining the problem

User research

We conducted research with Broward, NYC, Miami, and Duval - four districts that represent a wide range of size, organizational complexity, and security maturity. Despite very different internal systems, they shared overlapping challenges with the way Clever defined roles simply not mapping to how districts structured their teams. Every district organizes responsibilities differently, and as one admin put it, “There’s no one-size-fits-all set of definitions for each role across districts.”

These mismatches forced districts into brittle workarounds, over-permissioning, or simply excluding staff from using Clever altogether. The emotional undertone of this feedback was consistent: districts didn’t feel in control of access, and they couldn’t shape Clever to match how their teams actually operate.

“An admin needs X permission but shouldn’t have Y permission but role A isn’t enough to do X and upgrading them to role B would allow them to do Y. So we either don’t add that person to Clever, or we put them in the most restrictive role.” - IT admin at NYC Public Schools

Core problems

Synthesizing this research surfaced four systemic gaps we needed to solve

Designs (before)

Prototype + Iteration

Technical constraint

Initially, my PM and Engineering Manager proposed a modular RBAC model where roles acted as “bundles of permissions” sometimes containing just a single permission, allowing admins to mix and match multiple small roles to compose access. For example Impersonation and Password manager are sets of permissions which are extracted from a subset of default roles and can’t be added exclusively but can be added on if necessary.

While the model was technically flexible, it surfaced a core design question for me: Should we actually expose this level of modularity to users? And more importantly, does this mental model align with how admins understand access, or does it create unnecessary cognitive load?

Usability testing insight

In user interviews, admins made it clear that permission “add-ons” at the individual level would create fragmentation and risk.

“If I want all School Tech Leads to have impersonation, I need to define that once at the role level. I don’t want to grant impersonation to those 50 admins individually. I want the role to carry that permission so anyone added to it automatically gets it.” - IT admin at Dallas ISD

Admins stressed that if “add-on” bundles of permissions lived outside the role definition, it would introduce inconsistency and operational risk. New hires might miss critical capabilities because the Admin owner I forgot to add “the extra thing”, and teams would end up duplicating near-identical roles to represent every combination of “with” or “without” an add-on.

This feedback helped me advocate for changing our technical approach to keeping permissions unified within the role definition and reinforcing that roles must be stable, repeatable units of access, not piecemeal bundles composed user-by-user.

Final designs

Adding a team member

Viewing admin roles

Creating a custom role

Deleting an admin role

Impact

Three months after launch (Oct 2025), RBAC adoption far exceeded our expectations both in scale and in the types of districts adopting it. 690 districts were actively using Custom Roles, including 32 big districts and 61 mid-sized districts, our primary target segments for this release.

This level of early uptake was a strong signal that we had solved a real security and operational pain point and confirmed that our design decisions, particularly simplifying the mental model, unifying permissions at the role level, and prioritizing role clarity over technical modularity directly contributed to a solution that was usable, scalable, and trusted by districts of all sizes.

RBAC is now positioned as a foundational building block for Clever’s long-term cybersecurity strategy.