DigitalOcean | Cloud Computing & HostingIAMAccess control
RBAC - Predefined Roles
Expanding role options so teams can enforce least privilege without complexity, delivered in the "DO Simple" way.
Problem
With only 3 available roles at the time, the demand for more granular access to secure users' infrastructure was loud. Users needed a way to further isolate access to managing resources, thus, becoming the number 1 company priority in 2024.
Solution
Ship additional roles for users to select from based on the most common use cases and user requests and help them easily assign that new access.
Goals
Help admin users enforce the principle of least privilege, offer more restrictive RBAC solutions that still feel simple, and set the platform up for the next phases of access control.
Launch impact
Results
In the first weeks after launch, newly introduced predefined roles reached broad adoption across teams and API usage, with strong continued uptake as customers refined how they govern access.
0+
team members assigned predefined roles
Update: 1.5 years later, ~28,000+
0%
of API tokens on the new roles (millions of daily hits)
~0%
initial month-over-month growth in new role usage
Scope & collaboration
The largest collaboration DO has seen in years
Permissions touch nearly every surface of the product, so alignment across the entire product org was crucial to ship coherently and quickly.
0
products affected
0
product designers
0
front-end engineers
0
total contributors
- My role
- Product design lead and workstream owner for the end-to-end experience.
- Timeline
- 102 business days from kickoff to general availability.
- Collaboration
- Product designers, PMs, TPMs, backend and frontend engineering, Insights, Marketing/GTM, product docs, UX research, Support, API, and engineering directors and managers.
Research
Gathering and organizing feedback
RBAC demand showed up everywhere. I synthesized years of signals from NPS and CSAT, idea boards, customer channels, and CSM conversations, then grouped themes into simpler UX needs, requested role archetypes, and control over access.
User interviews
With UX research, we validated those themes through 13 interviews, focusing on how teams invite collaborators and govern access day to day. Findings shaped a simpler path to more granular prebuilt roles.
Research findings
- Assign a role at invite time; don't force a default-then-reassign loop.
- Users compare us to AWS and GCP IAM; they want less overwhelming granularity and clearer defaults.
- Most wanted broad access except delete; the next most common need was a true read-only role across the platform.
- Users want custom control of certain permissions and were mostly satisfied with the CRUD actions (create, read, update, delete).
- Project-scoped limits on who holds a role mattered for larger orgs.
Strategy, process, and vision
UX roadmap
Research pointed to one north star: granular RBAC that still feels DO simple. I framed the roadmap in 3 distinct parts by need and effort:
- Predefined roles (this launch)
- Custom roles
- Conditions for even finer control
Documentation & system rules
I executed a vast documentation effort in order to establish UX rules to be used across the entire platform for current and future permission and role needs. I laid out guidelines touching on: when to hide content from users who don't have permission to interact with it, how we define CRUD actions (what is technically happening vs what is happening from the perspective of users), how to display permission-related errors, and created experiences around the platform to increase role awareness and communication.
One spreadsheet to rule them all
While not interesting to show, this spreadsheet became the single source of truth and about 80% of the launch effort, after we moved off an unscalable "screenshot every screen" approach.
I coordinated ~10% of every product designer's time to complete rows for their domains, using an existing engineering inventory as the foundation. I assigned sections of the products that I knew that the designers would be most successful in handling.
This approach was well-received, and enabled fast cross-functional collaboration to keep the initiative momentum going.
Experience & communication
Experience & communication
Invite team members with a role
Uncovered from research, I addressed the need to add the ability to select a role while inviting team members into the DO team. Previously, users needed to invite a team member with a default role and then reassign that role after they have joined. This saves a giant step for users and saves time with role management duties.
Assign predefined roles
Team owners, or users with the correct associated permissions, can update members' roles from team settings through a focused modal that explains scope and impact.
Role communication
Communicating role changes is as important as the UI itself. I added email notifications that explain when a role changes and what that role can do, plus an account menu reminder so users can quickly confirm their active role per team.
It's also just as vital to celebrate the little moments. I added a banner welcoming new users into their teams and added another line of communication about their role.
Check out predefined roles - created by me!
See it on DigitalOcean
Official launch post with product context and user impact.
🧑💻 User feedback
“We create a new resource in DigitalOcean for every customer we onboard and granularity in setting up access control is critical for the success of our products. RBAC capabilities with predefined roles available today are going to help us secure and limit access to authorization. We have been part of the beta program and are excited to use this at scale in our production environment.”
✍️ Peer feedback
Highlights from internal recognition after the launch.