Data Exploration and dashboards are often heavily used terms that get interchanged and overloaded. There are multiple types of views in GitLab that are a collection of visualizations, but are hardcoded so the customer has very little ability to expand upon or explore. With that in mind, the goal of this epic is to understand the opportunities we have to unify these concepts into a seamless, easy to understand experience for our users, thus eliminating the confusion they have when knowing where to look to answer x question from their data. Our desired outcome would be a unified Dashboards navigation item that is data agnostic, uses common UI patterns to help users query, filter, and visualize their data. The Insights team will build the foundational framework necessary for both competitive dashboard and data exploration tools. We are not attempting to own or build visualizations for other teams, as we are not the subject matter experts across the various streams of data and use cases at GitLab. We will, however, collaborate to provide the framework (iterating as new use cases arise) and support the migration path for existing dashboards, and thus learn about the use cases and data exploration needs for each data source. By unlocking this cross stage data exploration experience, customers will be empowered to create their own dashboards that include visualizations from every stage in their devops flow that is appropriate for their needs, thus removing the need to go to multiple screens just to get a quick snapshot of team, system, and customer health. This will also improve overall satisfaction with the GitLab user experience as customers will find more flexibility in the way they consume data, less hard-coded experiences that only partially suit their needs. ### How this maps to our FY26 Objectives: This ties into the current FY26 Objectives to improve UX, deliver quality over boring solutions, and improve the feeling that GitLab is a partner not just a vendor. * Simplified navigation and access at the correct level * Provide a feeling that there is a one-stop shop for asking questions of data and visualizing customer-tailored experiences around GitLab * Not all GitLab customers structure their groups/projects the same way, so we should explore how to best provide an organization level data exploration experience that truly feels cross-stage and cross-org * Ease of querying to unlock insights * Give users starter experiences, access to underlying queries, and smart launch points around the UI so they feel that they can ask questions AND stay in context of what they are working on. This could very much be linked to something with Duo as an assist to "what insights can I get from this data?" "are there trends over the last 7 days of interest?" * Insights means making data driven decisions * Often GitLab builds fews that only contain one stage of data, and that can mean that the customer can't make the correlation to how one area affected the outcomes of another. By breaking the barrier of data siloes, we provide customers with the ability to build experiences that are team driven and help them make those connections. ### Dashboards vs Data Exploration I think it would be a good idea to piece out two concepts: - Dashboards: * Hardcoded, OOTB experiences that are GitLab built and can be used as starter dashboards for immediate insights * Many of these exist today under various locations in GitLab, mainly Optimize dashboards under the Analyze navigation * Customizable - Data exploration * A query experience that can be launched from any location to get immediate insights in context of a particular area of of the DevSecOps flow * A query experience (should be the same UX) embedded within the customizable dashboard experience that allows the user to build/save visualizations from any supported data source. I think people often get confused when they start building these things because they can look the same and even have the same bits under the covers, but they solve different use cases. **Out-of-the-box GitLab experiences:** For the first use case, GitLab already has roughly 30 dashboard-like UI experiences. Unfortunately, there is no single landing experience in the navigation to explore all of these, and users may have to jump from navigation point to navigation point to answer some simple questions. These experiences, however, are a foundational piece of the getting started/onboarding experience with GitLab and we will migrate these to a consistent dashboard framework and a consolidated UI navigation point for easier consumption. OOTB experiences also serve as an educational launch point for providing customers with the "what's possible?" on their data exploration journey and inform how they might combine various panels to create their own purpose-built dashboard. **Data Exploration (multiple purpose solution):** The second use case is the overarching need to allow users to ask whatever questions they want from their data (data agnostic so this could be security, VSA, pipelines, plan, etc) both ad hoc and in service of building customized dashboard views for their organization. **_Data Dictionary -\> Data Explorer -\> Dashboards_** Dictionary: give customers the ability to understand what data/attributes they have. - Docs data dictionary where we simply document every piece of data we ingest. - Or this could come in the form of a in-product dictionary. This option is usually interactive and the users can try out different queries there or just scroll through and click around in different areas. Those are super handy in either form to help users get familiar with the data attributes This is where all of the bits sort of come together and the user has a lot of power to build whatever they want in the moment. It could be a moment in time dashboard (incident response investigation) or a common team dashboard that they use every day in standup to check service health. This could also be a quick ad hoc query, even launched by Duo to ask a question in context of whatever they are doing, with no intent to save. - Ability to query all of their data, source agnostic in one consistent experience, * This could be a filter bar or a query language (GLQL in the future) * This could be launched as a solo experience from anywhere in the product and * This will be part of the dashboard creation flow, used to create panel visualizations - - Creating a new dashboard- this is largely structurally in place with very few bells and whistles but the bones are there. Adding widgets, reordering, resizing, storing with a name, editing, etc. - Providing OOTB widgets or prebuilt dashboards- similar concept here to what PA built with the audience and behavior dashboards as well as the "common" viz charts in the New Dashboard flow. Depending on how we want to accelerate this feature, we could either scrap the concept of prebuilt charts in favor of prebuilt, but clonable/editable, full dashboards based on our informed opinion on a use case, and then anything else, the user could query themselves. ### Phases to achieve the unification goal: The goal is to eliminate all the one off ways of creating charts or dashboards and unifying them into the same space. So from a customers perspective, there’s no confusion where to go when you need to ask a question of your data. 1. Expand foundational dashboard features so that we can cover more use cases. This includes things like support for markdown tiles, ability to clone dashboards, easy querying, etc 2. Extend viz designer to allow querying metrics so users can easily build a dashboard with customer (PA) and system health information 3. Encourage/ assist the VSA team to build their own query experience in that space 4. Shop to all teams who have a dashboard under the Analytics left nav. This could simply be a direct migration to a prebuilt dashboard that is not editable or clonable or they can bring their data source along. 1. Further support specific use cases around confidentiality 2. More advanced user control RBAC 5. Once that foundation is there and data querying becomes more robust, CS teams can help us expand our library of prebuilt opinionated dashboards based on their areas of expertise. It’s like crowdsourcing from SMEs. Specifically for things like observability use cases where there are 100s of types of infrastructure, applications, FE monitoring, we will need support from internal SME to build out our dashboards due to the size of the Insights team.