Product Direction - UX Paper Cuts

The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.

UX Paper Cuts overview

The UX Paper Cuts team has a unique scope; we are responsible for identifying and fixing small yet impactful usability issues across the GitLab product. The term “paper cut” refers to a small usability or accessibility issue that can cause annoyance or frustration for our users and customers. In aggregate, these paper cuts can impact the overall impression users have of the product and brand.

Mission and vision

The UX Paper Cuts team continuously improves the user experience by addressing small usability, accessibility and design consistency issues. By focusing on small details across the entire product, the team helps create a more polished and user-friendly interface, leading to increased user satisfaction, engagement, and ultimately a more successful product.

What we work on

By default, the UX Paper Cuts team does not take on new feature work, nor is the team used as a resource for another Group. Instead, the team focuses on usability and accessibility issues, design inconsistencies, and out-of-date UI across the entire product.
The typical or canonical UX paper cut is a small or seemingly insignificant problem that can cause annoyance or frustration for users but paper cuts can at times be larger in scope, and for these the team partners with Product and UX Research.
Like the Personal productivity team, UX Paper Cuts doesn’t work within a specific product area, but across the product as a whole.
UX Paper Cuts work can look like (smallest to biggest):
- A small paper cut such as migrating components to the Pajamas design system, improving product accessibility and increasing design consistency.
- A larger design change to a component or feature.
- A series of many similar paper cuts and design updates with a theme. See accessibility.
- Helping to refresh an entire product area. See Settings UI.

How we work

Each UX Paper Cuts designer is responsible for all the design and development updates needed to fix the paper cut, acting as a manager of one.
The team finds or receives paper cuts from around the product and maintains their own roadmap without a PM or engineers.
The team collaborates with Groups responsible for their areas of the product, acting as an informed partner.
The UX Paper Cuts team does not have the final say on work done by a Group and does not override decisions by a Group.

How we plan

DRI: Manager of Product Design

The UX Paper Cuts team updates our plan quarterly and follows a yearly roadmap.
The team works in monthly milestones, each with a specific theme.
The aim of using themes in milestones is to focus the work in one area (vs spreading paper cuts across the whole product), increasing the chances it will have an noticeable impact for our users.
Examples of themes include:
- Areas of high traffic.
- Areas that don't currently have design resources.
- Areas that are out-of-date or are inconsistent in their use of our design guidelines or design system.
- Areas that are deprioritized by a PM or where we are invited in to help by a PM.
- Areas with recent feature releases.
The goal is to always be planning 3 milestone in advance (in quarterly planning issues e.g. like this one).
We will solicit theme ideas from counterparts and keep a list of milestones and potential milestones.
We will review the backlog of issues, feedback, research, and bug reports to map them to the upcoming themed issues.

How we communicate

DRI: Manager of Product Design

Our default is to communicate the milestones to the product team in the #product Slack channel, and ensure Groups affected by any particular theme or issue are aware of the upcoming milestones.
We try to ping the relevant Group again a week before the planned milestone starts.
We will also ping the stage group PM and designers (if there are any) on the larger paper cuts work before the work starts, and ask for input to give Groups more awareness of upcoming work.
- Note: the UX Paper Cuts team is designed to move quickly and not get locked into the red tape and thus doesn't need explicit approvals before work.
- We do however have to have high confidence in our solutions.
- We have to ensure we're not introducing something that goes in the opposite direction the PM has set.
- And if UX Paper Cuts is working on something with lower confidence (or no data) then we do have to validate first (via PM, UX research, feature flags, etc.) before creating MRs.

How we collaborate

DRI: UX Paper Cuts designers

All UX Paper Cuts team members work from the same milestone planning document and are responsible for adding and describing upcoming issues or tasks, so we can communicate and collaborate with affected Groups in advance.
Since we work in other Group's areas, we make an extra effort in our MR descriptions. We explain the what and the why behind the proposed changes.
Each team member will make sure designer and engineer in affected Group is either set as a merge request reviewer or pinged in a thread for awareness (each Group can decide their preference).
The UX Paper Cuts team will pre-plan most of the work for each milestone and spend the majority of the milestone working on work related to the theme.
On larger changes, the UX Paper Cuts team will meaningfully communicate and collaborate with affected Groups, ensuring they are aware of upcoming work and are given the opportunity to participate in solutions.
The UX Paper Cuts team will monitor feedback after MRs are merged and continue to update and support that work.
The UX Paper Cuts team will follow our standard development practices including updating front-end tests.

Where we look for UX paper cuts (and how to send them to us)

Paper Cuts Possibilities issue
Issue labels
UX Research: SUS verbatim, CSAT verbatim and Usability Benchmarks reports
- Examples include:
Posts in #is-this-known Slack channel
Posts in #g_ux_paper_cuts Slack channel
Twitter / X
Customer feedback

You can find changes made by UX Paper Cuts by following along in the GitLab UI Polish Gallery, the internal Slack channel #ux_paper_cuts_mrs, or by searching the GitLab label UX Paper Cuts.