Most RBAC tools quietly assume one kind of user — the UI-dependent admin. ACM's actual users turned out to be three different people with three different mental models. The single biggest pain point across all of them was the effective-permissions blind spot: nobody could confidently answer "what can this user actually do?" across multiple clusters and overlapping role bindings.
We designed for three personas instead of one, framed the relationship between ACM and OpenShift as Federated Governance, and added curated User, Group and Role views that answer the "what can this user actually do?" question directly. Two rounds of usability research backed the direction, and Phase II shipped in ACM 2.16 GA.
Research and discovery
Two rounds of usability research really drove this case. Round one, with 9 participants split across vSphere-transitioning admins and OpenShift-native admins, surfaced both the three-personas framing and the effective-permissions blind spot. Round two, with 6 participants, validated the Phase III redesign — binding-type clarity, the curated views and the in-context entry point.
Across those two rounds, three distinct personas emerged:
Nobody could confidently answer "what can this user actually do?" across multiple clusters, group memberships, and overlapping role bindings.
Effective-permissions blind spot — #1 finding from Round 1
Key UX moves
1Designing for three personas, not one
The default move here would have been to optimise for the Visual Operator and treat the GitOps Architect as a power user the UI didn't really need to serve. We chose not to. The GitOps Architect needs the UI as a verification layer — a "single pane of glass" that shows what's deployed regardless of how it actually got there. That one requirement ended up reshaping the entire navigation.
2Reframing ACM ↔ OpenShift as Federated Governance
The relationship between ACM and the local clusters it manages isn't really Master/Slave. It's Federated Governance. ACM provides the ticket to enter — authentication and base scope. The local cluster honours that ticket without throwing away its own local policies. The design is built around propagation, not replacement, so if ACM goes offline, local emergency access still works. Naming that framing explicitly changed how the entire team talked about every subsequent design decision.
3Curated views for the blind spot
This isn't a feature so much as the answer. Dedicated, filterable pages for Users, Groups and Roles — each one an entry point to the "what can this user actually do?" question. The MVP had only a centralized role-assignment list. Phase III added the curated views as a primary destination for audit and troubleshooting work.
4In-context role assignment from a resource view
Most usability participants asked for this one without being prompted. When an admin is already looking at a cluster or a VM, the natural next action is "grant access to this." Forcing them back to a separate Access Control page broke the flow every time. We added the in-context entry point as a logical second path, complementing the centralized one rather than replacing it.
Challenges
1Role Binding vs Cluster Role Binding — the usability finding
The MVP wizard presented Role Binding and Cluster Role Binding as a sequential two-step flow. In testing, nearly every participant assumed both steps were required. The sequence quietly created a false affordance. That single finding drove the most significant Phase III redesign — making the binding type an explicit upfront choice rather than 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 personas means accepting three verification needs, not one. The GitOps Architect reshapes the navigation just as much as the Visual Operator does.
- Binding type belongs at the start as a choice, not at the end as a sequence. Once the conceptual model is up front, the wizard 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 in Phase IV: time-boxed permissions, IdP integration that doesn't feel disconnected from Active Directory, and an officially supported Group Sync Operator. None of those are edge cases — they're the difference between RBAC that scales and RBAC that quietly relies on a human to remember to revoke access.
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