Skip to content

Solution validation: Navigating to Settings

What's this issue all about? (Background and context)

How might we make it easier for people to access settings from merge requests?

We will leverage the JTBD statements from the CMS study around code review https://gitlab.com/gitlab-org/ux-research/-/issues/941

Key scenarios from JTBD 3 doc that will inspire this solution validation 1. Imagine that you are in charge of enforcing review of all changes before they are merged into this project. Where would you go to specify the approvers for all merge requests in this project? - Current success path - Navigate to “Settings > General” - Expand the “Merge request approvals” section 1. Consider a scenario where you need to create different approval rules How would you create an approval rule so that one of your colleagues, “Sam Hansen” or “Mary Porter”, must approve? - Current success path - Navigate to “Settings > General” - Expand the “Merge request approvals” section - Click “Add approval rule” - Type in any rule name - Keep “No. of approvals required” with 1 - Select the users “Sam Hansen” and “Mary Porter” approvers - Click “Add approval rule” 1. Imagine that you want the authors of merge requests in this project to use a standard message to describe documentation changes. You and your team have defined a template for this. What would you do to offer this standard message when people are creating merge requests? - Current success path - Navigate to “Settings > General” - Expand the “Merge requests” settings section - Paste the template in the “Default description template for merge requests” field - Click “Save changes”

What are the overarching goals for the research?

  1. Should we introduce navigation to go back to a the last page when dealing with MR settings?
  2. Showing settings in a drawer, does it help with settings?

Originally scoped

What hypotheses and/or assumptions do you have?

  1. Getting back to the product page from Settings is a current pain point.
  2. Using a drawer will help maintain context while accessing settings.
  3. Using modals on top of a drawer will not be confusing to users.

What research questions are you trying to answer?

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

System admins, manager, team lead

What business decisions will be made based on this information?

What, if any, relevant prior research already exists?

Who will be leading the research?

@mle

What timescales do you have in mind for the research?

1-2 weeks

Unmoderated test

  1. Task 1: Imagine that your team has a new process for managing tags in your repository and you need to see which tag is protected. Find out the name of the protected tag for your repository and say it out loud. After completing the task, navigate back to the Repository page.
  2. Task 2: For this task, you will need to remove the approval rule called "Design" from the list of approval rules for merge requests. When you have removed the approval rule, please navigate back to this merge request.
  3. Task 3: Imagine that you want to allow people outside of the Design team to approve this merge request. Change the name of the required approval rule from "Design" to "Team member.".
  4. Question: How would you describe your experience managing settings in GitLab? Is there anything you would change to make it better for your day to day work?

Relevant links (script, prototype, notes, etc.)

workflowsolution validation ~"group::editor" Category:Navigation & Settings devopscreate

Edited by Michael Le