[In Progress] Todos Research Executive Summary

Current State of Todo Usability

[2019Q2] UX Scorecard - Receiving and Configuring Issue notifications and To Dos gitlab-design#450 (closed) (visit issue for Mural, video walkthrough, etc.)

Benchmark Score: Grade: D+ (Presentable verging on average)

Research Summary

Total Participants: unknown.

Much of this data came from comments on dozens of issues, as well as interviews with three subjects: Systems Administrator, Software Engineer, UX/UI Designer. When you see (n=X) below, the n represents the number of comments tagged, not the number of users. The n is not mutually exclusive and its possible the same user is counted multiple times for different comments.

Screen_Shot_2021-03-08_at_12.26.01_PM

Problems (top 3)

  • Conceptualizing (n=17) - Conceptualizing is defined as the ability to understand what the todo list is, why it exists and how it works. Anytime a user mentioned not understanding why a todo was closed, why it appeared, or what todos meant, I marked it as "Conceptualizing".

  • Managing (n=12) - Managing is defined as the ability to prune the todo list for different purposes. This would include closing out todos, maintaining order, managing todo lists with large numbers of todos, tidying up projects, and the ability to control todos etc.

  • Missing out (n=10) - Missing out is defined as not receiving important notifications, whether due to conceptualization problems, or due to todos not existing whereas an email notification does. Could also be due to noise or problems managing out of control todo lists.

Solutions (top 3)

  • Notifications vs todos (n=18) - This is defined as the distinction between the types of activities that constitute a todo vs a typical notification. Many users mentioned wanting notifications in the web UI in addition to todos.
  • No Email (n=9) - Anytime someone mentioned not wanting to have to rely on email, this tag was used.
  • Manual vs automatic completion (n=7) - When a participant mentioned how todos could improve with some change to automatic vs manual todo completion.

Use Cases (top 3)

These are the top 3 mentioned use cases participants mentioned in respect to their use of the Todo feature. These mentions do not imply whether the feature works well or not for these use cases:

  • Bookmarking (n=5) - Saving something to come back it later.
  • Tracking work (n=4) - Deciding what to work on, keeping track of tasks.
  • Reminders (n=3) - Using todos as a reminder to complete a task at a later time.
  • Organizing work (n=3) - Knowing what to work on first/what's most important.

Why this is important

GitLab OKRs

Notable Quotes

“The main problem is that most of these TODOs aren't actionable at all, like simple mentions. So making a TODO for someone is something completely different than mentioning someone. That distinction currently can't be made (except for assigning someone an issue/MR).”

“I don't get notified by the GitLab UI for the following events: 1) an MR is created for which I am a reviewer (but not an assignee)2) someone comments in an issue/MR that I am subscribed to3) someone pushes code to an MR that I am subscribed toThese are among the most important events I want to be notified of.I can enable email notifications for some of these, but I am not interested in enabling emails from GitLab. Having no other way to know when these things happen is unfortunate UX.”

“It's unclear how to keep TODO list in order, as nothing is cleared automatically upon issues or MR being closed.”

"It's also indicative of the "GitLab knows best" philosophy that pervades design here, which means that many people end up having to spend a lot of time fighting the tool if they deviate at all from how GitLab devs like to do stuff."

"For me a notification center would help me so much in working in the Core team. Since there are so much emails, I can't handle them all with my dayjob as well. I like the GH Notification center for that reason."

"...I want NO EMAILS (I'm not saying to get rid of them). I would much rather have a notification center with the same stuff that would come in email (Like Github's notification center)... I've used email more since switching to GitLab (about a month ago) than I probably have (for work) in the entire 3 years I've been working at my company."

"I don't want notifications by emails. So when I start an issue or enter a discussion in an issue, I see that I "subscribe" to the thread, but I don't get any notifications and I miss important comments (for example it took me two days to realise the gitlab team was asking me for details about a bug I reported)."

"I am begging y'all to please add a "notifications" page like Github, where I can see new MRs in projects I follow, new comments in MRs I follow, new commits in MRs I follow, etc. The "Assigned" and "To-do" pages are good but they don't cover everything and it's really tough to play catch up."

Edited by 🤖 GitLab Bot 🤖