Uncovering the diverse needs of non-engineering GitLab users

Erica Huang ·
Oct 26, 2020 · 5 min read

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:

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 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.

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:

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:

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.

Open in Web IDE View source