The past few years exposed us to the heights of unpredictability, and a lot of time was spent on Zoom. The pandemic showed us that planning is not enough for an organization to survive in difficult times. Companies need to be flexible enough to innovate in accordance with altered workflows if they wish to sustain and support market use cases as they evolve. Innovating and iterating at the speed of DevOps requires designers and researchers to look at the user workflow differently, outside of the content of the UI. To understand our users and how their work has changed, we zoomed out our perspective by asking users their key tasks and goals at the Stage level - instead of presenting them with a UI to work within.
At GitLab, we use the Jobs-To-Be-Done (JTBD) framework to always keep room for innovation in our approach to research and customer inquiry. We believe that our users do not purchase our product because of the features and capabilities we build into it, but for what it helps them accomplish in their workflows. To capture more macro-changes in user workflows through this research, we adjusted the level of the JTBD framework to focus on the entire code integration, verification, and deployment process.
When we are too focused on the features and solutions we work on day after day, our frame becomes myopic, our sense of progress becomes skewed, and Conway's law rears its head. Our product then reflects our organizational structure rather than the user's workflow. The JTBD framework helps us be more aware of opportunities in the competitive arena by allowing us to understand the goal of the products at a more fundamental level that can easily be missed by a superficial frame.
Pipeline execution JTBDs
The Pipeline Execution group in GitLab is responsible for supporting the functionalities with respect to Continuous Integration use cases. GitLab CI/CD offerings have come a long way over the years. This realization triggered us to start re-examining the vision we have for the Stage Group earlier this year. We wanted to make sure that we’re leaving no stone unturned. And what better place to start than revisiting our JTBDs?
Designing the research
To avoid cutting any corners, we decided to keep our confidence in the product and our biases aside and speak with users without talking to them about our UI. A privilege of working at GitLab is having a well-documented handbook that is a living and evolving single source of truth. We looked at the documented process and, at the same time, made notes on our assumption around what might not have gone right the previous time we did this exercise. These are the areas we felt we could improve on:
- Making interviews more collaborative
- Documenting the findings without bias
- Helping participants tell us about the fundamental workflow level, and not at a utility level
The interview template
We co-created an interview deck with users to help us codify their workflows. After an introduction to the session to set them at ease, we showed them a relatively blank canvas with different stages of their workflow written on the top of the slide. We started with our GitLab Stages, falling into the Conway conunmdrum. At the end of our inquiry and co-creation of the deck templates that we use across participants, we had the following six steps:
- Define - How code is defined and how it will be integrated and verified
- Locate - How team members gets to know about Infrastructure-as-Code frameworks and how they should be used
- Execute - How the processes and frameworks are ultimately executed
- Monitor - How performance is monitored
- Modify - How teams change existing processes or existing code
- Secure, Deploy, and Debrief - How teams securely release changes to production and learn from their most recent process
Speaking with users for this research activity didn't just help us identify new JTBDs, but also validate some of the previously listed ones. The same research also helped us identify opportunities related to learnability of the tool, post code-integration monitoring capabilities and discoverability of the code-verification practices set up by organization on GitLab for their teams.
Users are at the focal point of our decisons at GitLab and going forward we will continue to improve our research methods and communication practices to capture the insights in the purest form.
