> [!note] 🧭 Vision > A single entry point where users can view and interact with their work using the visualization that best fits their workflow — list, board, roadmap — with consistent filters, flexible grouping/sorting, and the ability to create personal or team views without recreating the wheel. --- ## 📌 Summary We are revamping GitLab’s Boards experience to deliver a modern, scalable, and unified planning surface. Today, our legacy boards architecture limits our ability to meet the performance, flexibility, and usability expectations set by competitive planning tools. This epic outlines *what success looks like* from a user outcome perspective. It does not prescribe how engineering achieves those outcomes, but rather defines the problem space, user needs, and must-have capabilities. Related business case from the field: https://docs.google.com/document/d/1JSsc6_AxkAARmVmSSpXAzzFKA5k_goxv/edit (internal only) --- ### ❗ The Problem Today’s GitLab Boards are: - **Fragmented** – Epic vs. Issue boards are separate and confusing to navigate - **Inflexible** – Limited filtering, grouping, and saved view options - **Hard to use at scale** – Poor performance and lack of bulk interactions - **Non-extensible** – Difficult to evolve into a unified planning surface for all work item types; switching between views (e.g. list ↔ board) often requires reapplying filters and manually rebuilding context - **Not built for non-devs** – Many users find the experience rigid, unfamiliar, and unintuitive compared to tools like Jira, ClickUp, or Linear As a result, prospects hesitate to switch from mature tools, and existing customers frequently seek alternative solutions, including one [enterprise customer](https://gitlab.com/gitlab-org/product-feedback/-/issues/204#note_2617949824) who built an internal planning tool used by 4,000 of their users to compensate for limitations in GitLab’s boards experience. >>> [!caution] When asked if they planned to retire their custom tool as GitLab closes feature gaps, they shared: **_“Not necessarily. This is a transition point for non-IT and business users coming from Jira. We need an interface that eases behavioral change and makes onboarding efficient.”_** >>> This highlights a critical insight - **closing feature gaps isn’t enough**, we must also deliver a user experience that is intuitive, contextual, and approachable for non-technical users. --- ### 🎯 Key User Needs We Must Solve | Persona | Need | |--------|------| | **PMs/TPMs** | Plan both long and short term goals, understand cross-team dependencies, prioritize effectively, and share planning views with stakeholders | | **Eng Managers** | Run standups, see blocked items, and manage team capacity easily | | **Developers** | See only assigned work and relevant metadata without clutter | | **Program Managers** | Coordinate across projects, roll up progress, and track milestones | | **New Users** | Land in a usable, contextual default board without manual setup | --- ### 📋 Goals and Outcomes We aim to deliver: - **One unified entry point** to access work items in list, board, or roadmap format - **Switchable view types** with consistent filters, grouping, sorting, and saved views - **Two-dimensional grouping** (vertical + horizontal) by any attribute (core or custom) - **Bulk actions and drag-and-drop** across views - **Customizable card metadata** for at-a-glance context - **Full support for Work Items** (including epics, issues, tasks, and nested hierarchies) - **Real-time updates and fast performance** at scale (1000+ items) - **Support for workflows like PI Planning, Now/Next/Later, or team-based tracking** - **Personal and team views** with saved configurations to reduce ramp-up time --- ### 🧱 Architectural Requirements As a PM, I’ve experienced repeated friction when requesting new filters or grouping options. I’m often told the investment is high, especially for horizontal groupings. The system isn’t extensible, every change requires bespoke work. That’s not sustainable. We must evolve toward an **attribute-agnostic, schema-aware visualization framework** to support: - **Vertical and horizontal groupings** with two-dimensional layouts - **Decoupled UI logic from static field mappings** to support dynamic custom fields - **Pluggable filtering, grouping, and sorting** — new work item attributes (including custom widgets) should be available for filtering, vertical and horizontal grouping, and sorting with minimal engineering lift - **Future-proofing for AI-powered insights and custom widgets** — architecture should accommodate AI-assisted views and personalized recommendations - **Maintained performance** even when many fields and complex filters are applied - **Shared schema awareness** — consistent treatment of metadata across all visualization types (List, Board, Roadmap) This isn’t just a UX improvement, it’s a foundational enabler for GitLab’s ability to iterate faster and support customer-specific configurations. Without this, every new field we add will continue to require bespoke logic to expose it in boards, creating drag on delivery and frustration for both PMs and users. <details><summary>Implementation Considerations</summary> ### 🔧 Implementation Considerations This epic **does not prescribe** how engineering should implement the solution. It defines the outcomes we need. Engineering should evaluate: 1. Refactoring the current boards experience 2. Building a new boards experience from scratch 3. A hybrid approach that balances reuse and scalability Evaluation should consider: - Technical feasibility - Total implementation time and engineering cost - Long-term maintainability - Migration path for existing boards - Ability to meet the architectural and usability needs outlined above </details> --- ### 📈 User Value and Business Impact By addressing these pain points, we expect to: - ✅ **Increase adoption** by aligning with modern planning UX expectations - ✅ **Reduce friction and context switching** during daily workflows - ✅ **Support team alignment** with better visibility into work and relationships - ✅ **Drive usage of GitLab as a complete planning platform**, reducing third-party reliance - ✅ **Win new business** by unblocking hesitant prospects looking for intuitive planning tools - ✅ **Enable faster iteration** by scaling with the Work Items platform, not fighting it --- ## 📚 Additional Resources <details><summary>Competitive Analysis</summary> ### 📊 Competitive Analysis Our [competitive research](https://gitlab.com/gitlab-org/gitlab/-/issues/550346) across 13 planning tools reveals consistent patterns and evolving expectations for boards functionality. | Feature/Capability | % of Tools | Examples | |--------------------|------------|----------| | **Real-time updates & drag-and-drop** | 100% | Jira, ClickUp, Trello | | **Actions reflected across views instantly** | 100% | Asana, Linear, Notion | | **Flexible grouping by any field (incl. custom)** | 75–83% | Linear, GitHub, Monday | | **Two-dimensional layouts (group + swimlane)** | 75% | Azure DevOps, Jira | | **Mixed view modes (list, board, table, timeline)** | 92% | Notion, ProductBoard, Aha! | | **Customizable metadata display on cards** | 83% | ClickUp, Asana, Linear | | **Bulk actions directly on board** | 75% | Linear, ClickUp | | **Saved/personal views** | 50–75% | GitHub, Jira, Notion | | **Support for epics/issues/tasks in one board** | 33% (emerging trend) | GitHub, Linear | | **Progress rollups by item/weight** | 75% | Azure, Jira, Monday | | **Ungrouped fallback behavior** | 83% | Most tools include this safety net | | **Auto-persistence of filters & sorting** | 50% | Jira, Linear | | **Inline relationship visibility (parent/child)** | 67% | Jira, ADO, ProductBoard | </details> <details><summary>User Stories and Requirements</summary> ### 📋 User Stories and Requirements ### Must-Have Capabilities | Capability | User Need | Details | |------------|-----------|---------| | **Unified Entry Point** | Access work items from one place | - Land on list view<br>- Switch views easily<br>- Persistent state | | **Persistent Views** | Maintain filters/grouping when switching views | - Avoid resetting filters<br>- Save/share views | | **Performance** | Boards remain usable at scale | - Fast loading<br>- No lag with 1000+ items | | **Relationship Visibility** | Understand context without opening every item | - Parent/child, blockers, dependencies shown inline | | **Customizable Metadata** | See what matters at a glance | - Status, priority, team, health, etc. | | **Switching Views** | Move between views without friction | - No reconfiguring or navigation burden | ### Should-Have Capabilities | Capability | User Need | Details | |------------|-----------|---------| | **Bulk Actions** | Edit multiple items at once | - Move, assign, label, update in bulk | | **Flexible Grouping** | Group by any field, vertical + horizontal | - Milestone, iteration, label, team, etc. | | **Progress Tracking** | View workstream health | - % complete by count or weight | | **Saved Views** | Return to or share configurations | - Personal and team-level saved setups | </details> <details><summary>Acceptance criteria</summary> ## Acceptance criteria | # | Acceptance criteria | Existing behavior | Why | |---|---------------------|-------------------|-----| | 1 | Group by any field, including custom fields | Manual lists, limited fields | Supports flexible workflows across diverse teams and structures; reduces reliance on labels for complex planning | | 2 | Real-time updates (self and shared view) | Limited updates; mostly not real-time | Keeps teams aligned in async or distributed settings; avoids refresh frustration during standups or grooming | | 3 | Swimlanes (horizontal groupings) for any field, including custom fields | Only epics supported for swimlanes | Enables tracking of multiple parallel workstreams, teams, or priority buckets on the same board | | 4 | Combine list and board modes | Separate views with different filters/experiences | Improves continuity of experience and reduces friction switching views | | 5 | View/filter settings persist across list and board | Views not shared; filters must be re-applied manually | Saves time and ensures consistency when switching between views | | 6 | Auto-scaling of new attributes (e.g., new widgets are auto-filterable/groupable) | Requires manual configuration to add new attributes to filters or groupings | Ensures scalability and reduces developer overhead for newly introduced fields | | 7 | Items without grouping value appear in an 'ungrouped' column | Open list / Items sometimes disappear if no list exists | Prevents lost visibility and improves discoverability of 'misfit' work items | | 8 | Saved views replace “switch board” dropdown | Dropdown filters must be manually configured each time; not easily shareable | Improves team coordination and reduces setup time across recurring workflows | | 9 | WIP limits (by count or weight) | Same as existing issue boards behavior | Supports team health and capacity monitoring during sprints | | 10 | Progress % rollups (by item or weight) | Same as existing issue boards behavior | Gives a quick health snapshot of delivery without manual calculation | | 11 | Bulk editing in boards | Not supported | Reduces time spent making repetitive changes to similar work items | | 12 | Drag-and-drop works for all item types | Sometimes inconsistent, not available for all items | Supports fast workflows and intuitive reordering | | 13 | Filter by one or more work item types | Filtering is limited and often only applies to one type at a time | Enables mixed views of strategic and tactical work, improving planning alignment | | 14 | Default grouping options include milestone, iteration, health status, assignee, custom status, label, custom fields | No “auto” grouping options available | Allows flexible team workflows based on relevant planning dimensions | | 15 | Users can customize which values from a grouping are displayed (e.g. only ‘At risk’ and ‘Needs attention’) | All values are shown; no granularity for value-level filtering | Improves signal-to-noise ratio when managing focused work views | | 16 | Milestones and iterations default to last two, current, and next two | No smart default view logic | Saves time and reduces the need to manually filter time-based groupings | | 17 | Items without swimlane attributes are grouped in an 'ungrouped’ swimlane | Items may be hidden or excluded | Ensures visibility and discoverability of unmatched items | | 18 | Swimlanes persist board settings and can collapse/expand independently | Swimlanes have limited controls and no per-group behavior | Enhances board usability, especially for large or complex boards | | 19 | UI clearly shows which swimlane grouping is active | Current groupings are not always clearly indicated | Prevents confusion when switching board views or coordinating with others | | 20 | Actions taken in one view (e.g., list) are immediately reflected in other views (e.g., board) | Views operate independently; changes in one may not persist or appear in the other | Reduces duplicated effort and keeps planning artifacts in sync | | 21 | Combine all work items (epics, issues, tasks) on the same board | Separate boards for issues vs. epics, no view for tasks | Enables unified planning across strategic and tactical layers | | 22 | Switching between list and board is seamless; filters and view settings persist | Context is lost when changing views | Improves user efficiency and maintains mental model during planning | | 23 | Newly created WITs will automatically appear on board | — | — | | 24 | View options (filters, sorts) support common planning fields | Only label-based filters are available | Empowers teams to tailor boards to their context and roles | | 25 | Epic swimlane option is replaced by parent and shows the immediate parent of work items in grouped lists | Epic swimlanes | Supports all work item parent/child relationships including issue/task and future parent/child types | | 26 | Closed items appear in the list alongside open items and only hidden if the filter for state is restricted to open | Closed items move to closed list (if visible, or disappear if not) | Adds clarity so that users can track what was scoped and what was completed; supports retrospective review | | 27 | Users cannot build groupings (lists) by different attributes (e.g., assignee as one list, label as another, and milestone as another) | Users can combine lists of any scope | Simplifies the boards model, removes confusion about what happens when moving items across unlike columns, and allows us to make more informed decisions about presenting data (i.e. if we know this is grouped by iteration, we could use that information to provide insight on the iteration itself) | </details> <details><summary>User Pain and Research Insights</summary> - Confusing navigation between views and boards - Filters and views don’t persist across view types - Slow performance with large item counts - Lack of contextual visibility (relationships, blockers) - Missing capabilities expected from modern tools - Onboarding friction for non-devs: too much setup required </details> <details><summary>Out of Scope</summary> This epic does **not** include: - Changes to the underlying Work Items data model - Introduction of new Work Item types or relationships - Roadmap view redesign </details>