Risk-Aware
Access Control
Permissions don't fail loudly. I designed a system that shows impact before it breaks things.
Type
Conceptual
Role
Product Designer
Duration
2 Weeks
Focus
Decision support
Product design ⦿ Platform UX ⦿ Systems thinking ⦿ Decision support ⦿ SAAS
What's this about
Permissions are a decision problem, not a settings problem.
As teams grow, access control breaks down — not because admins configure things wrong, but because the system never shows them what the outcome actually is. A role change can silently affect dozens of users. Issues surface only after access is live.
Three gaps made every change feel risky
Invisible outcomes
Admins configured roles but never saw the resulting effective access.
Silent blast radius
One role change could affect many users. The system never surfaced the impact beforehand.
No recovery path
Mistakes were only visible after access went live — with no structured way to undo them.
Core Insight
Admins weren’t failing to configure correctly. They lacked enough information to know if their configuration was correct at all.
What existing systems get wrong
Competitive analysis of AWS IAM, GitHub, Notion, and Slack.
AWS IAM
Strength
Granular policy-based control
Gap
Extremely complex mental model
Lesson
Surface effective access clearly
GitHub
Strength
Clear role hierarchy
Gap
No preview of affected users
Lesson
Show impact before applying changes
Notion
Strength
Simple role model
Gap
No exception mechanism
Lesson
Use overrides instead of new roles
Slack
Strength
Workspace vs channel permission separation
Gap
No clear recovery tools
Lesson
Permission changes must be auditable
Three approaches I considered
1. Simulation Mode
Rejected
Why it looks good
Zero risk to live data
Matches engineering mental model
Where it broke
Introduces dual-state confusion
Adds friction to simple changes
Often skipped → false sense of safety
Too much friction for routine changes. Better suited for CI/CD tooling than admin UX.
2. Permission Diff Panel
Partially Adapted
Why it Worked
Zero risk to live data
Matches engineering mental model
Where it Failed
Shows what changed, not who is affected
Doesn't communicate blast radius
Non-technical users don't think in diffs
Inspired the Effective Access panel but diff alone wasn't enough
Impact Review Step
Selected
Why it Wins
Translates permissions people
Makes risk visible before action
Farces intentional decision
Where it Failed
Adds change step to every change
Risk of click-through fatigue if not designed carefully
Friction is not a problem it's the safety here mechanism
System Model
One source of truth: Effective Access. Most systems stop at configuration. This adds two more layers.
Roles
Permissions
Overrides
Effective Access
Audit Log
Design Decisions
1. Roles Dashboard: Ambient risk awareness
Member counts surfaced inline so admins understand the real-world weight of a role before touching it. High-risk system roles are read-only — deliberately trading flexibility for stability.
Permission editor — logic visible, not inferred
Dependency rules enforced by construction — Delete requires Edit, Edit requires View. Invalid states can't be reached. A live Effective Access panel updates in real time.
Why: If the system can only be configured correctly, admins stop second-guessing themselves.
Impact review — changes become consequences
User-level exceptions that sit above roles, visually flagged, fully reversible. Permanent or time-bound. Edge cases handled cleanly without polluting the shared role structure.
Member access summary — one screen to debug anything
Assigned roles, inherited permissions, active overrides, and effective access — all in one place. Eliminates the multi-screen guesswork that makes access bugs expensive to resolve.
Overrides — exceptions without role sprawl
Before any change applies, admins see exactly which members are affected and how. Not a confirmation dialog — a decision surface. The framing shifts from "save?" to "here's what happens to real people."
outcomes
Visible
Effective access shown before every change — not after
0
Silent high-risk changes — all require explicit acknowledgment
1 Screen
To fully debug any member's access state
↓
Reduced incident escalation — fewer failures turning into larger outages
The hard part
The impact review step adds friction intentionally — but too much friction causes admins to bypass it. In production, I'd measure drop-off at that step and validate that deliberate slowdown leads to fewer errors, not just slower workflows.
Learnings
Designing for mistakes is as important as designing for success
Undo changed how the whole system felt — not the flows, just the stakes.
Friction is a feature when risk is real
High-risk changes deserve a pause. The impact review step exists to create that pause deliberately.
Invalid states shouldn't be reachable
Enforcing dependency rules by construction removes an entire class of admin errors.
One source of truth simplifies everything
Once Effective Access became the single output, every other decision — overrides, audit, debugging — fell into place around it.
WHAT I’D IMPROVE
Measure actual drop-off at the impact review step. If admins are clicking through without reading, the friction isn't working — it needs to be redesigned, not removed. Also: test whether time-bound overrides get cleaned up or pile up over time. Expiry alone doesn't guarantee hygiene.
See what else I built
Working on a complex product? I can help bring clarity to it.
I take on projects, part-time work, and full-time roles. send the details — we’ll figure it out.
vizuraja@gmail.com
CHAOS
→
CLARITY
V
I
S
W
A
You could have been anywhere on the internet, yet you’re here. thanks for visiting