How the UX Research team operates at GitLab

Team structure

The UX research team is comprised of UX Researchers, Service Designers and UX Research Operations Coordinators).

• UX Researchers work within their assigned stage groups, where they conduct UX research on their own and consult on research efforts being done by their teams.
• Service Designers work across stages and groups, where they conduct user research and design to improve the end to end user journeys across GitLab.
• UX Research Operations Coordinators own the participant recruitment process and all things related to research operations.

Our working model

We employ a hybrid matrix structure where Heads of UX Research each oversee several product domains and support 5-7 UX Researchers and Service Designers owning the research for various stages within the product domains.

The Heads of Research oversee research vision and strategy of the product domains and coordinate cross-functional efforts, while providing mentorship and removing obstacles for their teams. UX Researchers and Service Designers drive both strategic thinking and tactical execution within their product areas.

This balanced approach enables deep domain expertise alongside clear accountability, fostering innovation through specialized knowledge and collaborative coordination across our connected product domains.

Teammate pairing

Team members, no matter UX Researcher or Service Designer, can participate in Teammate pairing, where they pair up with another teammate so they can provide and receive feedback from each other. This is an opt-in offering and the team members can self organise.

Teammate pairings gives the team member a consistent partner to share ideas with on research and service design approaches, addressing challenges, reviewing test plans, reports and designs, and gaining experience in delivering feedback. It also gives team members exposure to product areas outside of their own.

How team members are assigned

Domains	Heads of UX Research	Product Areas and UX Researchers
AI	Karen Li	AI Powered Nicholas Hertz Duo Pro & Nano Nicholas Hertz Duo Enterprise Erika Feldman Duo Workflow Erika Feldman, Nicholas Hertz
Core DevSecOps Workflows	Jessica Kane	Create Ben Leduc-Mills Verify Erika Feldman Plan Danika Teverovsky
Monetization & Analytics	Jessica Kane	Growth Anne Lasch, Senior Service Designer - TBH Fulfillment Anne Lasch Optimize Danika Teverovsky
Platforms	Jessica Kane	SaaS Platforms Will Leidheiser Systems Will Leidheiser
Security and Compliance	Karen Li	Security Risk Management Senior UX Researcher - TBH
GitLab Docs Site	Karen Li	Rolling Responsibility
Research Operations	Karen Li	Caitlin Faughnan Mariana Cardinali

How UX Researchers work

Who we work with

We collaborate with Product Designers, Product Managers, and Engineers to collectively determine what areas to conduct research on. The UX Research team works within the Product Development Flow as they partner with Product Management and Product Design.

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.

What we work on

Like other departments at GitLab, we follow the Product Development Timeline and use milestones to schedule their work. Milestones change monthly (find out the dates for upcoming milestones).

We follow a priortization process that helps us distribute our time effectively across the research projects occurring within our stage groups.

How we spend our time

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 researcher’s time being allocated to assisting Product Designers and Product Design Managers with Solution Validation research. Solution validation research at GitLab is led by Product Designers, with support from Product Design Managers. Occasionally, 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 conducting solution validation research.

Product Managers and Product Designers follow the steps in the Validation phase 4 when planning and executing solution validation research.

• ~60% Problem Validation - Researchers spend more than half of 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 Research - Ideally, 1 big project per researcher, per quarter. These are projects are a type of problem validation where little to no information is known about the problem, often using a mixed methods research design. Examples:

Four noteworthy benefits to conducting Foundational research:

1. Researchers gain subject matter knowledge in that topic
2. Researchers have an opportunity to impact Product and influence strategy
3. Career growth opportunities
4. The business benefits by gaining more knowledge/data in an specific area

How we uphold the quality of our work

UX Researchers will frequently drive research projects themselves in close collaboration with Product and/or Design. When this occurs, UX Researchers will take part in a peer review process on the following research artifacts:

• Participant screeners
• Test plans
  • Materials contained in the test plan can include:
    • Scripts
    • Surveys
    • Card sort activity
    • etc
• Final reports/output of the research

There are many benefits to a peer review process:

• Visibility - UX Researchers will be more informed about the research being conducted outside of their direct area of coverage.
• Learning - UX Researchers can learn from each other by reviewing the approaches being taken and the justification behind those approaches.
• Quality - Research deliverables will be more standardized and of higher quality as a result of a peer review.
• Onboarding - New UX Research hires will benefit by seeing standardized examples and learning about the quality bar to replicate.
• Diversity - We value diverse views and perceptions on how the content is being interpreted.
• Mentoring - UX Researchers will have more opportunities to mentor each other in their craft.
• Consistency - Participant screeners, in particular, will have a more standardized approach to how we ask the same questions across the team.

