The UX team in the Verify:Runner Group is responsible for Runner SaaS and Runner self-managed. We are focused on supporting the Runner JTBDs by understanding what users are struggling with, solving for those problems, and improving the overall experience to make it easy as possible to use runners and CI/CD.
We measure our success through a combination of experience scores, through SUS evaluations of the GitLab product, UX scorecards and Category Maturity scorecards and usage metrics (we are in progress of integrating and making use of these more often). Our goal is to provide the easiest feature set to manage, use and "not have to worry about" runners.
Platform engineers struggle managing large fleets of runners today. They are not equipped with enough configuration capabilities to manage and administer the fleet. This negatively impacts their teams as they sometimes end up running into blockers when using the runners. We have captured many issues, including customer requests and FY22-Q3 UX scorecard recommendations, in the Runner fleet meta epic that further document this problem and how we plan to solve it.
The vision for this problem is to provide users with a flexibile set of management capabilities to troubleshoot quickly and support their teams. To do this, we've broken down the vision into:
In FY22-FY23Q2, we are focused on first improving the overall usability of the runner admin page, to set a solid foundation to ultimately add new runner management features. The improvements to the admin page can be used to then improve the Runner SaaS experience for group runners.
In FY23Q3-FY23Q4, we plan to tackle the CI/CD job queues problem by adding monitoring features to the Admin view that enable platform engineers to get a better glimpse of what is happening across their fleet of runners. We also plan to incorporate features with automated recommendations based on your fleet of runners, so that you can keep them up to the best standards.
We use workflow labels, pretty closely following the product development flow, to indicate that an issue needs design work. We add ~workflow::ready for design when an issue is ready to be taken on by design. Design is responsible for capturing issues that could be taken on in the next milestone, and communicating with the PM and engineering to finalize the list.
When design takes on an issue, the ~workflow::design label is applied and the UX DoD should be added into the description. During the design process, a technical writer is brought into the process to be able to review the UI copy throughout the iterations. If copy was approved, then a comment is left on the issue saying so. Collaboration with development should also be consistent throughout the design process - this especially helps with considering the feasibility of features.
Once design is approved, the ~workflow::ready for development label is applied. Design and development should collaborate to ensure the issue is properly broken down and planned for development.
Issues will not get a milestone attached to them until they are considered as a candidate for an upcoming milestone.
We use the CI/CD UX Definition of Done (DoD) as a tool for assessing the readiness of an issue and tracking the expected deliverables, objectives, and the approval process.
We use the UX Weight definitions for milestone capacity.
| Product Designer | Gina Doyle |
| Product Designe Manager | Rayana Verissimo |
| Slack Channel | #g_runner and #ux_ci-cd |
| Youtube playlist | Runner UX on Unfiltered |
