Feedback: UX Vision for Plan - How might teams collaborate to plan their work?
Background
With #407470 (closed) we explored designs that could be used to organize and navigate epics, issues, and tasks. We've refined those directions and are excited to get your feedback.
Managing planning objects includes JTBD like building, refining, and prioritizing a backlog, planning items across milestones and iterations, managing the capacity of your team, and tracking the workflow of items planned and/or in flight for a team.
We identified two prominent user problems to solve (additional details):
- Navigating across projects/groups, issues/epics, and lists/items is confusing
- Incomplete tools for representing organization’s work structure
Our ask: Before you commit to joining the discussion, note that the videos are just over 15 minutes each (check the chapters in the description if you want to skip around), so you'll need about 1-2 hours to watch the video, read the issue and contribute to the conversation. We thank you in advance for your time!
What do we mean by planning objects?
- Objects which are used to plan and track work to be done.
- Usually exist in a hierarchy and can have parent/child relationships — the current hierarchy is epic-issue-task and these are the GitLab objects we focused on.
- Other objects can be added to this vision in the future following a user-centered design process.
Planning objects includes both implementation-level items, which can be completed on their own, such as tasks and issues ("Backlog items" in Scrum), and higher level items like epics.
Re: Work Items
Planning objects will be built using the work items architectural framework. Other GitLab objects will also be built using this framework which might not be considered planning objects; as an example Objectives and Key Results. These are built as work items but would not be classified as planning objects as they would not be hierarchically "parents" of planning objects.
Design directions
These are not mutually exclusive.
We arrived at these design directions by exploring various ideas, then designing three in more detail, finally narrowing down to two. These directions were picked for being notably different from each other to enable users to manage their work with planning objects.
Abstracted Collection
In this model we would introduce a new object called a "Collection" which is owned by a Group or User. A Collection allows users to build a list of items including planning objects which they can then represent through different views. While access to a Collection is defined by the group location, the data in the collection is not limited by the group. Item data, such as labels or milestones, is tied to the item and is the same whether viewed from a group, project, or collection.
Collections could initially live side by side with our current list, board and roadmap pages. As it matures we'd figure out how to converge things, by removing pages or updating pages to ensure they work the same way (both for user experience reasons and code re-use).
Example
As an example the Plan team could create a Collection called "Plan work" that is owned by gitlab-org/plan-stage group, and contains all items from gitlab-org/plan-stage/project-management and gitlab-org/gitlab items with label 'devops::plan'. This Collection could include a backlog view of all items in a table with one set of filters, and a planning view of items assigned to milestones as a board with a different set of filters. This Collection can exist in plan-stage, making it available to all plan-stage members, and contain gitlab items even though plan-stage is not hierarchically above gitlab — those items won't appear in plan-stage "Issues" list, but will appear in the Collection.
Consolidated Backlog (w/ Saved views)
In this model we could combine all Planning Objects — Epics, Issues, and Tasks — from one group or project into a single page, tentatively called "Backlog". From this page users could select which types to view; rather than navigating to Issues or Epics, Issues and Epics become options within the page. Users can additionally scope down a group-level list to specific subgroups or projects, and save the combination of type, scope, and other filters as a reusable view which can be displayed as a list, board, or roadmap. The data in a Backlog is always limited by the group or project.
Example
As an example the Plan team could create a view called "Plan work" that is owned by gitlab-org group, and contains items from gitlab-org/plan-stage/project-management, gitlab-org/gitlab with label 'devops::plan'. This view could be displayed as a table or board, each using the same filters defined by the view. This view could not be created in gitlab-org/plan-stage and contain gitlab-org/gitlab items as plan-stage is not above gitlab in hierarchy.
Recommendations
We like the Collection approach...
...because it moves us toward a team-centric GitLab, and enables better collaboration and quicker access to what the user cares about. We believe the collection approach provides the best experience to teams, especially teams in larger orgs who have been telling us they are limited by our current group structure. It is a first step toward abstracting that away and allowing a team or individual to focus and collaborate on things that they care about the most.
It's extendable
The collection approach is also more flexible to other use cases, such as an MR board or a personal issue list. As Groups are used only for access, extending Collections to other contexts would only require changing what can be the owner of a collection (i.e. a Collection can be seamlessly moved between groups, and could be added to something like an Organization in the future with no change in overall approach).
We can iterate
As a practical consideration, since Collections exist outside of the current Issue and Epic lists, we can considerably improve the user experience of planning and tracking work through Collections without requiring significant, immediate changes to group/project lists.
Future-future vision
Lastly, there is the possibility that a Collection could someday encompass the entirety of GitLab features. A user could select the data that they are concerned with, and anywhere they could navigate in GitLab could reflect that data. So you could view your issues, incidents, vulnerabilities. dashboards, pipelines, MRs, and on and on without having to re-filter your data. This could unlock a lot of value to customers.
🙋 Feedback Requested
Please review both directions and tell us what you think. In particular, we're looking for feedback on:
- How well do these approaches align with your vision for plan and plan objects?
- What excites you about these approaches? What concerns you?
- Is there additional customer value we could deliver that we've missed?
- What problems wouldn't be addressed through the Collections approach?
- What challenges would exist in implementing Collections?
As these are wireframes focused on IA, we are not looking for feedback on specific UI decisions or components used, these will be refined through more UI-focused design.
Figma access (internal)
GitLab users can access linked Figma files by creating an account with their GitLab email address.