Baseline experience and expectations on To-Dos

What’s this issue all about?

Understanding how users utilize To-Dos and how they do and do not meet their expectations.

Discussion guide

Core questions

  • What exactly do users think to-dos are? Is this the To-Do feature we have currently given them, or is it something else? Do we need to split this feature out in some way?
  • How aren't we meeting expectations around to-dos, and what is most important to users (so that we may prioritize what to solution for first)?
  • What "types" of to-dos are there and how might we perhaps split these out?
  • What other objects would users expect to add as to-dos, and from where?
  • How would users expect to customize and prioritize to-dos?
  • How do we help to-dos feel actionable and support a user in focusing and getting these done within the to-do dashboard?
  • How might we better differentiate to-dos and notifications, what are the use cases behind each?
#### Additional questions * Are to-dos more of a list to get done quickly, or a running list of things a user needs to get done that can span a longer time frame, or both as different features? * What is the mental model and context of To-Dos in general and also within a product like this? * What IS a "TO-DO" to a user? (outside of GitLab) * How do users keep track of to-dos in their daily lives? Do they keep journals, cals, etc? * How do users keep track of to-dos at work? Are there notes all over their desks, etc? * How do users expect to be able to keep track of to-dos inside of a product like Gitlab? * How often are users checking to-dos? * When and why? * Is a state of "inbox zero" with to-dos important to users? If so, how often are they trying to get there? (ie: are users wanting to clear out their to-dos once a day, a week, etc) * What do users want to-do with to-dos that they currently can not? * Are users hacking our to-dos in any way to make them more useful for themselves? * Do they wish they could annotate, add notes, or add context to to-dos in some way? * What are the different types of to-dos a user expects? (I am trying to understand if perhaps we should break up these to-dos in some way, like watched issues, reminders, alerts, personal to-dos with comments, etc) * What types of to-dos are most important and actionable to users? * How are users actioning upon to-dos? How does this vary by type of to-do? * What is a user's expectation of a to-do once they have added one? * Do users expect the to-do be dynamic and update with more information as the thing they have marked as a to-do evolves? (IE: I think I would expect to get almost a timeline list under each of my to-dos with relevant mentions and changes) * Do users expect to be able to customize to-dos in some way? * Do users expect the to-do to alert them or remind them in some way? Of what? * Would they want to set due dates? * Similarly, do user's expect to be able to prioritize to-dos in some way? * How would they determine priority of these to-dos? How would they rank them? * Are they wanting to just pin a few to get to asap or is this more sophisticated? * Do users expect to be able to create their own to-dos? * When and why? * Where would they expect to be able to-do this? (ie: click some kind of "add to-do" from the to-do dashboard to remind oneself to "Write a research proposal for Katherine about To-Dos") * If so, how else would they expect to be able to customize this to-do? * Do users expect to-dos to be more of a kanban or is this a task list? * Do users need to know what is in their to-do "backlog" of to-dos, what they are currently working on, what is next, and what is done, or is this overcomplicating this feature? * Do users want a list (possibly prioritized) that they can be tactical about and hopefully get to a state of "inbox zero" in a short time frame or is this not sophisticated enough? * Are both of these useful in different ways and could one perhaps be a feature somewhere else? * Is the placement of to-dos in the sidebar what users expect? * Where else in the product would users expect to "Mark as To-Do" or add a to-do? * Could this even be as granular as a small chart or metric in cycle analytics for example? * Does the paradigm of "Mark as To-Do" and "Done" make sense to users? Does the name "To-do" even make sense? * We currently mark a to-do as done once a user has interacted with the item (IE I replied to a comment). Is that what users expect? * We sort of treat alerts or mentions as to-dos. Does this make sense? * What kind of alerts would expect? * Where would users expect to be able to view these? * Similarly, how would they expect to be alerts? * When another users mentions someone, they are basically setting a to-do for someone else, does that make sense? * What is the difference between a to-do and a notification in the users mind? * How often are users using either? Why?

What hypotheses and/or assumptions do you have?

I am assuming from conversations I have had that the way users think about "To-dos" and the way they function in GitLab are pretty different. I am envisioning a system of allowing a user to keep track of their work in many ways:

  1. Priority 1(to a user)-being alerted quickly to what they most care about (could use rules to set up what is important),
  2. Priority 2-having a list of custom and prioritized to-dos or mentions they need to action upon asap as there may be dependencies.
  3. Priority 3-having a personal board of work that helps them plan their work for the sprint or milestone that is not tied to workflow labels and perhaps keeps teammates aware of what they are working on (passive transparency).
  4. Priority 4- allowing them to watch specific elements of issue, MRs, metrics in some kind of dashboard, etc. I'd love to understand how notifications fits into this as well.

What decisions will you make based on the research findings?

Improving and enriching the "To-dos" feature and its usability, or perhaps rethinking the usage entirely.

What's the latest milestone that the research will still be useful to you?

This isn't currently prioritized, but there a many issues around this asking for improvement. I think we would love this as soon as possible as a baseline of expectation and as guidance when prioritizing the issues for improvement.

Methodology

Research will be conducted in two phases.

  1. Affinity mapping: Consolidate the feedback we've received and the research we've conducted on Todos and notifications so far. Conduct interviews GitLab users.
  2. Prioritization Matrix: Identify the top areas for improvement based on phase 1. If needed, investigate the top needs and pain points through additional UX research.

Links

Feedback from general interview sessions conducted previously: https://gitlab.com/gitlab-org/uxr_insights/issues/61 https://gitlab.com/gitlab-org/uxr_insights/issues/62 https://gitlab.com/gitlab-org/uxr_insights/issues/63 https://gitlab.com/gitlab-org/uxr_insights/issues/65 https://gitlab.com/gitlab-org/uxr_insights/issues/64

Progress

  • Katherine: Create screener survey [Deadline: Fri Feb 7th]
    • Katherine, Emily: Send screener to GitLab First Look. [Deadline: Mon Feb 10th]
  • Katherine, Emily: Schedule participants [Target Deadline: Mon Feb 10th]
  • Gabe: Draft discussion guide [Deadline: Thurs Feb 13th]
    • Katherine: Finalize discussion guide [Deadline: Fri Feb 14th]
  • Katherine, Holly, Gabe: Conduct user interviews[Target Deadline: Fri Feb 21st]
    • User 1 - Friday, February 14, 2020 - 9am PT
    • User 2 - Friday, February 14, 2020 - 11am PT
    • User 3 - Monday, February 17, 2020 - 1:30pm PT
  • Katherine: Open an Incentive request issue using the template in the UX Research project [Deadline: Tues Feb 18th]
  • Katherine, Gabe, Holly: Analyze notes and synthesize findings [Deadline: Mon Feb 24th]
  • Katherine: Document insights as issues in the Insights Repository [Deadline: Tues Feb 25th]

cc @katokpara @gweaver

Links

Edited by Danika Teverovsky