Predefined Roles
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 a P0 objective and was the number 1 company priority in 2024.
Solution: Offer 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 our users enforce the principle of least privilege and offer more restrictive RBAC solutions in the “DO Simple” way.
Results
Over 6,000 team members and 13% of API tokens (several million daily hits) have been assigned the newly introduced predefined roles within the first few weeks and seeing about a 23% increase in new role usage month over month.
The largest collaboration DO has seen in years
Role
Product Designer Lead, workstream owner of the entire experience
Completion Time
102 business days
Collaboration
Product Designers, PMs, Technical PMs, Back-end Engs, Front-end Engs, Insights, Marketing/GTM, Pdocs, UX Research, Support, API, Engineering Directors and Managers
Research
Gathering and organizing user feedback
With RBAC being such a growing need amongst users, I had plenty of user feedback to gather and sort through from over the years. I filtered through NPS and CSAT surveys, idea board comments, customer channels, and conversations with CSMs to find any mention of role/permission related feedback. From there, I organized the data into sections: simpler UX, role archetypes requested to meet needs, and control-related access.
User interviews so we can meet their needs
Using the organized data from above, I collaborated with the UX research team to help formulate user interview questions to confirm if the information I uncovered in my digging would meet user needs and wanted to know more about how our users use their teams to control access. The UX research team lead 13 user interviews and helped us formulate our path forward towards a simple experience to provide more granular access.
Research Findings
- Users would like to assign the role to team members while inviting them to teams
- Users have a resounding frustration with AWS and GCP and think their role management is too complicated and desire simplicity and less granularity than what is offered through those providers
- An overwhelming majority of users wanted access to most resources and actions except for deletion, while the 2nd most needed role was a read-only role for the whole platform
- Users want custom control of certain permissions and were mostly satisfied with the CRUD actions (create, read, update, delete)
- Users want to be able to limit roles to team members by project
Strategy, Process, & Vision
UX Roadmap
It was clear from research that many users had many different needs that all led back to a more granular RBAC solution. Knowing this, I separated this solution into a UX roadmap consisting of 3 unique parts divided by both needs and effort: predefined roles, custom roles, and conditions.
Documentation
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.
While not interesting to show, this spreadsheet drove 80% of the effort for the predefined roles launch which initially began with an unscalable attempt to screenshot every screen to define permissions. I quickly switched to crafting this collaborative spreadsheet using an engineering doc with much of the platform already documented as the foundation. This approach was well-received, enabling cross-functional collaboration and a single SoT (source of truth).
I was allowed 10% of every product designer’s capacity to help fill out this spreadsheet, encompassing the permissions and actions for every single experience of DO. I assigned sections of the products that I knew that the designers would be most successful in handling.
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.
Assigning the New Roles
Users (with the correct associated permissions of course) can change the role of users in their team through this modal from the team settings.
Role Communication
Communicating with users is nearly as important as providing the experience itself. I integrated a new email communication path of notifying the user when their role has been changed and what that role can do. I anticipated a lot of roles changing due to this launch of additional roles. I additionally added a role reminder in the user’s account dropdown so they can be more conscious of what role they have in what team easily.
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.
🤔 Challenges
- This was my very first task when I first joined DO and I’ve never worked on such a technical product before so there were some learning curves that I had to overcome in order to provide the best experience for DBaaS users
- The ability to assign specific users to Topics was removed out of this first launch Kafka but allows us to see if this feature is highly requested by production Kafka users
✨ Opportunities
- Beta Users requested several Kafka features that they would like to see: Kafka Connect, Kafka MirrorMaker, and ZooKeeper
- This first GA launch of Kafka doesn’t have the ability to assign users to a specific Topic but it is something the DBaaS team and users would love the ability to do to increase security in their architecture
👨💻 User Feedback
DigitalOcean Managed Kafka simplified and sped up our management of Kafka. Self-managing Kafka, it would take about eight weeks to go from initial development to a production-ready system. With DigitalOcean Managed Kafka, we cut that timeline to just one week.
-Daniel, CTO of a sports tech company
The ability to create topics using a UI is super nice. It used to be a CLI job.
-unknown survey user
✍️ Peer Feedback
