Design: Improve the "Add metric" and "Create dashboard" experience in Metrics Dashboard
☝ The Problem
Adding a metric, editing a dashboard or creating a new dashboard can be quite confusing for a first time GitLab Metrics user.
In GitLab today a user has 2 ways on adding new metrics into their dashboard:
- Using the add metric modal - when clicking on the "Add metric" button which adds metric to the default dashboard.
- Through dashboard.yml file - user first needs to manually create a new dashboard.yml file which defines a custom dashboard, then add metrics manually in the .yml file - this will result in a new metric on a custom dashboard.
Those 2 workflows are completely separated flows that provide a similar result (adding a new metric to a dashboard) to the end user.
- From the engineering perspective maintaining 2 separate workflows, is an overhead.
- From the user perspective, having two separate flows is confusing and unnecessary.
The main problems with the current user experience:
- It's unclear what to do with the Default dashboard
- The path toward creating a new dashboard or editing the current dashboard is unclear
- Overall it's unclear how Metrics work, where the files are stored, how to work with them, etc.
To address them, we want to:
- Clearly communicate in Metrics UI what action are possible, not possible and why with our OOTB dashboards
- Leverage the OOTB dashboards in Metrics as an educational experience for the user during their first time experience
- An OOTB dashboard should bring value to the user right away, plus serve as a convenient "template" to expand upon
- Provide a clear path towards creating a new dashboard and editing the current (OOTB) dashboard
- Guide the user through the experience by providing helpful tooltip information, confirmation messages etc.
Further details
- Check out the current Metrics experience in Tanuki-Inc project
- Current "Add metric" flows in Mural (assumes that the user already configured Prometheus and created a custom dashboard)
Intended users
User experience goal
- "I want to quickly and easily add a new metric to my dashboard."
- "I want to quickly and easily create a new dashboard."
What does success look like, and how can we measure that?
This issue is meant to analyze the current experience and identify areas to improve. The outcome will be a mix of user flows, discussions and follow-up design and implementation issues.
💡 Design
🖥 Metrics UI
It's important that we strike the right balance between the simplicity of an abstracted UI and the flexibility and control of the git workflow. The git workflow we use for managing dashboards should be well explained and simplified wherever possible in the UI, without leaving the user in the dark about any underlying processes that happen in their project when they make changes in Metrics. We can do that by adding helpful help text, confirmation messages that provide extra context and suggest further actions, being intentional about the language we use and by simplifying the forms wherever possible.
📈 Default dashboards, custom dashboards... Just dashboards.
Note: I'll be referring to the dashboards that come predefined with Metrics as OOTB dashboards, and to the dashboards users create as custom dashboards. These terms are to only be used internally for the convenience sake as long as these dashboards are different in implementation and there's a need to differentiate between them internally. In the UI dashboard names will be based on the metrics they display (the purpose/function of the dashboard).
We need to offer a unified experience to the user, regardless of whether they use the dashboards that come with Metrics out of the box, or whether they create their own dashboards. The experience should follow the same interaction patterns, same functionality, and be as intuitive and simple as possible. Custom metrics will be deprecated, so there will be just one type of dashboard and metric.
Ideally, we want to make sure the OOTB dashboards are editable (see Issue to make OOTB dashboards editable), just like the custom dashboards. Eventually, the functionality shouldn't differ between OOTB and custom dashboards. However, due to the implementation constraints we can't have that yet and need to keep OOTB dashboards read-only.
🚀 Iteration breakdown and follow-up issues
MVC
- We can allow users to access Metrics Settings by linking the Settings > Operations > Metrics page in the UI
- We can allow users to create new dashboards by duplicating the current dashboard or by creating a new .yml file
Next 2-3 iterations
-
🔗 Design: Create mockups for the proposed user flows (includes additional work around the experience for setting a dashboard as home page and defining helpful alerts throughout the experience) -
🔗 Design: Improved "Duplicate dashboard" experience -
🔗 Design: "Create new dashboard" experience -
🔗 Design: "Add metric" screen -
🔗 Design: Allow adding alerts as part of the "Add metric" workflow -
🔗 Create a .yml file template for creating a new Metrics dashboard