Secure Access Control
Enable secure and controlled access to sensitive operations
Roles & Permissions Design
OUTLINE
Key Details
Status
Shipped-GA
Type
New Feature
My Role
Design Lead
Prod-Dev Process
Agile (2 weeks sprints | 3-4 sprint deployment)
Deliverables
Exploratory concepts, High-fidelity prototypes, Interaction guide for hand-off
Overview
When we began building access control into Staybl, there was no formal system in
place.
Permissions were handled
implicitly in code, with engineers defining access on a case-by-case basis. This approach worked
early on, but as the
platform expanded into financial operations, compliance workflows, and multi-role usage, it became
increasingly fragile.
I led the design of a Role-Based Access Control (RBAC) system from scratch, creating a scalable,
intuitive framework that
allows administrators to define who can access what, across the entire product.
The solution centered on a simple but powerful model: structuring access by product domains and
assigning clear,
progressive permission levels (Admin, Editor, View, No Access). This aligned system behavior with
how organizations
naturally think about roles and responsibilities.
Key Metrics and Impact
- 1. Reduced time to configure roles significantly (from fragmented, manual processes to a single structured interface)
- 2. Eliminated dependency on engineering for most access-related changes
- 3. Reduced risk of over-permissioning through clearer access boundaries
- 4. Improved admin confidence and speed in decision-making
- 5. Established a scalable foundation for future product expansion
Framing the Problem
Designing RBAC from scratch is deceptively complex. The obvious approach, listing out permissions and assigning them to roles, often leads to systems that are technically complete but practically unusable.
The real challenge was deeper:
“How do we design an access control system that feels intuitive to humans, while remaining robust enough for complex, high-stakes environments?”
This meant solving for three things simultaneously:
- 1. Giving admins enough flexibility to reflect real-world roles.
- 2. Ensuring sensitive actions are properly controlled.
- 3. Keeping the system simple enough to use without hesitation.
Business Motivation
As the product matured, it began supporting more sensitive operations like financial transactions, compliance oversight, and organizational workflows.
Without a structured access system:
- 1. Sensitive actions were difficult to control consistently
- 2. Teams relied on engineers to manage permissions
- 3. There was no clear way to audit or standardize access
This created operational inefficiencies and introduced security risks. To support enterprise use cases and regulatory expectations, the business needed a robust, flexible access control system.
Business Goals
Lower Engineering Dependency
Reduce engineering overhead for access management
Enterprise-Ready Access
Support enterprise customers with complex role structures
Scalable Access System
Ensure the system scales with new features and modules
UX Goals
The UX goals for the RBAC system are as follows:
- 1. Make role creation and management intuitive for non-technical admins.
- 2. Reduce cognitive load when assigning permissions.
- 3. Ensure users can quickly understand what each role can do.
- 4. Provide a consistent and predictable interaction model across the system.
- 5. Minimize errors and hesitation during configuration.
What was I solving for?
The core challenge wasn’t just adding permissions; it was designing a system that balances:
- 1. Clarity – Users must understand what they’re configuring
- 2. Control – Sensitive actions must be properly restricted
- 3. Scalability – The system must grow with the product
Additionally, I needed to address a key mismatch:
“Users think in roles and responsibilities, while systems operate on permissions.”
The solution needed to bridge this gap seamlessly. From speaking to customers, we were able to gather their use cases (Names of customers modified/hidden for confidentiality):
“I need visibility into transactions and audit logs without the ability to modify anything, so I can ensure regulatory compliance without risking accidental changes.”
~ Adaeze Okonkwo, Compliance Officer
“My team handles transfers and beneficiary management daily—I need to give them enough access to do their jobs efficiently, but not full control over sensitive configurations.”
~ Tunde Balogun, Operations Manager
“I’m responsible for managing access across teams, and I need a clear, reliable way to assign roles without depending on engineers or worrying about giving too much access.”
~ Greg Bessinger, System Administrator
Ideating a Solution
From conversations with some of our users and internal stakeholders, a clear pattern
emerged: the issue wasn’t
just missing access control; it was the lack of a clear structure for defining responsibility.
Early explorations through sketches and whiteboard sessions tested granular permission matrices
and feature-based
toggles. While flexible, these approaches quickly became complex and hard to reason about during
reviews. Even simple
role setups felt overwhelming.
This led to a key shift:
“Users think in roles and responsibilities, while systems operate on permissions.”
I reframed the solution around how users naturally think about access:
- - By product domains (e.g., Transfers, Beneficiaries, Audit Logs)
- - By levels of control within each domain
From this, I developed a simple model:
- 1. Define a Role
- 2. Assign access across domains
- 3. Select a clear access level: "Admin", "Editor", "View", or "No Permission"
This approach balances flexibility with clarity, creating a system that is easy to use, scalable, and aligned with real-world roles.
Flowchart
Design Explorations
Solution Demo
Summary
Designing RBAC from scratch wasn’t about introducing permissions; it was about defining how control works across the product.
By grounding the system in product domains and simplifying access into clear levels, I created a model that is both powerful and easy to use. The result is a system that:
- 1. Scales with the product
- 2. Reduces operational friction
- 3. Improves security through clarity
- 4. Aligns with how users naturally think about roles
Ultimately, the success of this design came from a simple principle: Clarity is what makes complex systems usable.
Looking Ahead
With a strong foundation in place, there’s room to make the system even more powerful:
- 1. Introducing audit trails for tracking permission changes
- 2. Creating predefined role templates for common use cases
- 3. Providing previews of what a role can access across the product
- 4. Exploring conditional access for more advanced control
Designing RBAC from scratch wasn’t about adding a feature. It was about defining how trust, responsibility, and control operate within the product.
And getting that right made everything else easier.