top of page

hmw

How might we overcome the problem of UX teams not having time to do research?

Context
Wallapop had changed management and ways of working. The product design team had to transition from being executors to strategic thinkers. A key resource and value that we could bring to the product development was research. It was crucial for such a rapid-growing company with so many users to listen to their needs, to pay attention to trends and to stop being followers. The problem was that there was not a research culture and as shown during a product design annual team retro, there was never time or resources to do research.

IDENTIFYING THE PROBLEM

One other member of the design team and myself took on this challenge willingly. We were thrilled to find ways to improve the way we did research in our organisation. Our plan was to first understand the culture and the root causes of the problem. Was it lack of resources, was it lack of experience? Was it more of a mental barrier? 

We started with key interviews of decision makers (CPO, Head of Product design, Head of analytics). We then moved on to do some workshops with the teams, separating product design from product management, to gauge how large of a gap of knowledge there was.

 

We focused out attention on: What do people understand is (the value) of research? What blockers do we face, what do we wish we did better and how are different roles meant to participate in research. 

No common ground

Different roles saw research as different things. At times these opinions were complementary - research can be both AB testing and exploratory interviews. But often times the perception at a fundamental level was different. While product designers saw it an enlightening, some product managers believed it was confusing and cumbersome.

One thing became clear as well, the need for research was in the mind of product analysts and product designers alike, and most roles believed it was up to the product design team to educate others on the value of research. So we took on this duty.

skillshare sessions

We first shared the results and discussed with the team at large. It was important to us to set realistic expectations. We then set up recurring skillshare sessions, starting with introductory education on what is research, how is it valuable, when is it valuable. We encouraged as well the product analytics team to take on after us and continue with their own skillshare sessions. Together we started the campaign to promote and democratise access to data & insights.

Learn by playing

After each session we gathered some feedback and realised the theory was sinking in but the least research-savvy members of the team felt overwhelmed by the idea of choosing which research to do. As experience designers we thought of the best way to get people engaged: to bring them together to compete. The environment of a game also allowed everyone to take risks, to put into practice what they had learned without troubling consequences. 

So we ideated a board game:

Each team was a ride-share (or similar) company. They did not know anything about their rival teams. They were competing however for the same user base. 

Each team was given a challenge, a budget and a time frame. The team to manage to reach their objective (after launching a successful service) won. The caveat was, that research takes time and costs money, so they had to do so before running out of resources.

By providing them a "research menu" they were able to order in some way which studies to do based on time and price. In return they would receive cards from us facilitating which matched the effort of their research plan. They soon discovered that some of the most cost effective studies were not the ones to bring in the richest of insights or data. 

We also tested how much attention they were paying in the previously dictated skillshare sessions. We expected teams to remember that they needed a research brief before jumping in and doing studies. The teams that did so gained clear advantage in the race. 

Lastly, to help them understand the value of ownership and collaboration, each person of the team was assigned a role (different to the one they actually played in the company) and thanks to this role they were able to have ownership over certain decisions and processes. 

Complemtary work & results

The exercise was a raving success. People learned to appreciate research, they felt empowered and more knowledgeable after applying some of the theory and they understood what to expect from each other. 

Of course mindset isn't all, so we complemented this effort with the procurement of new research tools after analysing our needs as a team and the cost of each. We also made a promise to share research demos with the product team and company at large, not always waiting for a finished product to show and brag. 

The results: night and day. The team after one year was completely immersed in the research mindset, PAs, PDs  and PMs of a team had weekly meetings to discuss research projects, both for evaluative and exploratory research. And even some of the PMs decided to use their learning budget to get accreditation and learn fro courses about user research and interviewing. 

my takeaways

We originally had called this initiative the "Care-bear" project which came to become my nickname in the team. The reason for this naming is that at the core of this effort we wanted to know enough about our users to actively care about them.

I think this guiding vision is something I carry with me since and have stopped taking for granted. Being good at your job does not mean you care, and as a manager I try and share this with my team: you have to design like you care and you have to build caring products by design.

bottom of page