The permissions screen is the most feared surface in a product. Ask an administrator to grant a role while you watch, and the hesitation is visible: a pause, a search through documentation, then a grant wider than the task needs, chosen so nothing breaks.
The fear has a precise source: irreversibility the interface refuses to acknowledge. Admins don’t know what a role actually unlocks, they don’t know who else it touches, and they don’t trust that revoking it will put the world back. So they over-grant, because too much access fails invisibly and later, while too little fails loudly this afternoon.
01 · WHAT REDUCES THE FEAR
Three affordances answer the fear directly. A preview of consequences before commit: "this grants read access to 214 records in two projects." A visible blast radius: who else inherits this change. And an honest undo statement: what revocation restores, and what it can’t.
02 · THE TRUST LEDGER
Every over-grant is trust borrowed against a future incident. The permissions screen is where that ledger is kept, which is why it deserves a product’s densest, most carefully argued design work, and why it usually gets the least.
03 · RUN THE TEST YOURSELF
The fear is measurable, and you need no lab. Recruit the administrators you already have. Give each the same three tasks on your own permission system: grant a contractor scoped access, work out what a named role unlocks, revoke an account after a simulated incident.
Record three numbers. Time from opening the screen to committing a change. The width of each grant against the minimum the task required. Spoken uncertainty, with "I think this is read-only?" counted as data. If your product over-grants the way most do, the grant widths will tell you before any incident does.
Then put the three affordances from section 01 in front of the same people, even as paper prototypes, and run the tasks again. Discount the enthusiasm a little, since people trust prototypes too readily. Watch what they ask for instead. Those requests are the permissions roadmap.