Solution Validation: View permissions on custom role

What did we learn

Results
Overall, feedback to the proposed view for custom role permissions is positive, "simple and pleasant" and met user's expectation. The proposed view with edit functionality tested successfully for admins managing member's role with direct membership and not as successful for admins managing direct or inherited access.
Insights below and in Dovetail. Walkthrough of the problem, validation and results walkthrough

Task completion

Task Admin Non Admin
View own role 80% 100%
View team member’s role Not tested 100%
Edit Role 100% Not tested
Edit role (indirect access) 60% Not tested

Proposed designs for viewing custom role's permissions met user's expectations

Participants successfully used drawer to understand permissions details, diirect feedback include "simple and pleasant UI". Participant who did not complete the task attempted to click on their profile to view more detail about their role.

Viewing role details is rated of high importance, viewing role details of team members considered important for transparency and collaboration.

Recommendation: Move forward with custom role detail view using drawer.

The same view is valuable to default roles and other member functionality

When viewing details on default role, participants noted that it be helpful to lay out a concise description instead of viewing the table linked in documentation.

It is also observed that for a few participants, they attempted to click on the entire member row to view more details. This gives us good signal to move forward with moving all details from the member row table into the drawer.

Recommendation: Implement the same interaction for default roles, partner with UX writing to develop descriptions for all default roles. Move forward with containing all additional details of member into the drawer.

Admin's ability to change a direct member's role in drawer meets expectations

For direct membership role changes, 100% of admins completed the task successfully and expressed that interaction met their expectations.

The pop-out drawer is perceived to be a natural interaction and gives the right degree of control for inspecting current access rights and updating user's current access rights. 1 participant expected a follow up notification to confirm changes after clicking save.

Recommendation and design update: Move forward with having the editing functionality in the drawer. Include a follow up toast notification for saving role changes.

Admin's ability to use the drawer for indirect or inherited role changes did not meet expectations

For indirect membership role changes, only 60% of admins completed the task successfully and expressed the task to be more difficult. Participants attempted to use "Manage roles" to complete this task and for some participants, the information bubble is helpful and gave information on next steps.

Recommendation and design update: With indirect source role changes, explore different views to make information on source clearer for first iteration. On second iteration, explore the possibility of directly changing roles for indirect or inherited access.

We revalidated admin/non admin insights when it comes to access rights

Employee roles and principles of least privilege remain top factors in determining access rights

  • Admins determine access typically by role, job function and responsibilities and try to manage them through a centralized platform.
  • Admins abide by principles of least privilege and meet requirements through intermittent auditing and manual testing of roles.

Admins aim to resolve access issues quickly and communication/workflows are completed through internal systems or email/slack

  • Communicating access is done through various forms; from onboarding, to email, to in-app communication. There is a slight reliance for the particular tool and app to provide notifications regarding access
  • Admins typically receive access request through email/slack or a ticketing system and aim for fast resolution
  • Non admins understand that they are given limited access, and will go through self-research when access is not as expected or go through internal system for access requests

Background

We have a proposal to provide users with context to permissions related to their custom role

What hypotheses and/or assumptions do you have?

  • Participants will complete task successfully (success rate at 80%)
    • View custom role's permissions
    • Edit role
  • The detailed view of a member's custom role and permissions meets user's requirements
  • Admins or Maintainers of groups understand how to edit a user's role

What questions are you trying to answer?

  • Gain context on how users gain use their role and permissions, where do they go, how often do they do this?
  • With proposed designs, can users navigate to where they may view more details about their role?
  • Is it intuitive to admins to edit role through the drawer?

What research methodology do you intend to use?

  • Unmoderated usability (GitLab users)
  • Non admin & admins (10 total participants)
  • Ultimate and above

What persona, persona segment, or customer type experiences the problem most acutely?

  • Non administrator users with custom roles

What business decisions will be made based on this information?

  • This will help inform how we build this functionality

What, if any, relevant prior research already exists?

Who will be leading the research?

What timescales do you have in mind for the research?

  • 1 week

Relevant links (problem validation issue, design issue, script, prototype, notes, etc.)

Checklist

  • Draft goals and objectives, review with collaborators
  • Create test plan, review with collaborators
  • Build prototypes
  • Launch study on usertesting
  • Analyze and communicate findings
  • Close issue 🎉
Edited by Ilonah Pelaez