## Problems to Solve There is an overwhelming amount of research that has been conducted on GitLab's todos that spans both internal and external users. Some of this research dates back more than a year. There have been a few attempts to improve todos, but those issues/epics have been abandoned. Many users complain that todos require excessive pruning in order to be useful. They also complain that they have to rely too much on email or third-party software in order to receive all necessary notifications. Many users mention wanting a proper notification center. Todos carry an assumption that the information they hold is actionable, which isn't always true. To dos are not customizable. ## Background ### Research (synthesized?) - [x] https://gitlab.com/gitlab-org/ux-research/-/issues/25 - [x] https://gitlab.com/groups/gitlab-org/-/epics/3132 (mural) - Navigation usability feedback that involved todos: https://gitlab.com/groups/gitlab-org/-/epics/1208 - [x] Navigation of: https://gitlab.com/gitlab-org/uxr_insights/-/issues/38 - [x] Using Todos: https://gitlab.com/gitlab-org/uxr_insights/-/issues/37 - [x] Comprehension: https://gitlab.com/gitlab-org/uxr_insights/-/issues/36 - [x] Icon: https://gitlab.com/gitlab-org/uxr_insights/-/issues/35 ## Goals ### Project Goals - To synthesize all existing research and community feedback in order to determine an ideal feature set for to dos and notifications. - To create an executive summary of current feedback in order to gain buy-in and get resources and fix to dos. - To inspire further user research (problem validation and solution validation) based on gaps in existing research. - To create an MVC that makes sense and has buy in both internally and externally ### Feature Goals - To determine how to adapt to dos to enable users to understand and organize what they need to work on. - To break dependency on email or third-party software in order to receive all vital information users need. - To allow users more control over what kinds of information they receive via email vs on the site. - To create a better paradigm about what is considered actionable and what isn't (i.e. automation). - To reduce the amount of pruning needed in order for to dos to be meaningful and helpful. ## What do we know? #### Interview: Notifications (Todos, Realtime Alerts, Emails) - General Usage - [x] https://gitlab.com/gitlab-org/ux-research/-/issues/312 (research issue from https://gitlab.com/gitlab-org/ux-research/-/issues/838) - [x] [Participant 1](https://gitlab.com/gitlab-org/uxr_insights/-/issues/61) - [x] [Participant 2](https://gitlab.com/gitlab-org/uxr_insights/-/issues/62) - [x] [Participant 3](https://gitlab.com/gitlab-org/uxr_insights/-/issues/63) - [x] [Participant 4](https://gitlab.com/gitlab-org/uxr_insights/-/issues/65) - [x] [Participant 5](https://gitlab.com/gitlab-org/uxr_insights/-/issues/64) ### Research Summary - Dovetail project: https://dovetailapp.com/projects/37959b8b-f5ff-43ad-9903-e8ea2e244cd6/data/b/0b972f8a-d919-4842-baf2-e3d3e5b487e7 ## Issues & Epics All epics and issues are linked to this sub-epic: https://gitlab.com/groups/gitlab-org/-/epics/5693 Approx 109 issues related to notifications or todos. An analysis of individual issues revealed 600+ thumbs up :thumbsup: The largest numbers of thumbs up were [227](https://gitlab.com/gitlab-org/gitlab/-/issues/17232), [258](https://gitlab.com/gitlab-org/gitlab/-/issues/14972), and [117](https://gitlab.com/gitlab-org/gitlab/-/issues/14889) ## Internal discussions - https://gitlab.slack.com/archives/CLW71KM96/p1655916329388259 - https://gitlab.slack.com/archives/C0NFPSFA8/p1654622842037829 ## Pillars of an ideal solution ### High confidence - Notifications should have parity with email. - Notifications should appear live, without the need for a page refresh. - Users should have control over whether they receive notifications, emails, both, or neither. ### Moderate confidence - Todos should be manually created from an issue/MR/epic/design or from a notification. - Automatic todo creation should be avoided unless research-based and under user-control/opt-in. - Notifications should not be cleared automatically as it's not clear to everyone why this happens. - Unless users have fine-grained control over what gets closed automatically and how. - Also unless it's visually and cognitively intuitive why they are cleared (assigned issue was closed, MR merged, etc.) - [Directly addressed vs mention distinction should be removed](https://gitlab.com/gitlab-org/gitlab/-/issues/119232). ## Proposed MVC https://gitlab.com/gitlab-org/gitlab/-/issues/325210/ ## Is this a cross-stage feature? Yes, this would be a global change for GitLab ### Help Needed - Gather any remaining research that isn't captured here. - Document how notifications, todos, and alerts currently work - Comment on proposed designs - Comment on research executive summary - Comment on the proposed process (next steps at top of epic) - Suggest competitors for competitive analysis - Anything you want to help with is fine! ## Next Steps - [x] Synthesize existing research - [x] Create research executive summary - [ ] Competitive analysis - [ ] Create research initiatives to fill in gaps - [ ] Design ideal system - [ ] Solution validation - [ ] Propose MVC - [ ] Resource project