How the UX Research team operates at GitLab

Team structure

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

• UX Research Operations Coordinators own the participant recruitment process and all things related to research operations.
• 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.

UX Researcher working models

To maximize research output and growth opportunities, we have established two working models that UX Researchers can choose to work within.

Single UX Researcher support working model

This model has a single UX Researcher working on a given UX research project and/or stage. Most likely, the UX Researcher is the assigned UX Researcher for the stage or stage group the UX research project is associated with.

Collaborative UX Researcher working model

This model is defined as having two UX Researchers working together on a single UX research project and/or stage. Most likely, both UX Researchers are assigned to the stage or stage group the UX research project is associated with. Having two UX Researchers collaborating together on a single UX research project and/or stage enables both of them to collectively build domain specific knowledge about the space, so the product stage can benefit from different perspectives on a given research topic. It also provides opportunities for the UX Researchers to mentor and be mentored by their partner, avoid silos and mitigate the risk of single point of failure.

Applying this model at scale means we can systematically explore rotation options to facilitate individual growth of the UX Researchers, and enable all UX Researchers to learn more areas across the product so as to identify more cross-stage research opportunities.

Note that additional time and planning may be required with this model due to the increased collaboration.

UX Researcher pairing

UX Researchers, no matter which working model they adopt, can participate in UX Resaercher pairing, where they pair up with another UX Researcher so they can provide and receive feedback from each other. This is an opt-in offering and the UX Researchers can self organise.

UX Research pairings gives UX Researchers a consistent partner to share ideas with on research approaches, addressing challenges, reviewing test plans and reports, and gaining experience in delivering feedback. It also gives UX Researchers exposure to product areas outside of their own.

How UX Researchers are assigned

Each UX Researcher is assigned to multiple, related stage groups, so they can focus on a larger product area. They work closely with Product Managers and Product Designers to ensure research projects are focused and provide answers to design questions. You can find more information on these stage groups here.

The assigned UX Researchers are the go-to person for their assigned stage groups for collaboration in projects and subjects:

Section: Stage Groups	Assigned UX Researchers
Systems: Distribution, Geo, Cloud Connector Data Stores: Global Search, Tenant Scale, Database SaaS Platforms: GitLab Dedicated, US Public Sector Services, Delivery Deploy: Environments Monitor: Observability	Will Leidheiser
Fulfillment: Purchase, Utilization, Fulfillment Platform, Billing & Subscription Management, Provision AI-Powered: AI Framework, Duo Chat, AI Model Validation	Nicholas Hertz Anne Lasch
Monitor: Product Intelligence, Product Analytics	Nicholas Hertz
Manage: Import and Integrate, Design System, Personal Productivity, UX Paper Cuts	Thaina Tavares
Plan: Project Management, Product Planning, Optimize, Knowledge	Danika Teverovsky
Secure: Static Analysis, Secret Detection, Dynamic Analysis, Composition Analysis, Vulnerability Research Govern: Security Policies, Threat Insights, Compliance, Authentication, Anti-Abuse, Authorization	Karen Li (interim cover)
Create: Source Code, Code Review, IDE, Editor Extensions, Code Creation	Ben Leduc-Mills
Verify: Pipeline Execution, Pipeline Authoring, Runner, Hosted Runners Package: Package Govern: Pipeline Security	Erika Feldman

How UX Researchers work

1. We collaborate with Product Designers, Product Managers, and Engineers to collectively determine what areas to conduct research on. The UX Research department works within the Product Development Flow as they partner with Product Management and Product Design. Additional details can be found here on how UX Reseachers prioritize research projects.
2. We follow a priortization process that helps us distribute our time effectively across the research projects occurring within our stage groups.
3. 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).

Note that UX Researchers adopting the Collaborative UX Research working model can operate in a number of ways. The UX Researchers who are working in this model will work closely with each other and with the stakeholders in the product stage to determine the most suitable way to operate, particularly on who the go-to person should be, and for what, and how to initiate, respond to, and work on research projects. The flexibility here is intentional since teams often work differently with unique goals.

How UX Researchers decide what to research

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.

How UX Researchers spend their 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 UX Researcher conduct peer reviews

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 UX Researchers socialize upcoming research projects

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.

How UX Researchers socialize 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.

Below is an example of the formatting:

How the UX Research team handles scheduling Paid Time Off (PTO)

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.