Access-control tools quietly assume one kind of user. Our research found three, each working differently. And all three shared one pain: once permissions pile up across many systems, groups and inherited roles, nobody could confidently answer "what can this person actually do?", keys everywhere, and no list of which doors they open.
We designed for three kinds of admin instead of one, reframed how the central system and local systems share authority, the centre issues your entry ticket, each local door still keeps its own rules, and added dedicated views that answer "what can this person actually do?" directly. Two rounds of usability research backed the direction before it shipped.
Pick who you are, then try a handle.
Research and discovery
Two rounds of usability research drove this case. Round one, with 9 admins from two different tool backgrounds, surfaced both the three-personas framing and the "which doors" blind spot. Round two, with 6 participants, validated the redesign that followed.
Across those two rounds, three distinct kinds of admin emerged:
Nobody could confidently answer "what can this person actually do?" across many systems, group memberships and inherited permissions.
The blind spot, #1 finding from Round 1
Key UX moves
1Designing for three admins, not one
The default move would have been to optimise for the Visual Operator and treat the automation-first architect as a power user the interface didn't really need to serve. We chose not to. The architect needs the interface as a verification layer, one glass pane showing what's actually deployed, regardless of how it got there. That single requirement reshaped the entire navigation.
2The centre issues the ticket; the local door keeps its rules
The relationship between the central console and the systems it manages isn't boss-and-subordinate. We named it federated governance: the centre grants your entry ticket, who you are, what you're broadly allowed, and each local system honours that ticket without throwing away its own house rules. Built on passing authority down, not replacing it, so if the centre ever goes offline, local emergency access still works. Naming this out loud changed how the whole team argued about every decision after it.
3Views that answer the question directly
Not a feature so much as the answer. Dedicated, filterable pages for Users, Groups and Roles, each one a way in to "what can this person actually do?" The first release had only a central list of assignments; the redesign made these views a primary destination for audit and troubleshooting work.
4Granting access from where you already are
Most usability participants asked for this one unprompted. When an admin is already looking at a system, the natural next action is "give someone access to this." Forcing them back to a separate settings page broke the flow every time. We added the in-context path as a second door, complementing the central one rather than replacing it.
Challenges
1One room, or the whole building, the usability finding
Permissions come in two scopes: access to one room, or access to the whole building. The first version presented the two as steps in a sequence, and in testing, nearly every participant assumed both steps were required. The order of the screens had quietly invented a rule that didn't exist. That single finding drove the biggest redesign of the phase: the scope became an explicit upfront choice, not a perceived sequence.
2"Narrow access to projects", the label that wasn't clear
One label that everyone on the design and engineering team assumed was self-explanatory turned out to confuse most participants. They couldn't tell whether "narrow access to projects with the same name" was scoping to a project or to a cluster. A small finding with a big lesson behind it: designer-clear and user-clear are not the same category.
High fidelity walkthrough
The interactive prototype that drove the design and served as the test artifact for both research rounds: kuklas.github.io/acm-user-interface →
Final takeaways
- Designing for three kinds of admin means accepting three verification needs, not one. The automation-first architect reshapes the navigation just as much as the click-first operator does.
- The scope of access belongs at the start as a choice, not at the end as a sequence. Once the model is up front, the flow becomes a decision aid instead of a maze.
- Audit and troubleshooting are first-class workflows, not side effects of the main one. Curated views for Users, Groups and Roles answer the question users were already trying to ask.
- What I'd push harder for next: permissions that expire on their own, and a clean connection to the identity directory companies already run. Neither is an edge case, they're the difference between access control that scales and access control that quietly relies on a human remembering to take a key back.
Public proof and customer evidence
Phase II shipped in ACM 2.16 GA. Phase III findings are informing the next release.
"This view is much better for management than the demo view you showed me. I can see all the groups, all the users, all the rules that apply to the clusters. This is the information that I needed."
Paraphrased usability participant · Phase II study