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.
| Stage | Foundations |
| Maturity | Minimal |
| Last reviewed | 2024-10-03 |
Thanks for visiting this direction page on the Notifications category in GitLab. This page belongs to the Personal productivity group within the Foundations Stage and is maintained by Jeff Tucker.
This direction page is a work in progress, and everyone can contribute:
People using GitLab can guide work throughout the entire DevSecOps lifecycle — from planning, to development, verification, and ultimately delivery. Having all of these capabilities within a single tool is powerful and efficient, yet requires users to stay up-to-date on changes and discussion happening across many parts of the product.
GitLab to-dos are the product experience intended to address this need. However they were designed to adhere to the GTD model: the only "notifications" we surfaced within GitLab were actionable tasks for the user. Our research has found that deciding what's actionable is a very personal, subjective question that varies by person — what some users find actionable, others find as noise, and vice versa. Instead, users want more visibility into their notifications so they can decide which they need to act on.
In contrast, email notifications provide an exhaustive set of notifications for nearly every event that happens in GitLab. Some GitLab users have abandoned to-dos entirely in favor of email notifications, as this gives a more thorough way to stay up-to-date. While this gives them more visibility into events occuring in their projects, they must spend significant time each day processing their email inbox to avoid missing an update. Additionally, they are required to jump between email and GitLab as they triage and take action on notifications.
We want users to stay up-to-date within GitLab more efficiently than they could via any other tool. We will do this by:
This work will deliver value to GitLab and our users in three time horizons:
The way each person uses the current email notification system and To-Do List features are highly personal. Our goal is to create a notification system that people can trust, and that's flexible enough to accomodate these many different ways of working.
The current To-Do List is used primarily by internal GitLab team members, but not by external customers. There are also issues with retention on the current To-Do List. With these improvement efforts, our focus is to increase customer usage and retention, and we are prioritizing efforts that will aid that longer-term goal. However, we will do our best to minimize the impact on internal users as we make these improvements, so as not to disrupt existing workflows.
To begin, we will focus on the Delaney (Development Team Lead) and Parker (Product Manager) personas, as these are the two personas whose workflows will be most impacted by these changes. See Target Audience to learn how we will expand to support other personas.
Our key initiatives will include:
Mature the To-Do List experience
We will iterate on the existing To-Do List during this phase, with each iteration available to all users. We intend to add features that have been highly-requested, and do not anticipate any need for breaking changes or deprecations. This includes features like:
We will introduce few (if any) new to-do types during this phase to ensure we avoid overwhelming end users with a noisy inbox.
The end goal of this work is to improve weekly user retention for the existing To-Do List by providing the functionality users need to manage notifications effectively.
Rename "to-dos" to "notifications"
Next, we will transition to using the word "notification" in the product instead of "to-do". We are doing this for two reasons:
This will involve cross-stage changes, like updating the sidebar on issues and merge requests. Given the potential disruption these changes could cause to users, we will bundle these changes into a single public release. Once this goes live, we will market the change as "introducing web notifications".
The goal of this work is to increase weekly active users (WAU) of the To-Do List by making it more discoverable to end users.
Provide fine-grained control for web notifications
Introducing more notifications into GitLab risks creating a new problem: making noise that distracts users from focusing on creating software. The types of notifications that users care about vary from person to person, so we need to provide tooling that allows users to tailor their notifications to exactly what they need to remain productive. Once this stage is complete, we will be able to introduce new notifications into the product while ensuring the notification list remains focused and action-oriented for our users.
Team leads want to be notified of all comments in a discussion so they can take action even when they're not explicitly mentioned. Currently, GitLab only creates todos to review a comment when you are directly mentioned. This drives team leads rely on email notifications, which leaves them bouncing back and forth between GitLab and their email inbox.
GitLab users should be able to keep up with conversations within GitLab. We will introduce additional web notifications for replies to discussions you've participated in, and improve the behavior for automatically resolving notifications to work better with discussion threads.
Integrate broadcast messaging with the notification center
You'll now have more control over important updates within GitLab, as we're enhancing broadcast messaging for admins. This improvement allows GitLab to communicate crucial information directly in the UI without hard-coding banners, and extends the functionality to GitLab.com administrators, ensuring you stay informed about essential updates while we work on reducing banner clutter for a better user experience.
Internal framework for notifications
Currently, email notifications and to-dos are managed by completely separate systems. As we seek to gain parity between these channels, we need a way for teams to surface new notifications without having to do so in two places. This framework will enable teams to maintain the content and logic for their notifications without needing to deal with the underlying notification infrastructure.
We are working to track how these improvements impact people as we iteratively add them into GitLab. We will periodically conduct UX Scorecards to assess the experiences. We are also working to create a baseline metric for this experience that we can track over time.
Quickly review a large volume of notifications
Even with support for customizing notifications, people can still end up with a large inbox of notifications to review. We want to provide ways for users to quickly review a large volume of notifications. We are considering ideas like:
Problem validation
We have audited previous research, user comments, and internal explorations to understand the core challenges and opportunities in this space. We are now conducting light-weight user research to validate the key themes we uncovered before moving forward to address them.
Initial design discovery
We have designed an initial full notification workflow. We are continuing to refine this design, and to assess how we can iteratively introduce these proposed features into GitLab.
See our roadmap in GitLab.
Watch our latest kickoff video to see our plans for the current milestone.
Notifications are used by all users, so our long-term vision must accomodate a variety of needs. In order to make progress, we will focus on a subset of personas that have a pressing need to remain up-to-date with work happening in GitLab:
Once we have created an experience that they love, we will broaden our focus to other people that use GitLab daily. We see the following personas as being our key targets in this second phase:
While Notifications doesn't represent a competitive category, the core user experience of GitLab will impact how well GitLab performs in the market. We take inspiration from others in the field that are delivering exceptional notification experiences.
GitHub
GitHub introduced their current notifications experience in 2020. They received significant praise for this upon launch, and we continue to hear requests from customers to bring an equivalent experience to GitLab. There are a few key details that we've noted as being particularly impactful:
Linear
The founder and original designer of Linear had years of experience as a designer before starting Linear, so it's no surprise their product is beautifully and thoughtfully designed. The inbox view is a core part of the Linear workflow, so it is a mature feature packed with innovative details:
GitDock
Built by GitLab Team Member Marcel van Remmerden, GitDock is a MacOS/Windows/Linux app that displays all your GitLab activities in one place. Instead of the GitLab typical project- or group-centric approach, it collects all your information from a user-centric perspective.
GitLight
GitLight is an open-source tool for managing notifications from GitHub and GitLab in a single interface. Like GitDock, this tool is building on top of the concepts offered by GitLab to create new experiences. It has some advanced concepts that make it stand out:
Honorable mentions
Notification experiences are not unique to developer tools — they're a common feature in collaboration software. We're looking beyond tools in our space to see how other domains are solving this problem as well.