The goal of UX research at GitLab is to connect with GitLab users all around the world and gather insight into their behaviors, motivations, and goals when using GitLab. We use these insights to inform and strengthen product and design decisions.
UX Researchers aren't the only GitLab Team Members who conduct user research. Other roles, like Product Managers and Product Designers, frequently conduct research too with guidance from the UX research team.
Research is successful when we understand our research goals and why we choose one method over another. Knowing and understanding the research question(s) you want to learn about will help you determine which method to use.
We use a wide variety of research methods, workshops, and exercises to help us better understand our users’ needs and goals. Our teams are encouraged to seek out anything that will allow our teams to better collaborate while we continue to enhance our product experience. Some of these are listed below:
What is it
A User Interview is used when we need to learn about what a user is doing in the present, what problems they are having, and what their general attitudes about these problems are.
Bear in mind that users tend to have better recall of things that were particularly difficult or delightful to use (in other words, the extremes). Human memory is extremely fallible and people have a great deal of difficulty knowing what they will want or do in the future. Asking a user how they currently perform a task will likely provide you with idealized information that leaves out any deviations or workarounds they usually perform to complete the task. You’re much better off observing them while they complete these tasks to ensure you’re getting the whole picture.
When should it be used
You should conduct User Interviews at the early stages of a project when you want to generate knowledge about your users’ thoughts, beliefs, mental models, and experiences. User Interviews are great when you need to learn and discover more when building personas and journey maps, gathering feature ideas, and understanding workflows.
Resources
What is it
The 5 Whys is an interviewing technique that allows the interviewer to dig deeper into the users’ mind. When using this interview technique, you start with a broad question, and then begin asking Why five times to learn more about the complexities of the problem.
When should it be used
You should use The 5 Whys to help uncover a user’s motivations and beliefs.
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Journey Maps help visualize the process a customer goes through to accomplish a goal with your product. It’s an accumulation of tasks and actions over time, accompanied by their thoughts and feelings.
When should it be used
Use a Journey Map to help uncover all of the steps a user goes through when trying to accomplish their goals. These insights highlight pain points and challenges they have that your design will solve.
Resources
What is it
A Design Sprint is a step-by-step process that helps teams to solve big problems and test new ideas in a very short period of time. It’s great for aligning teams on a singular goal and building better products, faster.
A Remote Design Sprint has all of the above benefits while allowing teams to work collaboratively in a remote setting, synchronously and asynchronously.
When should it be used
You should use the Design Sprint workshop method when you need to find a design solution/direction for your section quickly or if you're stuck and are having difficulty moving forward. It’s great for solving big problems in a short period of time, but it’s overkill for solving smaller problems that can be resolved with a smaller workshop or exercise, such as a Lightning Decision Jam workshop.
Resources
What is it
A Remote Lightning Decision Jam is a structured brainstorming workshop where a team of between 3 - 8 people come together to define, prioritize, and solve problems without the typical bias that may occur in a standard brainstorming session. It’s really good for aligning a team on a singular goal and coming up with solutions to validate without falling into the trap of open-ended, unstructured discussions.
When should it be used
You should use the RLDJ workshop when you want to work collaboratively to come up with problems/challenges to be solved and then determine a solution.
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
"How Might We" (HMW) is a technique used to reframe a challenge, pain point, or problem(s) into a phrase that is a more opportunity focused suggestion that a solution is possible. It’s important when writing your HMW to make sure you’re writing in the Goldilocks zone: not too broad and not too narrow… just right.
When should it be used
You should use How Might We’s when any part of a project is in short supply of fresh ideas or you’re looking for a way to rearrange your perspective on a challenge or problem you’re trying to solve.
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
N/A
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
A Storyboard is a low-resolution series of “scenes” or main events that helps you visualize and tell a story about a user’s world as they attempt to complete a task or goal using your product. This is the process that movie studios like Pixar use to block out the movie scene by scene prior to filming to ensure they have the key moments of the story plotted. Think of it as creating a mini-comic book of your user trying to use your product.
When should it be used
You should use the Storyboard technique when you want to visualize an interaction or how your user finds out about your product.
Resources
What is it
A Wireflow is a series of low- or high-fidelity wireframes/mock-ups displayed in the form of a workflow that shows the designs for completing a common user task. Wireflows can be shown as full desktop or mobile screens placed in the correct order of a task workflow, or they can be the micro-interactions/portion of a desktop screen.
When should it be used
You should use a Wireflow when you want to communicate how a specific task can be completed on a screen or across screens.
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Coming soon…
When should it be used'
Coming soon…
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
Coming soon…
When should it be used
Coming soon…
Resources
**What is it
Coming soon…
When should it be used
Coming soon…
Resources
What is it
A Remote Moderated Usability Test is a usability test that is performed when the participant is not in the same location as the moderator. Instead of the testing taking place in a lab where all parties are in the same physical location, each party participates through conference calling apps such as Zoom, Microsoft Teams, or WebEx. Everything else about the usability test is the same.
When should it be used
You should use the Remote Moderated Usability Test when it’s difficult to colocate with your participants and you need to validate a design’s efficacy. This is usually done before development has occurred to save time and resources, but it may also be done to validate an existing product’s usability to determine how it might be improved.
Resources
What is it
An Unmoderated Usability Test is a usability test that is performed by a participant without a moderator. This is usually done through an online application such as UsabilityHub, Maze, or UserTesting.com. Everything else about the usability test is the same.
When should it be used
You should use the Unmoderated Usability Test when you want to validate a design’s efficacy but don’t have the time or ability to moderate the research. Unmoderated testing is often the go-to method when you need to move quickly (usually before development has occurred to save time and resources), but it may also be done to validate an existing product’s usability to determine how it might be improved.
Resources
What is it
A 5-Act Walkthrough is essentially a cross between usability testing (you'll still need to define some tasks to be tested) and an interview (you'll also need questions you want to make sure you get answered). Once you've defined these things, you do all of the typical usability/interview stuff intermingled together in a single participant session. The intention of this method is to help a team get feedback on a low- to medium- fidelity mock-up by having the user walkthrough the screens while considering a task. During this time, they describe out loud what they think they’re looking at as they progress through each screen.
When should it be used
Use the 5-Act Walkthrough when you have a design that you want to get feedback on, but you also want to have a discussion with the participants as they move through the screens.
Resources
What is it
A UX Scorecard is a GitLab methodology to evaluate existing workflows of our product. They are mostly done in a heuristic or internal perspective but can involve real users when there is uncertainty. UX Scorecards offer a way to gain visibility and understanding of our product, motivate us to consider how a user may feel during each step, and innovate solutions for making the experience better.
When should it be used
Use the UX Scorecard when you need to determine how users likely feel about a workflow, provide a benchmark to measure following UX Scorecard assessments against, and to explore how it might be improved in the future.
Resources
N/A
Product Managers, Product Designers and UX Researchers have access to the following tools:
Qualtrics: CoreXM with TextiQ - Used for surveys, screening surveys and contacting members of GitLab First Look. To request access to Qualtrics, please open an access request and assign the issue to your manager for approval. Once approved, please assign the issue to @jeffcrow or asmolinkski2. For further information about Qualtrics, including how to create and style your survey, please visit Qualtrics tips & tricks.
Mural - For online brainstorming, synthesis and collaboration. Please reach out to a UX Design Manager or Christie Lenneville for access.
Calendly - For scheduling research sessions with users. A basic plan (free) is usually adaquate for Product Managers and Designers. UX Researchers are entitled to a Premium account. Should you wish to upgrade your Calendly account to Premium, please contact @asmolinkski2.
Dovetail - We use Dovetail to analyze data, collaborate on insights and as a research repository.
Zoom Pro Account - We use Zoom to run usability testing sessions and user interviews. All new team members at GitLab automatically receive a Zoom Pro account.
Optimal Workshop - Used for card sorts and tree testing. We do not have an ongoing subscription to Optimal Workshop. We purchase a monthly license as and when required.
Maze - Used for unmoderated, quick-hit usability testing where you can provide a click-through prototype with a survey follow up. We do not have an ongoing subscription to Maze. Maze does offer a free plan that allows you to run one project at a time.
UsabilityHub - Used for First-Click tests, and Preference tests, Five Second tests. We do not have an ongoing subscription to UsabilityHub. Work with your manager if a license is required.
Dovetail is the single source of truth (SSOT) for all user insights discovered by GitLab’s UX Researchers, Product Designers, and Product Managers.
UXR_Insights project - Prior to Dovetail, the UX Research team used GitLab as a research repository. Instead of reports and slide decks, we used issues to document key findings from research studies. A directory of completed research is available in the project's ReadMe file. The UXR_Insights project is no longer maintained or in use.
GitLab Community Forum - The forum is ran by community members. It's a place for community members to share, ask and discuss everything related to GitLab.
Zendesk - Zendesk is a ticketing system used by GitLab's Support team to track problems raised by customers. Zendesk accounts are available for all GitLab staff.
Chorus.ai - Chorus.ai is used by our Sales team to record conversations that they have with GitLab customers. It has the ability to transcribe and highlight key points during these conversations. To request access to Chorus.ai, please open an access request.
Social media and public forums - Such as Twitter, HackerNews and Reddit.
UX Researchers collaborate with Product Managers to determine the scope of research studies. Where possible, UX Researchers should try to attend planning meetings for their designated groups.
UX Researchers should proactively offer ways in which they can assist in the delivery of research. They should also suggest and discuss their own ideas for research studies with Product Managers.
UX Researchers have the following guidance on how they should be spending their time:
<10% Solution Validation - This translates to less than 10% of a Researchers' time being allocated to assisting Product Designers and Product Design Managers with Solution Validation research.
~60% Problem Validation - Researchers spend more than half their time working with Product Managers conducting Problem Validation research, with the long-term goal of investing their time towards training and mentoring.
~30% Foundational/Strategic Research - Ideally, 1 big project per Researcher, per quarter. These are projects that feed into the Researchers' stage area/team and may be derived by the Researcher. Examples:
Three noteworthy benefits to conducting Foundational/Strategic research:
Assign yourself to any issues you are leading or supporting.
Doing = issues you are working on right now.To Do = issues you plan to tackle in the near future.Blocked= issues you can't proceed with as you're waiting on feedback from someone else.Backlog = issues that haven't yet been scheduled.Problem validation research issue.
1 = Trivial2 = Small3 = Medium5= Large8 = Huge13 = GiganticProactively contact your Product Director, and ask them to prioritize your issues. Inform your Product Director of your capacity based on your historic velocity. This may be more effective as a Zoom call at first, rather than async.
Backlog.Product Manager drafts the discussion guide. When a first draft of the guide is complete, the UX Researcher reviews and provides feedback.
Simultaneously, the UX Researcher begins crafting a screening survey in Qualtrics.
After the screening survey is created, the UX Researcher will open a Recruiting request issue using the available template in the UX Research project and assign it to the relevant Research Coordinator.
The Research Cordinator will perform a sense check to make sure your screener will catch the people you’ve identified as your target participants. If there are multiple rounds of review, the Coordinator will pause activities until uncertainty about your screening criteria has been resolved.
By default, Product Managers are responsible for leading (moderating) problem validation interviews with users. If the study is complex in nature, a UX Researcher may volunteer to moderate. UX Researchers have the discretion to decide which research studies they will moderate and which they will observe synchronously or asynchronously.
The person who is leading the interviews, and who has subsequently supplied their Calendly link to the Research Coordinator, is responsible for creating user interview invites on the UX Research calendar (gitlab.com_kieqv96j35mpt8bdkcbriu2qbg@group.calendar.google.com). Other interested parties (Product Designers, Product Managers, UX Researchers, etc) are encouraged to subscribe to the calendar.
After the interviews are concluded, the UX Researcher updates the Recruiting request. The Research Coordinator will reimburse participants for their time within 2 business days of the interview.
Product Manager and UX Researcher work collaboratively to synthesize the data and identify trends in Dovetail, resulting in insights.
UX Researcher updates the Problem validation research issue with links to findings in Dovetail and, if applicable, unmarks the Problem validation research issue as confidential before closing it.
Product Manager drafts the survey. When a first draft of the survey is complete, the UX Researcher reviews and provides feedback.
The UX Researcher enters the survey in Qualtrics.
Once the survey has been entered into Qualtrics, the UX Researcher opens a Recruiting request issue using the available template in the UX Research project and assigns it to the relevant Research Coordinator.
The Research Coordinator distributes the survey to a sample of participants.
The UX Researcher, will review the responses received so far and amend the survey if necessary. The UX Researcher should advise the Research Coordinator when to continue recruitment.
The UX Researcher will keep the Research Coordinator informed of the survey's response rate and must notify them when they plan to close the survey (to ensure recruitment doesn't continue on a survey that has been closed).
After the survey is closed, the UX Researcher updates the Recruiting request issue. The Research Coordinator will reimburse selected participants for their time (payment occurs on Tuesdays and Thursdays).
Product Manager and UX Researcher work collaboratively to synthesize the data and identify trends, resulting in insights.
UX Researcher documents insights in Dovetail.
UX Researcher updates the Problem validation research issue with links to findings in Dovetail and, if applicable, unmarks the Problem validation research issue as confidential before closing it.
Note: A Lead UX Researcher is the person who devises the research brief and provides an initial outline of the study's goals and hypotheses. A Lead UX Researcher can hold any level of seniority and experience, from Research Coordinator to Staff UX Researcher. The Lead UX Researcher is the DRI for the research study. They should communicate that they are the DRI during stakeholder meetings and within research issues.
Lead UX Researcher meets with the relevant PM(s), fellow UX Researcher(s), Research Coordinator(s) and UX Research Manager to discuss the goals of the study and the hypotheses they have. The purpose of this meeting is to get buy-in from all stakeholders. If a stakeholder is unable to attend the meeting, record the session, and allow them the opportunity to provide their feedback asynchronously.
Lead UX Researcher creates an issue using the Problem Validation template.
Lead UX Researcher applies the ~"workflow::problem validation" label to the associated issue; this automatically removes the ~"workflow::validation backlog" label.
Lead UX Researcher fills out an opportunity canvas to the best of their ability. Ensure the problem and persona is well articulated and add the opportunity canvas to the issue's Designs. Note that you should include content for the solution and go-to-market sections, possibly with low confidence; this section may be likely to change, but thinking it through will help clarify your thoughts.
Lead UX Researcher opens a Problem validation research issue using the available template in the UX Research project. Once completed, assigns the issue to the relevant UX Researcher(s).
Follow the steps outlined for user interviews or surveys. However, for multi-stage-group initiatives, the Lead UX Researcher should take responsibility for all steps outlined in the user interview or survey process, for example, writing a discussion guide. They are welcome to delegate responsibilities to other UX Researchers should they need assistance.
Lead UX Researcher meets with the relevant PM(s), UX Researcher(s) and UX Research Manager to discuss findings and next steps.
The Lead UX Researcher may be required to:
Finalize the opportunity canvas with the synthesized feedback.
Present the opportunity canvas to Scott Williamson, Christie Lenneville, and the relevant Product Director(s).
Solution validation research at GitLab is led by Product Designers, with support from Product Design Managers. Occassionally, Product Design Managers may need to escalate queries about solution validation research to UX Researchers for advice and feedback. If capacity allows, UX Researchers can help with solution validation research efforts.
Any GitLab Team Member can open a research request. If you are not a Product Manager, Product Designer, or UX Researcher, please open a Research request issue using the available template in the UX Research project. Once completed, please assign the issue to the relevant Product Manager, Product Designer and UX Researcher. The team will review your issue and notify you when/if they plan to proceed with the work.
We use the shared UX Research google calendar (link is only available to GitLab employees) to advertise upcoming problem validation and solution validation research efforts. Both Product Designers and Product Managers can add events to this calendar. These invites are only viewable by GitLab employees, your participant will see and use the original Calendly invite.
Attending a UX research session can be enlightening! However, it's important to let the researcher take the lead on interactions with their participant. Some tips when attending sessions:
Like other departments at GitLab, UX Researchers follow the Product Development Timeline and use milestones to schedule their work. Milestones change monthly, find out the dates for upcoming milestones.
If you're new to conducting user research or just want a refresher, please refer to the UX research training resources to help you get started.
Product Designers and Product Managers should complete the Research Shadowing process during their onboarding to gain an understanding of how research is conducted at GitLab.
Both the GitLab CE project and GitLab EE project contain a UX Research label. The purpose of this label is to help Product Designers and Product Managers keep track of issues which they feel may need UX Research support in the future or which are currently undergoing UX Research.
UX Researchers are not responsible for maintaining the UX Research label. The UX Research label should not be used to request research from UX Researchers.
UX Research project contains a UX Research Backlog label. Its purpose is to denote research efforts which aren’t ready to be actioned on. Usage of this label is not required and its workflow is not further prescribed. This label is automatically applied with all UX Research templates.
