# Purpose Using a thematic roadmap designers will have the ability to focus on a larger problem area -rather than a feature- and to dive deep into a set of related problems based on user needs. This focus will generate a comprehensive experience inclusive of any/all related touch-points in the UI as well as an iterative approach to implementing these experiences. Hence the notion of theming and maintaining focus on that theme until it is delivered in the composite. This approach also builds in the runway for extensible problem and solution validation initiatives that can cover a wider surface area and uncover more nuance than if we focused on a particular problem for a specific feature. For transparency, We are using [this model](https://www.nngroup.com/articles/ux-roadmaps/) from the NNGroup with a few GitLab-specific modifications. At its core, the roadmap is a now/next/future cadence of themes that house multiple activities and features. Associating the cadence with our calendar can be rather subjective and thinking in quarters gives us the flexibility to plan out all necessary design and research activities. | Now | Next | Future | |-----|------|--------| | Start=Current Quarter | Start=Next Quarter | Start=In 2 quarters | We can follow this and make adjustments if themes take more or less time. Generally, if a theme takes more than a quarter to complete, then it should be broken down into a smaller theme. Note: There will be instances where we are working on a feature/capability that is not contained in one of our themes. ~OKR ~bug ~"UX debt" and urgent ~"customer+" / ~customer requests all fall into this bucket and don't require inclusion within a theme to be worked on. Think of themes as the strategic design initiatives we need to complete to hit our target maturity level. The other issues are for maintaining the experience as it relates to our standards and our customer's standards. # Goal ### Product Goal: **Complete Definition**: Companies use GitLab in concert with their **existing security processes and tools** to manage **many** aspects of vulnerability-related risks across the entire application lifecycle. ### UX Goals: - Attain an understanding of complex and nuanced problems, informed by industry standards and best practices - Adhere to the design process and best practices to solve user problems through workflows and comprehensive experiences - Remain focused on a Theme within the scope of attaining Complete category maturity ## Roadmap ### Now | Theme | Status | DRI | Target to design complete | Rem. UX Weight | | ------ | ------ | ------ | ------ | ------ | | Vulnerability Management at Scale | In Progress | @andyvolpe | %"14.6" | 29 | | Vulnerability Lifecycle Depth | In Progress | @andyvolpe | %"14.5" | 25 | | Elevate DevSecOps Maturity | - | @beckalippert | - | - | ### Next | Theme | Status | DRI | Target to design complete | Rem. UX Weight. | | ------ | ------ | ------ | ------ | ------ | | Risked Informed Decision Making | - | @beckalippert | - | - | | Triage Automation | Partially started | - | - | 19 | ### Future | Theme | Status | DRI | Target to design complete | Rem. UX Weight | | ------ | ------ | ------ | ------ | ------ | | On-Demand Reporting | - | - | - | - | ### Complete | Theme | Status | DRI | Target to design complete | Rem. UX Weight | | ------ | ------ | ------ | ------ | ------ | | True Shift-left | {+Design complete+} | @andyvolpe @beckalippert | %"14.3" | 0 | ## Reference <details><summary>Contents of a UX theme</summary> **Theme Title:** The theme title quickly articulates the focus of the theme and its related activities. This is used for recall when planning / discussing or working directly on a theme. **Subject Matter:** A brief statement noting the breadth of the theme and which workflows it covers. This helps understand the scope at a high level. **User Benefits:** These are the benefits a user would directly receive when the theme is completed. Related Jobs Documented JTBD that relates to the user benefit. These are written as jobs excluding the motivation and result. **Business Objective:** What do we stand to gain from completing this theme. This is our internal motivation for working on this theme whereas the user benefits are our external motivation. Often this is measurable or quantifiable but that doesn’t have to be the standard. **Sub themes:** These can be listed as capabilities and act as an itemized list of topics to cover in the larger theme. We can close the theme when all of these are delivered and research hasn’t uncovered additional sub themes. Research topics: Open and high-level questions relating to the theme. These act as an initial guide for us to determine if problem validation is required in the theme. The topics also give us a sense of our understanding and confidence in the theme. **Related product themes:** One or more themes from the product or company vision that relates to the UX theme. This ensures we are keeping the overall direction (the forest) in mind when we are working on the issue (the trees) in the theme. </details> <details><summary>Old Details</summary> Feature types - Primary: Used to complete a task - Secondary: May be used to complete a task but isn't required - Auxiliary: Supports task completion activity but the task isn't solely reliant on this capability <details><summary>[Vulnerability Management at Scale](url)</summary> Summary: ### Subject matter Prioritization / Triage experiences at all levels of the application ### User benefit Users will be able to efficiently manage large quantities of vulnerabilities across multiple projects. #### Associated job family(s) - **Big:** Assessing my organization’s security stance - `Little:` Maintain situational awareness of the security of my organization’s assets - **Big:** Reducing known security risks - `Little:` Addressing detected business-critical vulnerabilities ### Business objective </details> ### User Benefit Users will be able to efficiently manage large quantities of vulnerabilities across multiple projects. ### Associated job family(s) - **Big:** Assessing my organization’s security stance - `Little:` Maintain situational awareness of the security of my organization’s assets - **Big:** Reducing known security risks - `Little:` Addressing detected business-critical vulnerabilities ### Areas of focus & opportunities **Vulnerability Reports** | Opportunity | Issue | Customer Req | Insight | Validation Type | UX Weight | Feature type | Status | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | | Multi-select/bulk actions | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/267582) | | | Solution | 5 | Primary | ~"workflow::validation backlog" | | Vuln Grouping | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/267588) | | | :gear: [Problem](https://gitlab.com/gitlab-org/ux-research/-/issues/1295) | 6 | Secondary | ~"workflow::problem validation" | | Custom report views | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/267572) | | | :gear: [Problem](https://gitlab.com/gitlab-org/ux-research/-/issues/1295) | 7 | Primary | ~"workflow::problem validation" | | Vulnerability details preview | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/267590) | | | Solution | 5 | Secondary | ~"workflow::validation backlog" | | OWASP type as primary identifier | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/119029) | Yes | | TBD | 2 | Secondary | ~"workflow::validation backlog" | **Security Dashboards** | Opportunity | Issue | Customer Req | Insight | Validation Type | UX Weight | Feature type | Status | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | | Metric: Vulnerabilities by age | [Link](https://gitlab.com/groups/gitlab-org/-/epics/5354) | | | Solution | 5 | Secondary | ~"workflow::planning breakdown" | | Metric: Vulnerabilities by OWASP type | No | | | Solution | 5 | Secondary | ~"workflow::validation backlog" | **My Security Center** *(Formerly Instance Security Dashboard)* | Opportunity | Issue | Customer Req | Insight | Validation Type | UX Weight | Feature type | Status | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | | View/Manage assigned vulns | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/292251) | | | Problem | 8 | Primary | ~"workflow::validation backlog" | ____ ## Configurability and flexibility Users will be able to create and manage capabilities that introduce efficiencies required by a small team working in a larger organization. ### Associated job family(s) - **Big:** Enforcing compliance with security best practices and org requirements - `Little:` Implementing security controls into developer workflows - `Little:` Implementing security scanning policies ### Areas of focus & opportunities **Settings/Configuration** | Opportunity | Issue | Customer Req | Insight | Validation Type | UX Weight | Feature type | Status | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | | Configurable Auto-close (resolve) vulns | No | Yes | | Solution | 4 | Primary | ~"workflow::validation backlog" | | Configurable Auto-dismiss vulns | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/299552) | Yes | | :gear: [Problem](https://gitlab.com/gitlab-org/ux-research/-/issues/1295) | 4 | Primary | ~"workflow::problem validation" | | Configurable Vulnerability_Check | No | | | TBD | 4 | Primary | ~"workflow::problem validation" | | Disallow status/severity changes by permission level | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/208482) | Yes | | :gear: [Problem](https://gitlab.com/gitlab-org/ux-research/-/issues/1295) | 7 | Primary | ~"workflow::problem validation" | **Vulnerability Report** | Opportunity | Issue | Customer Req | Insight | Validation Type | UX Weight | Feature type | status | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | | Configurable report Export | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/267581) | Yes | | :gear: [Problem](https://gitlab.com/gitlab-org/ux-research/-/issues/12) | 6 | Primary | ~"workflow::problem validation" | ___ ## Deeper Vulnerability Lifecycle Capabilities A. Users will be able to add and/or manipulate vulnerability information to maintain an accurate SSOT of the vulnerability. B. Users will be able to work transparently with complementary experiences seen elsewhere in GitLab. ### Associated job family(s) - **Big:** Reducing known security risks - `Little:` Addressing detected business-critical vulnerabilities ### Areas of focus & opportunities: **Vulnerability Details pages** | Opportunity | Issue | Customer Req | Insight | Validation Type | UX Weight | Feature type | Status | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | | Change status w/comment | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/13640) | Yes | | Solution | 4 | Primary | ~"workflow::validation backlog" | | Change severity w/comment | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/204820) | Yes | | Solution | 4 | Primary | ~"workflow::validation backlog" | | Support comments/threads | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/273800) | | | TBD | 2 | Primary | ~"workflow::validation backlog" | | Richly formatted [GFM] comments | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/273800) | | | TBD | 2 | Secondary | ~"workflow::validation backlog" | | Full vuln activity history | No | | | TBD | 2 | Auxiliary | ~"workflow::validation backlog" | | Support To-do's | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/273066) | | | TBD | 3 | Secondary | ~"workflow::validation backlog" | | Support Assignees | No | | | Problem | 8 | Primary | ~"workflow::validation backlog" | [Vulnerability Details page enhancements](https://gitlab.com/gitlab-org/gitlab/-/issues/284337) **Issues** | Opportunity | Issue | Customer Req | Insight | Validation Type | UX Weight | Feature type | Status | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | | Attach multiple vulns to an issue | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/267589) | Yes | | :gear: [Problem](https://gitlab.com/gitlab-org/ux-research/-/issues/1295) | 5 | Primary | ~"workflow::problem validation" | _____ ## Vulnerability Prevention Users will be able to enforce requirements for DevOps flows to reduce the chances of vulnerability escapes into production or critical pre-production environments. ### Associated job family(s) - **Big:** Enforcing compliance with security best practices and organizational requirements - `Little:` Implementing security controls in developer workflows ### Areas of focus & opportunities **MR** | Opportunity | Issue | Customer Req | Insight | Validation Type | UX Weight | Feature type | Status | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | | View vulns in a single list (sec tab) | [Link](https://gitlab.com/groups/gitlab-org/-/epics/4428) | Yes | | ✅ - [Solution](https://gitlab.com/gitlab-org/ux-research/-/issues/910) | 5 | Primary | ~"workflow::blocked" | | Code review from vulns | [Link](https://gitlab.com/gitlab-org/gitlab/-/issues/12903) | | | [Solution](https://gitlab.com/gitlab-org/ux-research/-/issues/275) | 3 | Primary | ~"workflow::validation backlog" | --- # Post evaluation After https://gitlab.com/gitlab-org/ux-research/-/issues/1295 has completed, we will refine the list in priority order and create a general roadmap for the year. We will also create a new label that defines issues planned for this year to assist with identification and potential collaboration opportunities for other designs to work on. </details> ## Measuring success