Product Thinking · Published August 28, 2026
Permission Design Is Product Design
Permissions are not a technical appendix. They decide what each person in the organisation can see and do.
Permission discussions usually focus on role names: admin, supervisor, employee. What actually matters is the boundary detail: can a supervisor see a subordinate's salary, and who handles the approvals of an employee who left? None of that is a technical question.
Three questions only the business can answer
Who owns the data, and does historical ownership move when the responsible person changes?
How is unauthorised access detected? The system must record it, not just assign blame later.
What is the access request process, and does temporary access expire automatically?
Implementation advice
Name permission points after business actions rather than pages, so reorganisations do not require rebuilding screens.
Default to least privilege with a request path for more, which is safer than opening everything and tightening later.
Provide a visual permission editor so business administrators can maintain it without developers.
Permission design translates organisational rules into enforceable control. Translate accurately and the system fits the business.
← Previous post
Caching and First Paint in Nuxt SSR
Next post →
From Design File to Design System: Three Agreements with Engineering
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →