From a complex permission model to a simpler management experience
Managing user access had become increasingly difficult as the product and permission model grew. The challenge was to make access easier to understand without exposing all of the underlying complexity.
Managing access had become increasingly complex
As the product grew, so did the number of things administrators needed to manage. Permissions were difficult to understand, access changes could be manual, and the underlying permission model didn't necessarily match how customers thought about managing their teams.
The challenge wasn't simply to redesign a permissions screen.
We needed to turn a technically complex permission model into an experience that administrators could understand and confidently manage themselves.
Understanding the underlying permission model
Before exploring solutions, I wanted to understand why managing access was difficult.
- How permissions were structured today
- How administrators currently managed access
- Where the existing model created confusion
- Which tasks were most common
- What constraints existed in the underlying product architecture
- Where user expectations differed from the existing permission model
Mapping the existing experience
I mapped the current permission structure and management process to understand where complexity entered the experience.
This helped us separate two things: the complexity of the underlying system and the complexity that users actually needed to deal with.
Three areas of friction shaped the direction
The permission model was difficult to understand
The underlying structure made sense from a product and technical perspective, but it wasn't always obvious to administrators what a particular permission meant or what access someone would actually receive.
Managing access could be too manual
Common access-management tasks required administrators to understand several parts of the existing system, creating unnecessary effort for something that should be straightforward.
The existing model wouldn't scale easily
As the product continued to grow, simply adding more permissions to the existing experience would increase complexity rather than solve it.
Create a self-service experience without exposing unnecessary complexity
The solution needed to work within the existing permission architecture while supporting the most common access-management tasks.
- Work within the existing permission architecture
- Support the most common access-management tasks
- Be understandable for administrators
- Provide enough flexibility without overwhelming users
- Create a foundation that could scale beyond the initial MVP
Keep the complexity in the system, not in the experience
Transparent, but overwhelming
Giving admins visibility into every permission made the system transparent, but increased cognitive load and made common tasks harder.
Simple, but uncertain
Hiding the underlying model made the interface simpler, but left admins uncertain about what users could actually do.
We deliberately didn't solve everything
The long-term permission model could support much more granular access management. For the MVP, we focused on the most common use cases and the subscription level.
This allowed us to:
- solve the highest-value problems first
- reduce implementation complexity
- validate the new model with real users
- create a foundation for future permission levels
A clearer management experience
Clearer role-based concepts and focused workflows hide unnecessary complexity while preserving control.
Make permissions understandable
Instead of simply renaming roles, we needed to make the relationship between users, roles and subscriptions visible.
Make common actions self-service
Common tasks such as inviting users and changing access were designed to be completed directly in the product.
Design for scale
Although the MVP focused on subscription-level access, the structure was designed with a future model of organizations, markets, products and features in mind.
We solved the highest-value problems first
Rather than attempting to solve every permission-management scenario at once, we focused the MVP on the highest-value use cases.
This allowed us to validate the new approach while keeping the initial scope manageable for both design and engineering.
I worked closely with the team through implementation to make sure the experience translated correctly from prototype to product and to resolve questions that emerged during development.
The goal wasn't to remove complexity from the product. It was to stop making users carry that complexity.
This project reinforced the value of understanding the system first and simplifying the experience second.