Settings UX - Learnings and recommendations
🎥 You can also watch an in-depth version on Unfiltered.
Why settings?
Settings have been a persistent issue reported by our customers over the last couple of years. The target audience for it is very broad. In short, all GitLab users with permission to change settings are our target audience. This also means that small improvements can result in highly impactful user experience.
@nudalova and I looked into both existing insights and feedback from our customers, as well as results from user research on the Settings.
The overarching goal is to improve the GitLab Settings experience in order to drive user experience and System Usability Scale (SUS) score improvements. Our vision is to help facilitate the alignment on Settings user flows, components, interaction patterns and layouts/templates - ensuring our designers are empowered to build a clear and consistent Settings experience across GitLab. Learn more on &3535
(not-so) Low-hanging fruits
I identified a total of 43 improvements that are "shovel ready" for other stage groups to prioritize &3547.
I then refined the list with 12 items I believed were the lowest hanging-fruits that UX designers could tackle with little to no engineering involvement in the grooming phase. These issues would fix existing bug, UX debt, and UI polish and slightly enhance the settings user experience without the need to invest in huge redesign efforts. &3547 (comment 372447070)
Roadblock
A lesson learned from the "Low-hanging fruits" experience so far is that simply listing problems that need to be solved is not enough. The main challenge here was that since Settings remained under the groupnot_owned group, Ideally, these 'cross-vertical' issues were not prioritized. The bystander effect persisted. Only 5 issues received an update but none of them were prioritized or scheduled yet. We need Product to help us prioritize and schedule these issues together with engineering.
What we heard from designers
I spoke with 10 designers/stakeholders in different stage groups to understand their struggles, successes, and vision for GitLab Settings:
- Plan - @uhlexsis
- Secure - @beckalippert
- Enablement - @sunjungp
- Growth - @matejlatin @timhey
- Monitor - @nadia_sotnikova
- Create - @mnichols1
- Verify - @jj-ramirez
- Package - @icamacho
- UX Research - @katokpara shared some great insights into previous research findings on Settings as well as actionable insights from the Navigation System Usability Scale surveys.
The insights shared by our team of designers were not so different from the actionable insights collected from the Navigation SUS questionnaire, but still helped to reinforce the direction of this initiative.
Challenges when designing settings
Target audience
We know that Settings has a broader target audience, which means users, such as executives, have different technical abilities and most of the time won't be able to set things up in the ci file. We need to be able to design with answers to the following questions in mind:
- How do we cover different personas?
- What are the needs of a technical vs non-technical personas?
Challenges with the UI
- Lack of standardized UI elements and patterns, which leads to inconsistent design. For example, the mix of radio buttons and toggles in the UI.
- Poor visual aspect and interaction design. One the main issues relates to the expand/collapse pattern which makes it difficult to access settings areas.
- UI text can be verbose and not so helpful. The settings copy is not clear in a lot of places. The pattern in use that describes the functionality in the help text is confusing.
Contextual settings
The cost of context shifting for settings means that users are spending extra time to figure out where to find the correct options in order to complete their tasks. The lack of context is an anti-pattern. We will start discussing how contextual settings can be made available to our users in particular situations or product areas, potentially based on data. Some of the recurring challenges were:
- How do we handle group level “defaults” vs project level settings? How do we give users context of settings at the group level? How can we give the user context of why things work the way they are?
- E.g In Verify, customers need to know they cannot enable shared runners in a project because it's disabled at the group level.
- In general, settings are hard to find. We can solve it by bringing settings closer to the thing they affect. For example, by adding entry points to settings in the feature page.
- Also in Verify, users have to go to settings to install a runner. The instructions give you an url for the instance, registration token and so on, you need those to register a runner so you always go to settings. The problem is that people forget to do the registration many times -- because they don't check the settings.
Information Architecture (IA)
Information architecture is another broad topic, that mainly focuses on navigation.
The conversation with the designers just confirmed the known issues. We need to understand how users categorize information about GitLab's Settings, and where they expect to find Settings in GitLab.
Today we know that similar to Navigation, Settings has been a consistent issue in GitLab. Navigation affects the understanding of the product and how users are able to complete their Settings tasks. The reason is settings generally deal with both detail and non-detailed focused tasks. That means when it comes to working with GitLab users tend to manage options specific to the tasks they want to complete, for example managing options such as creating and editing a ci pipeline, issue board, access and permission and so on.
Our research team has a very interesting issue that covers the IA topic: https://gitlab.com/gitlab-org/ux-research/-/issues/983
Documentation
What we see is users going outside of GitLab to get help. They rely heavily on google to figure how to set things up -- ending up in our official documentation. Still, when you check the docs you need time to find where the settings are.
- Every time is about the settings, it should be highlighted in the docs.
- Many of the instructions for settings already exist in the settings ui… so people are trying to get more complex tasks done.
❤
Settings work designers are proud of - Package - Container registry cleanup for tags: a very human and approachable improvement.
- Enablement - Geo-setting UX was updated a few months ago.
- Manage - We were able to improve a couple of settings screens (project & group) updating section labels and descriptions and usability.
- Secure - Investigating whether or not we should consider adding a Settings area for Secure.
What features are coming next for some stage groups
There is some interesting work around GitLab Settings planned in different stage groups today.
- Settings at the group level - there is a desire to bring settings to a higher level. Release Management, Package, Verify, and Create have been working on group settings issues.
- Contextual settings - Secure, Monitor have issues that discuss implementation of in-context settings that can bring configuration closer to users by using the left-navigation menu and shortcuts in the feature pages.
- Information architecture - Growth UX will work on making it easier to get an overview of settings related to the instance, license, upgrade to a higher plan, etc.
Recommendations & next steps
Pajamas guidelines
More guidance and reuse: designers want the out of the box ability to design with settings by reusing UI elements, layouts, as well as making use of documentation and settings best practices. gitlab-org/gitlab-services/design.gitlab.com#709 (closed)
- Define guidelines, templates, patterns for settings.
- Document GitLab Settings patterns in Pajamas as best practices.
- Define guidelines around information architecture - for example how to organise information in Settings, etc.
Empower designers to contribute to settings
- Define plan for iteration - what can we realistically do by the end of this fiscal year?
- Collaborate with the Growth team on defining the vision for settings in the left-menu navigation for the information architecture improvements.
- Facilitate the conversation between stage groups in a workshop like what Growth did around the 1st-time experience in GitLab.
- Find a dedicated PM as a product counterpart to help us moving this effort further.
If this topic or any of these issues interest you, or you are excited to learn more - please reach out to me @rayana
or join the #f_settings
Slack channel.