A colleague once showed me a button that had disappeared from an enterprise product. It was not disabled, explained or replaced. It had simply gone. The user knew the action existed because the person beside them could see it, which produced the natural conclusion that the software was either broken or engaged in office politics.
The button had vanished because of a permission rule. Technically, the system was behaving correctly. Experientially, it was behaving like a locked cupboard that denied the existence of cupboards.
Permission models are often treated as backend plumbing: important, complicated and best discussed by people who enjoy spreadsheets with seventeen tabs. But permissions shape what users understand about their role, what they can safely do and how teams collaborate. They are part of the user experience.
Access is a product decision
Every permission rule encodes a decision about responsibility. Who may see financial data? Who can approve a contract? Who can edit a customer record after an invoice has been raised? These are not merely technical questions. They define the operating model of the product.
When the model is vague, the interface inherits the confusion. Teams end up with broad roles such as Admin, Editor and Viewer, followed by exceptions that accumulate like receipts in a coat pocket. Eventually “Viewer” can edit three fields, “Editor” cannot submit a quote, and only the person who configured the system in 2022 knows why.
I start permission design by mapping real responsibilities, not inventing role names. Who initiates the work? Who checks it? Who approves it? Who needs oversight? Who handles an exception? The resulting model may still use roles, but those roles are grounded in actions and consequences.
Hidden is not the same as forbidden
Sometimes hiding an unavailable action is sensible. A customer should not see internal administration controls. But inside collaborative products, invisibility can destroy shared understanding. If one team member can approve a record and another cannot even see that approval exists, they cannot coordinate around it.
A disabled action with a clear explanation can be more useful: “Finance approval is required before this contract can be issued.” Better still, show who can approve it and how to request their help. The interface then teaches the workflow instead of merely enforcing it.
This aligns with the visibility of system status heuristic. Users should understand what is happening and why. Security still matters, of course; an explanation should not expose sensitive information. But “you do not have access” is usually less useful than “only account owners can change billing details”.
Design the denied state
Product teams lavish attention on successful actions and leave denied states to a generic toast. That is unfortunate because denial often happens when the user is already trying to solve something urgent. A good denied state answers four questions: what is restricted, why, who can help and whether the user’s work has been preserved.
Preservation is crucial. If a person spends ten minutes editing a form before discovering they lack permission to save, the product has converted governance into punishment. Check access early where possible. If permissions can change during a session, preserve the draft and provide a recovery route.
The WCAG guidance on error identification focuses on clearly identifying problems and describing them in text. A permission denial is not always a validation error, but the underlying lesson travels well: clarity and recovery beat colour, codes and cryptic system language.
Collaboration needs visible ownership
Permissions become easier to understand when ownership is visible. Show who owns the record, who is responsible for the next step and which role can complete it. This turns access control into workflow information.
In complex charter operations, a request may pass through commercial, financial and operational teams. My Aerios marketplace work reinforced how important it is to expose state and responsibility without drowning users in system mechanics. People do not need to memorise an access-control matrix. They need to know why the work is waiting and what moves it forward.
Audit history also helps. When a role or permission changes, record who changed it and when. This is useful for governance, but it also prevents a familiar workplace ritual in which four people ask whether anybody touched the settings.
Beware the super-admin solution
When permissions become difficult, organisations often solve the problem by making more people administrators. It is quick, generous and roughly equivalent to fixing a sticky office door by issuing everyone a chainsaw.
Excessive access increases risk and makes the product harder to reason about. If everyone can do everything, ownership becomes ambiguous. Sensitive actions should be proportionate to their consequences, with confirmation and audit where appropriate.
That does not mean every action needs a ceremonial approval procession. Over-control creates shadow workflows in email and spreadsheets. The goal is the minimum governance needed for confident work, not maximum restriction. Test the model with real scenarios and real exceptions, especially temporary cover, staff changes and cross-team collaboration.
Test roles as journeys
Permission testing is usually performed as a checklist: can Role A access Screen B? I prefer journey tests. Can a sales user create a request, collaborate with finance, respond to a change and complete the handover? Can a manager intervene without taking ownership accidentally? Can somebody returning from leave understand what happened?
Journey testing reveals gaps between individually correct rules. Each screen may pass while the overall job remains impossible. It also exposes places where the product assumes users know organisational details that are invisible on screen.
Good permissions create confidence
A strong permission model does more than prevent the wrong action. It makes the right action feel safe. Users understand their authority, see the boundaries and know how work moves between colleagues.
Treat access rules as part of product modelling. Make restrictions explainable, preserve work, show ownership and test whole journeys. If a button must disappear, be certain the user does not need to understand that it ever existed. Otherwise the product is not simplifying the experience. It is hiding the plot.
