GitLab Next

Background

The Compliance Dashboard has evolved to a point where the current MR view is no longer sustainable. Recent learnings and the general evolution of the dashboard has highlighted new opportunities for iteration. In order to pursue these new opportunities, we'll need to split the dashboard into two views: Projects and Merge Requests.

Proposed Solution

JTBD: When I have complete visibility into adherence to policies, I want to know what is not compliant, so that I can address issues.

• Convert the current Merge Requests view to the new Projects view
  • Each row should represent a Project
  • Each row should be expandable to show the data that's most important to see at a high-level for each project, e.g.:
    • Project security grade
    • Current MR approval settings
    • Protected branches
    • Maintainer(s)
  • The most recent MR for each project should become a secondary data point for each project line item
  • Purpose of this view: Cameron (Compliance Manager) should be able to view all of their Projects to quickly determine where they need to focus their attention

Mockups (Figma)

Checklist

workflowdesign

• Product Designer leads the team in ideating about potential solutions and engages the PM and Engineers to determine whether the proposed solution meets business goals and is technically feasible.

workflowsolution validation

Solution validation is appropriate when we don't have high confidence that the proposed solution will meet users expectations.

• PM and Product Designer review the goals and research questions to determine the best research method to use.
• PM and Product Designer discuss user recruitment needs and clarify the research study's goals, research questions, and hypotheses. Once a draft is complete, the Product Design Manager reviews and provides feedback.
• Product Designer begins crafting a screening survey in Qualtrics
• Product Designer creates a recruitment request issue in the GitLab UX Research project using the available issue template. Assign it to the relevant Research Coordinator.
• The Research Coordinator will perform a sense check to make sure your screener will catch the people you’ve identified as your target participants. If there are multiple rounds of review, the Coordinator will pause activities until uncertainty about your screening criteria is resolved.
• Product Designer drafts the test plan in collaboration with the PM. When a first draft of the test plan is complete, the Product Design Manager and UX Researcher review and provide feedback.
• Product Designer prepares the design assets needed for the study. This will likely be a clickthrough wireframe or prototype (low or high-fidelity screenshots, or an interactive UI prototype).
• Product Designer forwards research study session invites to the UX Research calendar and any other interested parties (Product Designer, PMs, Engineers, etc).
• Product Designer leads (moderates) the usability sessions. PM should observe research study sessions and take note of insights and pain points. It is beneficial to also invite Engineers to shadow the research study.
  • (Optional) Run a pilot session with an internal participant.
• After the research study sessions conclude, the Product Designer updates the recruitment request issue in the GitLab UX Research project. The Research Coordinator will reimburse participants for their time.
• PM and Product Designer work collaboratively to synthesize the data and identify trends in Dovetail, resulting in insights.
• Product Design Manager reviews insights and provides feedback, if needed.
• Product Designer updates the solution validation issue with links to the insights in Dovetail.
• PM updates the opportunity canvas with the insights.
• PM articulates success metrics for each opportunity and ensures a plan for product instrumentation and dashboarding are in place.

What are the overarching goals for the research?

To better understand the needs of the users with regards to using the compliance dashboard including validating hypotheses, getting questions answered, understanding existing pain points without these features and who has those pain points/why.

What hypotheses and/or assumptions do you have?

• True We believe the Merge Request view in the Compliance Dashboard is providing some value, but is missing key project related information to make insights actionable.
• Possibly We believe users need to see additional information such as maintainers, merge request approval rules, protected branches, and the corresponding project security grade.
• Not sure We believe reusing the data displayed on the current Merge Request view within projects will provide better context and faster decision making
• True We believe users want to be shown the projects that need their attention, and will prefer to have them separated from projects that are compliant
• True We believe users want direct feedback on how to resolve violations
• Maybe We believe adding a shortcuts to Merge Request Approval Rules, Protected Branches, and Maintainers are both useful and necessary.

Proposed Research Method: Quick demo for feedback