[UX] Refine how custom permissions are displayed

Background

Any group member with a role of Maintainer and above can invite members and assign them a custom role. But, only an owner can create a custom role within their group.

A custom and static role's "definition" is not clear to the user from the UI. They could look up what a Reporter could do in the table but from the current UI, do not have any description about what the role does.

Problems to solve

Current UX solution to this problem details out permissions in the member page. Each badge represents an allowed permission to the base role. This interaction will not scale as we continue to add more customizable permissions to roles. (MR: !136703 (merged))

Use case	User	Flow	Screens
Assign a custom role to a member	Admin	The admin creates a custom role, assigns to member and confirms that custom role has been assigned. Alternative If the member has not been invited, invite member and assign custom role. If member has a pending invitation, re-assign the member to the custom role. If member is part of subgroups and projects, confirm that member has custom role has been assigned.	Create new role View custom roles Assign to member Custom role assigned
Understand my role and permissions	Member (non admin)	The member (non admin) attempts to complete an action, member (non admin) is restricted from completing action, troubleshoot with system admin to gain access. Assumption: Non-admin users use the member page and role detail to solve this problem. NEEDS MORE PROBLEM VALIDATION**:** When non-admin users are blocked from accessing or completing an action that's relevant to their workflow, what do they do to un-block themselves? This is also related to this issue: Handling visibility of functionality with custo... ( #434080)	Non admin member viewing member page

Additional context (JTBD, past research, personas)

• Main Job: When enforcing my organization's access control policies in a third-party software, I want to limit user access privileges to sensitive information and action, so I can ensure only the people who require access have it and people who should not have access do not.

Persona

Past research informs below:

• Sidney, Systems Administrator
• Priyanka, Platform Engineer (Maintainer)
• Sasha, Software Developer (Non Admin User)

Past Research

• Prototype Validation ux-research#1923 (closed)
• Dovetail InterviewsDesign Pod &7420 (closed)

The Ask

Please tell us how the UX can be improved and provide mockup(s).

Proposal

• Disclose custom role's description in the table and when assigning a custom role
• Simplify the metadata presented in the member's table to indicate only if a role is a custom

Visual Designs & Feedback

To scale the detail shown on the member page UI, I explored disclosing the custom role description across the workflows of creating and assigning a custom role.

Exploration & Feedback

Exploration	Feedback and how we moved forward
Custom Role Table	Using the right Pajama components: A card component is not used for containing a table so I revised the designs to bring it more within Pajamas guidelines Badges are used for metadata and if the table cell consists of data described by the column header then a use of a badge is not needed so I revised the designs so that base role and permissions are represented in simple text. How are customers using descriptions today? We have minimal feature usage to use as reference We opted to bring this question in solution validation
Create role	We discussed the use of an inline form and whether this is the best user experience for creating custom role. Move forward with custom role creation form in another page to help us scale with the # of permissions expected to be customizable
Assign to member	We discussed whether a base role is important context to users in the drop down to choose custom role. Because we don't have early feedback on the feature, we decided to bring this question through solution validation, asking users what level of detail is needed at each part of the workflow I added an action from the dropdown to route user back to settings>roles & permissions page
Custom Role Assigned Option 1 Option 2	Option 1 appears too cluttered and presents information detail on number of permissions that may not be valuable Option 2 Is a scalable approach to detailing custom role but there was concern on how much detail is potentially missing Explore how much detail is needed by users through solution validation Explore options that show more detail

Prototypes

Check out the walkthrough where I give an overview of the final designs that we moved forward into solution validation and an overview of the plan to validate the proposal.

To understand if the experience is an improvement over the current, we built a prototype and tested both the current experience and the proposed experience:

• [B] Proposed
• [A] Current Experience

Solution Validation

🎬 Want a quick(ish) overview? I put together an overview video (6 mins) walking through the goals of the research, the prototype, and the results.

📖 Want to dig into the findings? If you're interested in the more detailed insights, check out the solution validation issue description. (You can also find the full research plan and links to the prototypes that we tested in that issue.)

Final design and specs

Figma link for final designs and specs

Create custom role

Custom Role Table

Group Members (Non Admin)

Group Members (Admin)

Follow up and next steps

• Design for determining the order of permissions in the "Create Role" form will be handled here [FE] Roles and Permissions - determine the orde... (#430924 - closed)
• Designs for dependent permissions will be handled here [FE] Roles and Permissions - automatically chec... (#430920 - closed)
• Designs for providing more detail to all members of custom role permissions here [Design] Show custom role permission details to... (#439823 - closed)