Blog Uncovering the diverse needs of non-engineering GitLab users
Published on: October 26, 2020
5 min read

Uncovering the diverse needs of non-engineering GitLab users

This post describes how the System Usability Scale (SUS) uncovered opportunities to improve the GitLab user experience for non-engineering users.


I discovered UX research when I was looking for my next opportunity early this year as a researcher. The field's initial impression intrigued me, so I spent the following weeks learning from online courses, books, and other UX researchers. I started networking and asking for informational interviews. One particular conversation with Katherine Okpara, UX Researcher at GitLab, led to a capstone project. We discussed the System Usability Scale (SUS) survey that is run quarterly at GitLab and uncovered an opportunity to better the user experiences for GitLab users in non-engineering roles.

Understanding the problem

After taking a closer look at the trends and themes from the survey data, I learned that many non-engineer GitLab users are having difficulties working in GitLab. Most feedback came from users in product management, product design, academic research, and executive leadership.

Based on the SUS feedback, I hypothesized that non-engineer GitLab users take longer to learn how to use the tools in GitLab. They may be overwhelmed by the many features of GitLab and have less experience with competitor tools.

With all the Auto- and advanced DevOps features creeping in constantly, it becomes harder to use Gitlab as a simple git repository system with issues/MR/wiki/simple CI for small non-DevOps teams…

Many engineers expressed their frustrations with persuading or teaching their non-engineer colleagues to use GitLab.

I've been using GitLab for more than four years, so it's obvious and intuitive to me, but I am finding coworkers new to GitLab are increasingly unable to figure out some of the features on their own. As a specific example, we had someone propose to use a different code review tool, but when I showed them how to do a side-by-side diff and view the file tree, they were OK with it. These features are obvious to me as I've watched them get added over time, but I think the cues for them may be too subtle to new users.

After considering these challenges, I believed that non-engineer users would benefit from a tailored onboarding experience.

Defining goals and objectives

Through this project, my goal was to understand these users' needs and pain points and identify ways to improve their user experience with GitLab, especially during the onboarding process. I set out to answer these questions:

  • What are the areas of GitLab particularly challenging for non-engineer users?
  • How long does it currently take non-engineer users to get comfortable with GitLab?
  • What do users need to learn during onboarding to use GitLab more easily?

Conducting interviews with GitLab users

To get a deeper understanding of the user experiences, I wanted to interview diverse groups of roles and get as many sides of the story possible. I started close to home and spoke with GitLab employees who use GitLab every day for work. From this set of interviews, I learned that:

  • The majority of the participants expressed frustration with using the Search function.
  • The majority of the participants utilized other tools such as Figma and Google Docs to complete their work.

The next step was to conduct interviews with external GitLab users to ensure that I was forming a balanced perspective. I recruited participants by sending a screener to the GitLab First Look research panel and experimented with recruiting outside sources such as Reddit and LinkedIn.

  • All of the participants proposed the need for a better workflow
  • Some participants would like a more robust approval system that easily tracks the project and its members.

Leveraging secondary research

Due to recruiting constraints, I could not interview as many external users as needed to gain a full picture of their experiences. To conclude everything I learned so far, I decided to look into data from previous GitLab research projects and analyze findings according to the themes observed in each set of data. From this secondary research, I learned that needs of non-engineer GitLab users were diverse depending on their specific roles:

  • Many researchers expressed that they want the ability to reorganize and customize their GitLab UI.
  • Executives said that the page layouts and overall structure are too complex and affect how they navigate the site.
  • Many product managers expressed that GitLab features are inefficient and incomplete for task management and tracking.
  • Many non-engineer GitLab users want a documentation feature separate from Wiki.

Synthesizing findings from interview and survey data

Overall, many non-engineer GitLab users suggested improved onboarding and better help documentation to help them get used to new features. These users are overwhelmed by GitLab features and want to customize the feature menu they see.

I also saw a trend of users having trouble finding what they need from using the search function. Additionally, these users are more likely to supplement missing features with other services (i.e., Jira, Trello, Google Docs, MURAL, Figma).

What's next?

I now have a better idea of the challenges and needs of diverse groups of people who use GitLab. To invest in critical areas that would improve the GitLab experience for non-engineers, I recommend the following next steps:

  • Stakeholder Interviews: Present findings to the stakeholder and get their perspectives. Understand whether the research insights are consistent with business needs and outline potential deliverables.
  • Usability Test: Learn about the users' behaviors in action. How are non-engineering users navigating between features? Where do they experience challenges, and where do they experience delight?
  • A/B Testing: Compare the current UI design to a design iteration that results from the findings.

What I learned

Unfortunately, research projects don't always go as planned, so researchers will need to be adaptable. Adequate documentation will allow researchers to revisit past projects to collect secondary research for instances like these. It will also make it easier for stakeholders to access research projects without going through researchers each time.

About the guest author

Erica's background is in academic research and psychology. Her curiosity about human behavior and emotions steered her in the direction of research. Her favorite ways of learning are through her own experience and from listening to other people's stories.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert