Making High-Stakes Access Decisions Clearer and Safer
Role: UX research, systems thinking, information architecture, and product design
Product: Identity and access management for a cloud platform
Focus: Clarity, traceability, security, and scalability
The Context
Identity and access management determines who can use which resources, under what conditions, and with what level of permission. It is a powerful part of a cloud platform—but also a high-stakes one. Confusing interactions do not merely slow people down; they can lead to overly broad access, insecure workarounds, and uncertainty about what has actually been granted.
Sotoon’s IAM service was capable, but its experience was fragmented. Users had to interpret the relationships between roles, rules, groups, users, workspaces, and organizations with limited contextual guidance.
The Research
I interviewed and tested the service with six new and existing users. Across both groups, the central problem was not missing capability. It was the effort required to understand the access model.
Users struggled to:
- Understand the relationship between roles and rules.
- Know what a permission actually enabled because descriptions and context were missing.
- See where access came from or how it was inherited.
- Understand a user’s group membership and effective permissions.
- Move between profile-, workspace-, and organization-level settings.
- Complete public-key and backup-key tasks reliably.
- Recover from errors that explained what failed but not how to fix it.
Participants described the service as “foggy” and its workflows as “hard and annoying.” Several relied on teammates, documentation, or support to verify decisions they should have been able to make inside the product.
Reframing the Problem
I treated the redesign as a system-design challenge rather than a visual refresh. The goal was not to hide the underlying access model. It was to make the model understandable, inspectable, and ready to support more advanced governance features.
The work centered on three principles.
1. Clarify the architecture
I defined clearer boundaries between personal settings, IAM, workspaces, and organizations. This reduced navigation ambiguity and helped users form a more accurate mental model of where access was configured.
2. Make access traceable
The redesign gives administrators a clearer view of what a person can do, which permissions are effective, and where those permissions came from. This supports review before change and reduces reliance on guesswork.
3. Design a foundation, not a dead end
The structure anticipates future capabilities including just-in-time access, access requests, trusted devices, session visibility, audit logs, and expanded group management. Designing for these concepts early reduced the risk of adding more disconnected surfaces later.
What Changed
IAM Overview
A new overview brings operational status, pending actions, access information, and risk signals into one entry point. It helps administrators understand what needs attention before they navigate into details.
Access Groups
The group model now explains what a group is, which permissions it bundles, who belongs to it, and what members can do. This makes group-based management a visible default for repeated access patterns rather than a hidden feature.
User Access View
A redesigned user view exposes effective permissions and their sources, answering one of the most frequent research questions: “What can this person actually access, and why?”
Security Center
Sessions, trusted devices, posture checks, and related security actions are organized into a coherent administrative area instead of being scattered throughout the product.
Interaction-Level Improvements
Clearer terminology, stronger hierarchy, searchable long lists, contextual documentation, actionable error messages, and better links between related objects reduce friction across the system.
Outcome
The redesign created a more coherent model for managing access across people, groups, workspaces, and organizations. It also established a product foundation for future security and governance capabilities.
The most meaningful outcome is better decision quality. Users can inspect access before changing it, understand how permissions were inherited, and make sensitive decisions with more confidence. Because this work describes the redesigned direction rather than a fully measured release, I would pair implementation with success metrics for task completion, support dependency, configuration errors, and use of group-based access.
Reflection
IAM reinforced why I enjoy designing complex systems. The designer’s job is not to pretend complexity does not exist. It is to make the system legible enough that people can act accurately, confidently, and safely.