How we made user research impactful element of product development
The setup of a Research team in product development can be organised in different ways: a centralised team working in an agency style, a team divided into several product teams or a mix of both. But how to start it?
I will show you the journey that Research went through at Docplanner. We can experiment with the product a lot to build the best tool for our users, but also play with the way we work — to find the perfect setup for us. Let’s take a look at how Research has started and how it became an essential part of our agile environment. What did we do to show the value of the research and build trust in it? What did we do to make others see the bigger picture about our users with all the puzzles: their goals, needs, patterns and all “whys” behind?
Let’s go back to the beginning
For me, a researcher, it was clear from my first days in Docplanner: we definitely needed more research. At that time, every product team worked with a UX designer who was also doing the research part. Vision and actions emerged from sprint to sprint, based on the prepared backlog of ideas. What was the research like at that time, two years ago? And what has changed till today?
1. Evaluatory/tactical research — testing existing assumptions as quick wins in showing the research value
As a starting point, we focused on smaller actions — we were challenging existing development ideas and testing/verifying some assumptions and solutions that were already waiting in our team’s idea banks. We were using mostly tactical research methods like usability studies, surveys, tactical interviews with our users. All to understand if team ideas and assumptions were valid. This was the first important step because it showed how impactful research could be, sometimes helping to discard some of the ideas at an early stage.
At the same time, some new hypotheses to think about came after conversations with users. But it wasn’t enough. We were testing most of the existing ideas without the whole user journey context, without knowing the real needs and patterns of our users. We wanted to show how discovery methods and the bigger picture can help to build a better product.
We knew most of the backlog ideas were based on intuition, business cases, random research, surveys, benchmarks etc. And we didn’t know how it fitted to real user journeys. So we started talking with our users and observing their actions — despite the backlog of ideas and existing hypothesis, no matter how amazing we all thought those ideas were.
2. Starting with discovery research — let’s meet our users, get to know them better and understand what is important for them
We added a new element to daily tactical actions we used to do from sprint to sprint. In an arranged space every month, we had one week of sessions with users to understand their needs beyond any specific hypothesis. It was the moment when we started to know and understand them better as well as to spot clear patterns in their behaviours.
3. Understanding the whole context of the user journey — from the user perspective, not from your product team’s perspective
At that time, product teams were focused on specific parts of our product — and only partially on the user journey. Researchers embedded in the product teams were investigating only parts of the journey too. We didn’t know if the “puzzles of knowledge” shared between teams matched.
So during new monthly sessions, we started to cross these artificial boundaries and put attention to the whole user journey, not only to the small part that was drawing our team’s attention most.
We started to take into account the whole context — all product flows from the users’ perspective and their broader experience outside of our system. We used to do tactical research mixed with discovery / generative one. That showed us how our users behave apart from our artificial boundaries through the whole process — not only the small part of it. The puzzles finally started to form a bigger picture.
As an example from the patient side — we wanted to understand the process of searching for a doctor, with all different use cases, contexts, conditions and needs. Finding the most important criteria from various perspectives made us understand how much more we can do with our product to help the users. Discovery interviews and usability sessions during the whole process revealed important gaps in our flow, so the product teams could start to work on the best solutions to fix them. What amazed me most that time: we started collaboration based on the users’ journeys, between different teams and apart from their specific idea banks or tasks already waiting in their backlogs.
4. Engaging others — make them part of the research and the ideation process
The next point was: how to engage more people from our company, so they could understand the importance of research and become thirsty for more insights on the topic? How to build trust and visibility of the research?
We started with inviting more people to interview sessions (all of them — product managers, designers, analysts, devs, even people not related strictly with the product development process). We wanted to make them empathise more with real users, to show that there are more scenarios, more needs than they know from their perspective. Finding out about real users, seeing them “in action” was a real ice breaker in the “empathy-building” phase. Before, this question appeared a lot: “how many users said/did that?” But being there, seeing real users in action, built more trust in the qualitative research. This way qualitative insights started to be more important in a data-driven company.
Then we started sharing empathy to users among other team’s members in a more creative way. How? Every series of research sessions ended up with workshops, where more people got to work with the findings about our users. It helped to understand users’ journeys through healthcare (not only through our service), working with their stories and thinking about solutions to specific user problems and needs. That was a fantastic experience to see how participants (not related to research and design) started to think about ideal solutions with the user in mind.
Around that time, a wider audience started to see the value of research, and also share the research questions to investigate outside of product teams.
5. Experimenting with our research process — change from tactical to strategic research
That’s why we decided to change the way we were working as a Research Team at that time. After a year of doing research for the product teams, we decided to separate a bit from them. We focused on more strategic topics essential for new decisions, more significant changes, new directions or pivots. Since then, researchers have been working independently of the product teams, investigating broader topics. On the one side — it was an incredible adventure and challenge but we were all alone, without engaged people around, on the other. Product teams were doing their work, but now without a researcher on a daily basis. We still were helping them but in a more centralised way — mostly in fast tactical/evaluatory research, but not as much as it used to be.
At the end of the first quarter of operating this way, we had some interesting findings, but no one could work with them at that time, because it wasn’t in any scope. These puzzles were part of new pictures and didn’t match with any existing ones. So we all felt like our work wasn’t impactful as much as we all thought it would be — despite us working on strategic topics, doing mostly discovery research. We knew that it was impactful for some decisions, but went to the parking lot, waiting for the right moment and the right team. At the same time, product teams missed researchers a lot in their daily work. They had already learned how impactful research could be. Even though they started doing smaller research on their own, continually empathising with the users, they missed a closer collaboration, and so did we. So finally we decided to change again.
6. Building the perfect set up — a mix of strategic and tactical research, mostly for the product teams purposes (but not only)
Researchers came back to product teams, but with one significant change. Now our primary goal is to do more discovery research for specific team’s questions. Our role in the team is to help make the right decisions also on a higher level, not only a tactical one. How does this work? We start every quarter with a set of more discovery research questions prepared with a Product Manager from a specific team. Questions aren’t about the current scope only — they also bring knowledge and impact future decisions. We put a lot of effort into the proper propagation of research goals to more people with different perspectives, to bring value not only to one team but to the whole company.
We love to work with this approach — it makes much more impact and helps to see the bigger picture super clearly. It empowers our Product Managers and their teams to make good decisions and build the right solutions. But we didn’t give up on tactical (evaluative) research — it still helps us to develop solutions in the right way and still forms part of the overall research process. With this setup, the majority of ideas in teams backlogs come from research insights now, but we continue being there to facilitate their evaluation.
But what about broader strategic research and the new puzzles? We still have 20% of our work time dedicated for more broad, strategic topics not related strictly to our product teams. These topics can come from different directions — head of product, operation teams like sales or customer experience but also from our investigation of gaps in the user journeys. Most of these goals should foment strategic decisions or help operations teams in their daily work. For now, this setup is best for us — we can see the impact of research insights on a daily basis. But we haven’t stopped with experimenting and we are constantly improving our research process.
