5 things UX Researchers can do differently: a reflection after Uber’s layoffs
Opinions expressed are solely my own and do not express the views or opinions of my current and past employers.
In September 2019, without warning, Uber laid off almost half of its researchers globally. This followed a similar lay-off of market researchers only a few months prior. In an open letter from the leadership, it was made clear that the company intended to rely more on rapid AB testing to make product decisions, rather than on user research.
From that moment, researchers who survived the lay-off went on a soul-searching journey, exploring our self-worth and the meaning of existence. Some read the letter over and over again, trying to make sense of it. Some took the chance to ask the leadership what value they place on research. Some confronted with their immediate product teams, wondering what they have done wrong.
Needless to say, there were multiple reasons behind the layoff, far beyond the value of research. However, as I spend more years in the research role, I have started to question its purpose, too.
A few days after the layoff, everyone from my product managers (PM) to the office site lead, came over and told me how important research has been, and how much researchers contributed. While I felt lucky to have great alliances, I couldn’t help but think they just wanted me to feel better.
Some of my PM friends outside of the company were more direct with me. They shared stories like this:
“Once I wanted to change the way certain things look on the web navigation, my researcher said no, because it would affect user experience. He would need to run a study first. I asked how long it would take, after a careful calculation, he said at least two weeks. That immediately blew up my mind. I stared at him for a minute, almost looked into his soul. Eventually, I said: ‘My engineers and I can build this in two hours, can’t we just build it and make decisions based on data?’” — Product manager, a leading fin-tech company
I started to get the sense that research sometimes feels like the blocker of execution from the PM’s perspective, but that was never directly communicated to us.
Of course, one may argue that user research uncovers problems and user needs, and provides guidance and direction at early product stages. Foundational research serves these purposes, but it doesn’t happen often. Evaluative research, which takes place rather frequently, takes a minimum of one week from planning to recruiting to reporting. If we cannot make the process quicker, what can we do to make user research more practical, and less blocking?
Being A Neutral Observer ➡️ Bringing in Strong And Subjective Opinions
Researchers are used to representing users, putting our opinions aside to neutrally report users’ needs. We tend to use soft terms like “consider…”, “how might we…” when giving recommendations. However, a lot of times, the team actually wants to know our thoughts. Those are users’ needs, but so what? What do “you” think? In fact, PMs hope their cross-functional team members can provide different or even opposing opinions based on the information they’ve gathered, so that they can have someone to bounce ideas with, instead of solely presenting the findings to them, and let them make the decision. This can lift the PM’s burden of having to first digest, synthesize, and then think about action plans.
The very influential researchers I’ve met are usually those who can form a strong opinion after research, and act like thought partners, as opposed to those who are only craft in conducting perfectly rigorous research. Researchers need to believe that our value to the company is not only the ability to gather unbiased user needs, but also our very own point of view.
Looking For Opportunities To Conduct Research ➡️ Creating Value From Existing Research
It is a common expectation for experienced researchers to be proactive in identifying research opportunities that are not directly requested by the product team. However, not every team or product needs research all the time. When there aren’t any research needs, instead of researching for the sake of it, it would be better to utilize and consolidate existing knowledge from cross-functional insight teams.
For example, at Uber, researchers lead “insight sprints” during the year-end planning season. In insight sprints, user-facing functions such as user research, market research, customer services, and operations come together to share their insights and synthesize critical user and business problems that are not yet addressed. These serve as important input and guidance for the roadmap next year. It is a good way to utilize what we already learned throughout the year without having to conduct additional research.
Spending Time Perfecting Research Methodologies ➡️ Spending Time Understanding How The Product Works And Its Technical Limitations
It is great that researchers spend time exploring different methodologies or fine-tuning existing ones. However, it would be more beneficial to the broader team if researchers have deeper product knowledge.
When it comes to product development, there are many constraints and variables that non-technical roles usually don’t consider, such as dependency, engineering resources, how much a PM can realistically do, etc. Without those understandings, it would be hard to provide practical and actionable advice.
Take Uber for example, in order to provide recommendations that land well, researchers need to be mindful of the priorities of the map, market place, driver, rider…teams, as those all impact the rider experience. Things like the trade-off between collective wait time and individual wait time also needs to be considered. Externally, policies and regulations are factors that can’t be ignored.
Create Personas And User Journeys ➡️ Accept That Not Every Feature Needs User Journeys and Personas
Walls covered with colorful post-its, personas that are beautifully designed, journey maps with incredible details… These have become iconic images when it comes to User-Centered Design. However, sometimes they function more as flashy tools that design consulting firms use to attract clients. Pragmatic researchers need to carefully choose when to use, or not use, those tools.
Personas and journey maps are helpful for teams that have a limited understanding of users, and/or haven’t done user research before. They could also be helpful for teams working on products where they are not the users, such as medical products, products for construction workers, apps for truck drivers, etc.
For teams that already have a fair understanding of their users, personas and journey maps are usually hard to execute. Especially for roles that tend to be more practical-minded, like engineers. Knowing “Tom, 35 years old, consultant, takes Uber Black when traveling for work but prefers Uber Pool for personal trips…” wouldn’t do much help in their day-to-day work. Eventually this creates the impression that user research is not useful.
Ruthless prioritization is a good way to avoid this trap. When prioritizing, besides considering the value of a project, we also need to only work on projects that the team has the resources and interest to act on once the result comes out.
Some suggest that if you don’t feel pain from the trade-off during prioritization, you are not really narrowing down to things that absolutely need to be worked on. Researchers need to let go of projects that are interesting, but don’t hold real value.
The Expert of Users ➡️ The Safari Guide that Enables Moments of Understanding
Last but not least, the role of a user researcher needs to evolve. In The Future of UX Research, Monty Hammontree mentions that researchers shouldn’t see ourselves as the owner of user’s voice. We should transform from methodology gurus and research executors to tour guides that enable everyone to see, hear, and experience the voice of the customers from their perspectives.
Think about a safari trip. Instead of presenting photos of lions in a meeting room and educate people about them, a safari guide brings people to the subjects’ natural habitats, provides guidance on what to observe, sparks their curiosity, and enables moments that build empathy.
Through this kind of immersion and participation, the product team can internalize research findings more easily. It saves time persuading the team of the importance of user needs via elaborated reports. The team can share what they saw and learned directly, then talk about action steps without having to wait for the full report.
Those are my two cents after eight years in the research field. This should be an on going discussion and there a lot of great thoughts already from other researchers, such as:
The Future of UX Research by Monty Hammontree
How to Stop UX Research being a Blocker by Ben Ralph
What next, UX? by Jay Hasbrouck
What else do you think researchers should do?
