This interview is part of an on-going serie we are conducting with UX researchers. The goal is to shed light upon this role: its diversity, practices and the people moving it forward.
Yiching is Lead UX Researcher at Scaleway, a cloud provider who helps developers and businesses to build, deploy and scale applications. She has been working in the field of UX since 2014, as a freelancer, in agencies and in-house.
I chatted with her in September 2022 and in April 2023 about the challenges of a complex B2B product, working with limited UXR resources and on repository projects.
UX is the perfect role for someone curious and who is afraid to get bored.
The challenges of a complex B2B product
Yiching has always enjoyed working with complex and technical B2B products.
I’ve worked with hotel managers, traders, aeronautics engineers, mechanics.
But when she started working for Scaleway, she realized she had never worked with such a complex product. This complexity boosts her motivation but it becomes a struggle when recruiting new team members and UXR participants for their research studies.
Despite these challenges, Yiching mentions a positive aspect of this complexity for UXR: it avoids taking shortcuts because we think we understand what users need.
In agencies, working with B2C products, it’s not uncommon to skip research, conduct a benchmark, design and deliver. […] You can’t do that with a B2B product, you have no choice but to understand users to design.
Team member recruitment is challenged by their B2B UXR experience, willingness and ability to learn about complex products like those developed by Scaleway.
Her criteria when looking for a researcher are:
- someone with a designer mindset (able to identify the right problems to solve)
- a fast learner, ability to understand complex subjects
- someone who can conduct research and also teach others how to do it at the same time
- someone empathetic, positive, proactive, and organized
- someone able to give and receive feedback
Recruiting participants for research studies in the field of cloud computing can be challenging due to the technical expertise required, limited population, time constraints and competition for participants.
Working with limited UXR resources
Being part of the team of 3 researchers, she expressed a situation which is very common in companies with a growing UX maturity: the research need is much higher than research capabilities.The team struggles to meet the research needs of 18 squads overseeing 20+ products.
Since 3 researchers can obviously not cover the research needs for so many products and stakeholders, they have 2 priorities:
- train stakeholders and create processes and tools to let them conduct research by themselves as much as possible
- work closely with the Lead PM to prioritize research needs and provide varying levels of support to different teams and projects as needed
For instance, UXR team adapts their processes to different PM based on their research expertise. A PM with limited research skills might require a researcher to support them during interviews, whereas a PM experienced in research may only need coaching during the preparation phase (such as defining research questions, selecting methods, and crafting the interview guide or survey).
They also follow research projects with high business impact more closely.
Having no team member dedicated to research ops, they build resources as they go. These resources include a playbook, guidelines, and templates for various research tasks such as invitations, consent forms, interviews, user testing, surveys, reports, and Figjam templates for kickoffs and debriefs. By creating these resources, the team can save time and ensure consistent application of research practices.
Our goal is that no one has to start a research study from scratch.
A repository project with a high number of stakeholders
In the not too distant future, Yiching would like to implement a repository tool at Scaleway. Having discussed with organizations who have done so and face challenges (difficulties to maintain, low usage), she has a pretty precise idea of how she wants to do it:
- no unilateral decision from the UXR team
- treat the repository as a product: kickoff with stakeholders, understand repository users’ need with interviews, benchmark tools, start small and iterate
- define the repository format and its taxonomy carefully
The high number of stakeholders who will be using the repository adds complexity to this project because they all have different levels of involvement and different needs.
She has been thinking about implementing a repository for quite a long time but doesn’t want to rush the process because she knows how ambitious it is.
