Package and container registries are often overlooked yet critically important to the product development process. My first design task for GitLab was to improve the user experience of the registries and set the foundation for the overall product vision. I partnered directly with the package team, made up of representatives from the entire product organization, including product management, engineering leadership, and quality assurance. In the end, we confidently built a new user interface grounded in robust user data.
Before kicking off formal user research, I spent a few weeks in exploration; interviewing and discussing the package registries with stakeholders across the organization. These individuals included team members from sales, marketing, support, and the internal infrastructure team that dogfooded the product. The exploratory interviews provided a rich perspective from which we based our formal user research.
Additionally, we performed a robust audit of the current product and general package market. We discovered containers and packages had completely different needs and data points. Even then, each package format (npm, maven, Conan, etc.) had unique data requirements. With this data in hand, we started formal user research.
To set a strong foundation for the trajectory of our newly formed team, we focused our research on understanding the comprehensive needs of our users around artifact data. We split our discovery efforts into two phases: quantitative and qualitative.
First, we set out to understand what data is important by sending a survey to a broad audience related to the package and container registries. Those insights guided in-person interviews with participants to get a better understanding of why certain pieces of package data ranked higher than others.
We started with a survey in order to gather quantitative data around what package metadata was most important. We asked users to self-select the package format they were both familiar with (up to 2). After self-selection, they were provided with a list of metadata specific to that package format in a random order, asking the participant to stack-rank by order of importance. We concluded the survey by asking if any data they thought was relevant was missing or if they had any other thoughts. This data would answer the “What?” as in “What data is most important?”
The thorough research we did around package and container data was foundational to our package stage direction and interface. We walked into the design phase of the project confident in our decisions based on this data.
“I am so happy Iain pushed to do the survey and the interviews as part of our first research project.
We confidently based a lot of business decisions on that data at the start, and almost two years later, we still reference some of the insights.”
- Tim, Senior Product Manager @ GitLab
After sharing the research results with the broader package team, we kicked off the design phase with an asynchronous workshop. Each teammate went through a series of eight exercises exploring different areas of the package and container registry UIs and provided their thoughts on solutions.
An important aspect of the project was to bring the package stage UIs into parity with the Pajamas design system. While this can feel restricting at times as a designer, in this case, it allowed for key advantages:
Iteration is incredibly important to the design process, and it is made even better by an organization that boldly embraces iteration like GitLab. The main design was split into two main phases. First, shoring up the existing design with minimally viable changes (MVC). This was followed by a second phase polishing the interface and overall experience. Inside each of these phases, the design went through many iterations based on feedback gathered from across the company.
Throughout the process, everyone from engineering to quality and even support were brought in as part of the collaborative design of the package and container registries. Through many iterations, we created a design that was easily accessible to users while flexible enough to accommodate a variety of package-format specific needs.
“Love! It is simply so much easier to grok the entirety of the data on this page. Great job, Iain!”
- Christie, Vice President of User Experience @ GitLab
The official solution validation exercise for the container and package registries was a series of remote moderated user interviews. Testing was performed with internal stakeholders, dog-fooding engineers, and 18 external participants ranging from engineers to system administrators.
Each session started with exploring each participant's technical background. Next, the participants were asked to complete five tasks related to the registry using a Figma prototype. After the tasks were completed, participants were walked back to specific UIs and asked to thoroughly describe the data being presented. As validation, we wanted to confirm participants could identify each of the different pieces of package or image-related data shown in the UI.
As part of the research initiative, we collaborated with team members from throughout the organization.
After completing multiple rounds of feedback gathering, validation, and design iteration, we walked away with a user-validated design that was ready to be built by the engineering team.
Thinking at a higher altitude, we also walked away with valuable insights around users’ expectations.
We were able to further utilize the data and insights from testing to guide priority during planning breakdown with the larger team.
GitLab is a very iterative company that focuses on the minimal viable change. With this in mind, I partnered with the broader feature team to break down the design changes into the smallest parts possible.
From the start, we knew the UI design needed to be flexible. There are a variety of different artifact types, each with their own needs and unique data. The design was intended to be flexible enough to accommodate all of those differences.
Our final product successfully achieved our goal of flexibility and scalability. A few months after the design launched, a different team inside GitLab was able to use the design as a blueprint for their new terraform module.
In the end, the design required no updates to successfully accommodate the needs of the new registry while maintaining a consistent user experience for the customer.
As a feature team, the Package stage was uniquely excelling at collaboration across product, design, engineering, and quality. We created a repeatable methodology based on our learnings, creating ThinkBIG!
Specifically, ThinkBIG! is a sync-meeting held monthly by the package team. The focus is for the strategy (PM and Design) to inform the broader team on a variety of topics, including design reviews, presenting research data, discussing large scale initiatives, and bringing the team up to speed on the current roadmap and team strategy.
“As a front-end developer, working with Iain was a complete delight. His attention to detail and openness to discuss and iterate on design/UX ensured that there was never any ambiguity or a feeling of being unsure on what was required.
Iain has a very strong focus on the end user and what will be of value to them and as a developer with a similar approach, it made working together a really enjoyable experience that produced great results.
I welcome the opportunity to work alongside him again and would recommend the same for any one else.”
- Nick, Senior Front End Engineer @ GitLab
Throughout the time I was working with the package stage, we experienced a consistent growth in both package and container registry usage, generally represented as a 1,200% usage increase from when we started.