The UX Research peer review process is designed to be asynchonous and inclusive to all UX Researchers. The process is as follows:

1. Share - A UX Researcher has either a test plan and/or a final report that needs to be peer reviewed. They ensure it’s shareable and editable.
2. Post - Within the #ux_research_team_lounge Slack channel, they post a link to the test plan or final report, along with a request to review. They include a date and time that they need feedback by.
   • Example: “Hi - can I please request a review of this test plan (link)? Feedback is needed by Thursday. Thank you!”
   • Best practice: Reviewers should aim to provide reviewers at least 24 hours to review.
3. Review - The reviewer provides feedback directly in the document, issue, etc.
4. Inform - When the review is complete, the reviewer responds to the thread and mentions the UX Researcher.
   • Example: "@ name - your testplan has been reviewed. Let me know if you have any questions!"
5. Edit - The UX Researcher looks at the feedback, follows up on any questions, and makes any adjustments necessary.
6. Mark as done - When complete, they put a green check mark emoji reaction on their original post, indicating that the peer review request has been completed and is closed.

UX Researchers are all required to take part in a peer review with their participant screeners, test plans, and final reports that they’ve created. Additionally, it’s strongly encouraged for UX Researchers to help their peers by reviewing anything submitted through the peer review process.

When reviewing suggestions from peers asynchronously, it’s a best practice to provide a note or explanation when closing suggestions. This is done to explain any rationale behind any decisions made around the suggestion and to add closure to the suggestion.

Ultimately, it’s up to the owner of the document to decide which suggestions they’d like to apply.

How we socialise our works

Socialising pcoming works

To raise awareness and provide transparency on the research projects that we drive, we need to put some additional effort into getting the word out. Note that this announcement isn’t intended to serve as a call for feedback; it’s purpose is to inform team members of upcoming research. The most effective way to do that is as follows:

• Create a brief statement that explains what will be done. (Example: ‘Upcoming UX Research - Hi team! I’m about to start collecting data to inform some new navigation-related decisions focused in the Monitor, Infrastructure, Deployments, and Packages & Registries items with experienced GitLab users.’). Note that the method isn’t called out; that’s intentional here. Keep the announcement focused on what’s going to be accomplished, rather than how.
• List 3-4 bullets with the main research questions the study will answer. These should not include any detail - just very short sentences.
• Link to the issue for additional details.
• A note around the expected timeline for when you’ll share the results. A rough estimate is acceptable. For example, ‘Results will be shared in 3-4 weeks from now’.
• Optional: if you would like to use this post as a way to invite attendees to your research sessions, you can certainly do that. An example on how to do that: ‘If you are interested in attending sessions live, please reply to this thread. Otherwise, I’ll post recordings to this Dovetail project [insert link], where you can watch on your own time.’
• The posting is shared out via Slack to at least the three following channels: #ux, #ux_research, and #product. It’s advised to also share the posting in any relevant stage-group channels, too.

Socialising research findings

When we drive our own research projects, it means we’re also responsible for socializing those insights. The most effective way to do that is as follows:

• Create a brief into on what was done. (Example: Hi team! I recently finished a tree test 🌳 on the left sidebar navigation focused in the Monitor, Infrastructure, Deployments, and Packages & Registries items with experienced GitLab users. I’m excited to share the key insights ⭐ :)
• List 3-4 bullets with the key insights. These should not include any detail - just very short sentences on the high-level findings.
• Links to the: Research report, Video readout, Data sheet, Research issue, Dovetail project
• A ‘Next steps’ sections that includes bullets on what will be happening as a result of the research. These should be links to issues that are actionable insights.
• The posting is shared out via Slack to at least the four following channels: #ux, #ux_research, #ux_research_reports and #product. It’s advised to also share the posting in any relevant stage-group channels, too.

How we maintain coverage

Since the UX Research team works so closely with their stage groups and participants, it’s important to have a plan in place when we’re on PTO to keep research projects moving along - even when we’re taking time off. Such an approach allows us to support each other, as a team. The following steps outline the process the UX Research team follows, regarding PTO:

1. Enter the PTO dates in Workday and within the UXR team availability calendar (internal link). Time off by Deel will ask you to ssign auto-replies to the #ux_research_lounge Slack channel or to your manager.
2. Note any overlapping PTO dates with other team members. This is ok - as long as there isn’t a business impact.
3. Create a coverage issue to address ongoing projects with timely business impact.
4. Ensure your backups: 1) are not on PTO, and 2) agree to be a backup for you.
5. Inform your manager of your PTO dates in your next 1:1 and demonstrate the above steps have been completed.