GitLab Settings Prioritization & Scope
We have consistently received feedback from customers expressing the difficulty in discovering, finding, and recalling where to find specific settings within GitLab. This epic is to prioritize and address the highest priority pain points. **Priority #1 - Information Architecture** Help guide users to find and discover the settings they need. How to solve: - [ ] Conduct UX Research to understand baseline findability and usability - https://gitlab.com/groups/gitlab-org/-/epics/4513 - [ ] Conduct an unmoderated, closed card sort to learn how users organize our existing settings. - [ ] Make organizational/categorization changed based on the above research outcome. - [ ] Collaborate with Navigation Project to answer: Where do users expect to find settings in GitLab. - [ ] Restructure the Settings pages/content to limit the number of progressive disclosure patterns and balance the amount of content presented to users (Hick's Law). - [ ] Document guidelines in Pajamas for usafem layouts, and Settings best practices so that designers can leverage of more more guidance and reuse. https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/709 **Priority #2 - Search** Help users control their own actions and find the settings they need. How to solve: - [ ] Evaluate ways to incorporate search capabilities within the existing Settings experience. - Option 1: Search within each Settings page https://gitlab.com/gitlab-org/gitlab/-/issues/23635 - This option does not solve our main use cases. It should be seen as a possible short-term solution only. - Option 2 (Recommended): Search the application globally - https://gitlab.com/gitlab-org/gitlab/-/issues/241317 - This option helps solve some of our discoverability and findability concerns with Settings. - [ ] Build chosen option. *Search does not eliminate the need to address our Information Architecture challenges. **Priority #3 - Contextual Access** Provide quick access to relevant settings without sending users out of their current context. How to solve: - [ ] Evaluate structural ways to support top-down and bottom-up pathways to Settings throughout the application. Ideally, we provide a solution that is built and maintained in a single location (SSOT) with the capability to surface it from anywhere in the application. - Option 1: Implement a [drawer](https://design.gitlab.com/components/drawer/) that can appear on any page within the GitLab application that pulls content from Settings. Content needs to be actionable from within the drawer. https://gitlab.com/gitlab-org/gitlab/-/issues/273554 - (Post-MVC): Each stage or stage group is responsible for applying the drawer (sourcing and maintaining their settings) to their own use cases. - Option 2: ???? - [ ] Build chosen option. *Additional research is not needed to determine IF we need to support top-down and bottom-up pathways. Research may be needed to validate the option we move forward with but can be limited to testing 5 heavily used settings. **Priority #4 - UI Cleanup https://gitlab.com/groups/gitlab-org/-/epics/3547** Improve overall interaction and aesthetics to increase the usability of our application. How to solve: - [ ] Assign existing UI-related issues to various stage groups and treat it like a burndown list (possible shared OKR?). NOTE: RELATED ISSUES TO BE ADDED TO THIS EPIC.
epic