[RESEARCH STAGE] WIP Limits MVC

From: ux-research#215 (closed)

Options

1. ONE

2. TWO (WINNER)

3. THREE

Summary of findings

4/7 users chose option 2 as best overall, 3/7 chose option 1. Option 1 and Option 2 were both favorable in terms of concept and design, however. They just may have different use cases, depending on how rigid the team's planning processes are and how they perceive the functionalities.

• For example, User 1 stated that option 1 provides capabilities to organize what he sees while option 2 is an aid for a management process (there would need to be an established reason for why he should set limits).
• User 4 stated that Option 2 was for hard limits while Option 1 was for informational processes.

Overall, users were receptive to both option 1 and 2, even if they didn't fully understand all aspects of the designs on the first impression. Some users do not need to set specific limits (option 2/3) but still understood the concept well. Other users may not have stretch goals in their own workflow but see use cases for using the line to group issues on the board or prioritize issues in the backlog (option 1).

Considerations for each design proposal

• In Option 1, the weight icon was unclear to most users so understanding the link between capacity and weight was more difficult. Still, most users thought option 1 was describing an organization/grouping workflow and did expect the numbers to increase as more issues were added above the line.
  • The majority of these users were using GitLab.com Free or Core (2 users were using GitLab.com Gold as well) so this was likely their first impression of the weight icon. Since this feature would be in Starter, perhaps it will be adopted by people who are already using issue weights and as a result, there could be less confusion about the icons.
• Option 3 received some negative reactions to the bold colors. Also, 2 users pointed out that the yellow color did not align with the color of the word “Min” in the column header so some people may miss the connection there. User 4 thinks it’s fine to use the yellow color, since it’s more of a warning than an error, but it may be best to make the word “Min” yellow too.
  • User 4 preferred Option 3 over Option 2. He liked that the "error" doesn't give you any context for what is over the max and you’d have to make your own decision about what to move out.
  • User 1 would like something in between - a contour around the whole column (to make it easier to see the error) but not as harsh as the colors in Option 3.
• Option 2 was generally regarded as communicating the limit more precisely and clearly than Option 3. Additionally, since it highlights the exact issues over the max vs highlighting the whole list, some users thought it would save on guesswork. For example, User 5 stated that, if the max was "12" and the whole list was red, users would need to do more work to count how many issues were over the max.

  • User 3 and User 6 had slightly different interpretations of the concept of option 2, even though they preferred the design.

    • While User 3 selected option 2 overall, he actually understood the concept of option 1 better:

    (regarding option 1) This appears to be another way of grouping issues that you want to concentrate on and those you want to leave out. The issues above the line should be worked on, the issues below the line are in the backlog.

    • In contrast, he interpreted Option 2 as limiting the number of issues that can be open at any given time. As a result, he thought the red error was linked to due dates and that the issues in red had exceeded their due date.
    • User 6 thought that the red error was from GitLab, communicating that a user has gone over an allotted limit in their pricing plan. She did not connect option 2 to capacity planning.

Conclusion

The choice between option 1 and option 2 comes down to differences in planning needs, which varied with these users and likely varies even more across all GitLab users.

I think it's reasonable to implement the capacity line as an MVC for grouping and prioritizing issues. It will be important to consider the way that information is being communicated to users and provide tooltips/other cues in the UI to help users understand what they can do with the line.

We could also explore Option 2 as a more precise method for adding constraints in the planning process. For example, User 5, a professor, suggested that the limits could be used as a way to help him encourage his students to focus on a set number of projects and set realistic expectations. He saw option 1 as more one-dimensional for his needs since he works with different groups who may have different priorities.

Perhaps it makes sense to determine which approach is feasible for 12.2 and follow-up with additional research after implementation or further product discovery?