Boards design sprint/idea session
Problem to solve
- Establishing a "Board" primitive. There is emerging evidence of different kinds of objects in GitLab that all would like to be interacted/managed via a "board". (MR Boards, Epic/Program Boards)
- Surface the most relevant information on a Board for a given context. We're adding more and more features to Issues/MRs/Epics, but surfacing all the related meta-data within the constrained space of a Board Card is difficult. The more we add, the less meaningful the cards become for any given use case.
- Configuring Boards and navigating across Boards of different object types. We could expand the sidebar nav to include Epic Boards and Merge Request Boards and treat Board Object Type as completely separate things, but is this the best solution? Issues, Epics, MRs all share the same list interaction model. Should they be entirely separate nav items just because they are different object types? Is there a way to provide a more efficient experience for users to configure "value streams" that encompass quick links to all of these different objects that share some common underlying configuration settings like "saved filters", "group by", etc.
- Enabling Boards to be a shared, SSOT for a cross-functional development team. Right now, boards lack the necessary configuration to allow all different personas to share a single Board comfortably. This results in problems like the Dev boards getting out of sync with the PM boards and the same lists having different WIP limits across Boards. Different personas want to see things differently. Individuals want to see things that maybe the entire team doesn't and vice versa.
- Reduce duplication of implementation effort and ongoing maintenance costs. We have a limited team size and lots of JTBD/Use Cases that we need to solve for over the next 12 months. The more "custom" interaction models, UI elements, etc. we build -- the slower we end up going because everything we build has an ongoing maintenance cost. How can we solve the use cases of Epic, Issue, and MR boards with as much shared "implementation details" as possible.
Intended users
- Parker (Product Manager)
- Delaney (Development Team Lead)
- Presley (Product Designer)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
User experience goal
Proposal
Further details
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
Edited by Gabe Weaver