[UX] Group/project parity for planning objects workflows
Background
To allow teams to better organize work across their GitLab ecosystem, we plan to allow users to create planning objects in both groups and projects (decision context). Practically this means issues can exist in groups, and epics can exist in projects. Teams who were creating "team issue" projects just to hold issues for a group can choose to instead hold those issues in the group itself, and groups with just one project can now utilize epics within the project, avoiding navigating between namespaces.
User goals
Primary goals for this work
Parker needs to create new records for work to be done, including items that don't relate to a single repository or code at all, in order to easily track the work and collaborate with the team.
- Pain point: Today this requires additional projects; “We don’t want to create duplicates…we created a project just to track anything that belongs to multiple projects." (UX Benchmark Study)
Parker needs to manage work in GitLab in a way that mirrors how their team thinks of the work so that everyone can find and understand the plan.
- Pain point: Projects are tied to repos and may only represent code structures, while Groups are closer to representing team/org structures; for non-development tasks many users operate out of the Group level but have to navigate down to projects to manage Issues. (Related UX Benchmark insight)
In addition, other user goals remain true and will continue to need to be supported
Parker, a product manager, needs to view work to be done across the groups they work on in order to understand the backlog and status of work in progress.
Parker needs to prioritize and update details of the complete body of work they're responsible for in order to ensure the team has visibility into what's happening and is aligned on the plan.
Sasha, a software developer, needs to view work to be done in a single project they're responsible for in order to understand work in progress and what to work on next.
Parker and Sasha both need to be able to move planning objects to reflect changes in either the work, the team, or their GitLab organizational scheme in order to accurately reflect the work status.
- Pain point: Epics and Tasks cannot currently be moved, and Issues across projects cannot be bulk moved at once (i.e. no bulk move from group level). (Related UX Benchmark insight)
Known constraints
Group inheritance (additional detail)
A consideration will be users needing access to a higher-level group to manage issues in that group, which as a result of inheritance will necessarily mean that that user also must have access to all lower-level groups and projects. Users could request access to a group for the reason of editing issues and be inadvertently granted access to content they are prohibited from accessing. This is not blocking but is helpful to be aware of.
More detail
- This is not different from epics, which already operate this way. The main difference will be user perception of epics as a higher-level object managed by one set of users, vs. issues as a lower-level object managed by a broader set of users.
- Not all issue touchpoints require membership — users will be able to view and comment on group-level issues without belonging to the group, as can be seen today with epics. This risk only arises when a non-member needs to be able to create or edit a group level item.
- Project-level epics do not have access risks as this is the lowest level of access.
- With RBAC and custom roles, it may be possible to consider adding controls for inheritance at the role level, allowing users to create a role that can manage issues only on groups and projects they’re a direct member of. It’s not clear if this sort of limiting feature is currently planned for RBAC, RBAC team could provide more clarity.
- Other solutions to restrict inheritance have been explored; these could all allow users to manage group-level issues without having access to everything below that group.
- If inadvertent access is a problem users encounter, increasing awareness of scope at the point of group invitation (e.g. user will gain access to 100 projects, including 20 private projects) could help illuminate the impact of group membership and minimize the risk of a user thinking they’re just giving issue access.
- These are complimentary considerations which could be useful beyond group issues; these do not block this issue.
Design needs
To support this change, we need to ensure users can effectively create, manage, find, and understand issues and epics, in particular with respect to its "location" — the group or project where the object exists. This includes consideration of:
- Settings: How can users control which objects are available for a group or project to ensure users can't create objects where they don't belong (per their team's organization scheme)?
- Today: Project-level setting to enable issues (default ON)
- Future: Project-level settings for issues, epics; group-level settings for issues, epics
- Cascade as non-default option; users should be able to configure so that users cannot create group-level issues, but can create issues in projects within that group (recreate the current state).
- Lists and boards: How do users find objects in this location? How can users differentiate objects in this location vs. a subordinate location (e.g. group issues vs issues in that group's projects)
- Today: Group issue list and boards, group epic list and boards, project issue list and boards
- Epic lists, epic boards, and roadmap (at Group level) include a Group filter today
- Future: Group issue list and boards, group epic list and boards, project issue list and boards, project epic list and board
-
Introduce location filters to group lists, boards, and roadmap
-
Explore whether the path field can be iterated to more effectively convey where items live (related issue)
-
Combining issues and epics can be considered once saved views; consolidated concepts rely on saved view tools to manage types effectively.
Filters
-
- Today: Group issue list and boards, group epic list and boards, project issue list and boards
- Selecting location: How can users define where a planning object will exist during creation? How can users move items to new locations?
- Select location when Creating
- Today: select project from searchable dropdown (issues from group list or board); select group from searchable dropdown (epics from epic)
- Future: select location when creating from group list/board or global create (design)
- Moving an item
- Today: issues only, searchable projects dropdown; no ability to move epics
- Future: select destination location from any object
- Bulk move
- Today: same experience as moving single item, only available for issues in project issue list
- Future: select destination location from group or project list bulk edit
- Select location when Creating
- Understanding location: How can users understand where an object lives when viewing that item?
- Today: breadcrumb displays full path
- Future: breadcrumbs; current designs do not include breadcrumb when in interstitial view (e.g. drawer), evaluate if the location in the originating link (e.g. board card, list item) is sufficient to provide location information when open in an interstitial view
- Interacting with attributes: What's available from a group-level item, and how can we handle things where no group-level values exist?
- Today: group-level items (epics) use group-level attributes (e.g. milestones, iterations, and assignees pull from group-level). Project-level items use values from that project and all higher-level groups.
- Future: no change expected in logic, but will need to specifically account for creating merge requests from group-level issues — this currently uses the current project, but will need to get user input on which project to use.
Deliverables
View in Figma (internal only), or design manager
- Issue/epic settings designs
- List and board filter designs
- List and board path designs (only if changing)
- Move designs
- Detail page path designs (only if changing)
https://gitlab.com/gitlab-org/ux-research/-/issues/2742)
Solution validation (Solution validation should answer whether users can effectively and easily utilize group issues and project epics.
Key questions to address in solution validation:
- Can users find planning objects at different levels of hierarchy?
- Can users easily understand where an object exists?
- Can users create and/or move items across locations?
- Can users understand who will have access to an object (based on its location)?
- Will group issues, and/or project epics, be usable for the user's team given their organizational structure?
Secondary question to look for:
- How do users think about organization across groups and projects? Why do they organize things the way they do today?
Research process
Moderated RITE study (3+2+n) to be conducted early in the design process allowing for rapid design advancement, and again at the end of the design process to validate workflows and interactions.