UX Research from 0 to 1

Nadine Piecha at UXDX Community: Europe South. Video: https://youtu.be/3vrU-NmF_rA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and why research is worth the cost

[00:00:00] This is Nadine talking. I'm a German living in Spain, I'm a researcher, and I'll be talking to you today about UX research from zero to one. That means the process of setting up research in your organization. That doesn't mean the talk is only interesting for researchers. You might be a designer, you might be a PO or an engineer or anyone else who works in product, and you want to get research set up as part of your process in the company. I hope that will be interesting for you, and that I have some good advice and some tips and tricks to share with you today.

[00:00:33] I'm a fan of quotes, so that's my quote of the day: the price of the light is less than the cost of the darkness. I feel that really relates to the work I'm doing. There are quite often objections like research takes too much time or it's too costly. But if you look at the flip side, if you don't do research, that might take more time, or you might lose more time or waste more money by building a product that in the end no one loves and no one uses. So I really feel like doing research is a little bit of an investment, but less of an investment than not doing any research.

[00:01:09] Typically, when I start in an organization, at least someone already understood that; that's why they are hiring me as a UX researcher. But that doesn't mean there are no obstacles or no objections that I still hear. That doesn't mean the whole team is already brought in and already understands how research works, what research can bring to the table, and what impact research can have for product teams. So there's still a lot of work for me to do, and that's what I'm going to share with you today.

My background as often the first researcher

[00:01:39] Just a brief overview of myself, a little bit of my background, so you understand why I'm talking about what I'm talking about today. I'm a psychologist. I studied psychology in Germany, and after that I started in a consultancy called eye square. That was my first job, and there I soon became the key account for one of their biggest clients, that's eBay, a company probably every one of you knows. I worked as a UX researcher for eBay for a while, until I decided to move south. Now I'm living in sunny Spain; I don't know if you can see me sweating already. I'm enjoying the sun in Spain.

[00:02:18] I moved to a job at eDreams ODIGEO. eDreams ODIGEO is the biggest online travel agency in Europe, and I worked there for a while as the first, and for a while also the only, UX researcher in the product team. Then over the years I started building up a team, hiring more people, establishing processes, and working very closely together with product teams, product owners, product managers, engineers and copywriters.

[00:02:52] After about four or five years in that company I moved on to NetSuite Oracle. Obviously NetSuite Oracle had researchers before; there's a great team of researchers with a lot of experience. But I was hired for a team that had about 20 product squads, these cross-functional teams, and I was the only researcher for that team. So it still felt like starting in a company as the only researcher, even though I had great research colleagues in other teams in NetSuite.

[00:03:26] From NetSuite I moved to a startup, Badi. There again I was the first researcher, working with product teams, with designers, with UX writers in that startup. That's a Spanish startup connecting people that are looking for a room in a shared flat with people that are renting out their rooms in shared flats, so I was doing interviews and surveys with those people. Most recently I switched jobs again and started at Beat. Beat is a ride-hailing company. It's a Greek company actually, but operating in South America, so again the Spanish-speaking market. They do more or less what Uber or Cabify or maybe FREENOW are doing: connecting drivers with people that need to get from A to B.

[00:04:17] That's a little bit of my background, and what you could probably hear already from the last few stations in my career is that I've often been the first researcher. That's why I decided to share a little bit of that experience, and share a bit of what has worked for me.

Listen and adjust

[00:04:34] Those are the four topics I wanted to talk to you about. The first tip, as a researcher, doesn't sound very surprising: listen and adjust. Really talk to people and listen and see where you landed, because every organization is very different and there's no such thing as one size fits all. After my four or five years at eDreams I felt like, okay, I've worked for eBay, I've worked for eDreams, now I've got it figured out. Now I know what research is and what a researcher has to do.

[00:05:08] I moved to NetSuite and the whole situation was different. I found myself in a B2B context. I found myself in a company where a lot of people already do research without calling it research. There were sales agents, there were product managers talking to customers on a regular basis, trying to understand requirements, trying to come up with feature ideas from there. It was a whole different context, a whole different scenario where I found myself. And then yet again, when I went to the startup, I thought, now I got it, now I know what to do. And again the whole scenario was different: the needs, the pace, the dynamics were very different.

[00:05:46] So I'd really recommend to always start from where exactly the company is. Figure out how much your colleagues already know about different aspects of research. Who are the fans, who are your supporters? What are the objections, what are the doubts that maybe other people have? Will you hear things like research takes too long or research is too pricey? Or will you hear something about the methodologies itself, like we don't believe what five people say? There are all these different kinds of objections. You need to listen carefully, and then in every conversation, every project, every chat or discussion, you can address those very specific issues or doubts.

[00:06:29] It's also very important to really understand well from the beginning who in that company is already doing research. Obviously I'm hired as a UX researcher, I will be one doing research, but I'm never the only one. When I start in a company there are most likely already data analysts, data scientists, product analysts. There's a customer insights team or customer experience team, there are market researchers in other teams, and also POs, designers, sales experts, product ops people. All of them are probably doing research in one way or another. Some of them are doing user research: talking to people, or sending surveys, or analyzing app reviews or any sort of data that we have from users that we can get insights from.

[00:07:16] So it's really important that we understand that from the very beginning: who's there, who's doing what, with whom do I have to collaborate, and who can I involve in my projects. On the right-hand side of that chart you see a little bit of an abstract overview of how I'm used to working. In the past few companies there were always product teams, squads, with POs, with engineers, with designers. I'm very used to working also with UX writers, and then hopefully one or several UX researchers. And then in the green bubbles at the bottom you see all the other teams and disciplines that are very much overlapping, or collaborating with me as a researcher.

Involve and co-create

[00:08:02] Once we've listened and adjusted and understood where we landed and what our challenges will be, I would say involve and co-create with your colleagues. By that I mean, obviously and not surprising for anyone probably, collaborate in every project work. Involve your colleagues, the stakeholders, in kickoff sessions, in the preparation of any project, and in understanding what you're asked to do or what the team really needs. Involve them along the way when conducting research, or when sharing results and discussing the recommendations or the insights.

[00:08:39] But I don't just mean collaborating in project work. I also mean collaboration beyond the projects: assessing the business needs together, understanding where you are expected to have the biggest impact with research, assessing together what the priorities are, what the biggest projects are, where we have urgencies, and then also setting up goals for research overall. That's not something I want to do in my black box and then come back and say, I think this is the ultimate solution for our company. I want to do that together with colleagues, understanding what your needs are, what your expectations are, where you feel research works already in your organization and where you feel we need to improve.

[00:09:23] As an example, when I started at Badi there was no one, no UX researcher, but there was a strong customer support team, or customer experience team. They had regular conversations with users as well, they sent surveys. So there was a part that was already working: that was the feedback on the live product. There was a part that was not covered at all: that was the feedback on new ideas or designs. So depending on what's already there and what's already working, the situation might be quite different.

[00:09:53] Then with the teams I craft a plan, something as easy as this style: three steps. We start generating impact with the first projects. Then in phase two we focus on getting things more efficient and effective, establishing processes, and maybe teaching other colleagues to get things done faster or on a bigger scale. And then maybe step three could be to advance and add new methodologies. But that really depends on the context. Right now I started at Beat, and there's already a team of researchers that is doing a lot of research. They are part of the local teams, so there are researchers in Latin America, and they are using some methodologies: very sophisticated surveys, they are doing focus groups. But again, there are other parts of research, or specific conversations with the product teams, that don't happen yet. So my focus, and what I will develop in that company, will be quite different.

Choose the right first projects

[00:10:50] Once we've understood where we landed and we involved everyone in planning, we need to start working. We need to get some projects really done and deliver some insights and have impact. So it's really important to choose the right first projects to work on. I call it here project number one, but in reality I mean the first few projects that everyone will see from you. My recommendation would be to go small, go step by step, and show that research can have impact fast.

[00:11:26] As a first recommendation I listed here: involve research champions. What do I mean by that? I mean involve the people that maybe you noticed know about research, know about the value of research, maybe have ideas on what to conduct and how to conduct it. They will be the ones helping you spread the word and spread the insights and the results, and make sure that your insights will actually have an impact.

[00:11:51] Choose an easy and easily repeatable method. By that I mean don't go too big from the beginning. I wouldn't do a diary study with a very specific tool, setting up something that takes months to be set up and to have an impact. Go for something small, like a round of interviews with six to ten people, or a usability test, or something that doesn't take forever, and that you can go back very soon to the team and say: these are the results, and this is why we need research. So you generate impact fast.

[00:12:27] On the right-hand side you can see a mobile screen, for example, of a recent usability test. We tested a flow of an ID verification process, and we got some very obvious insights. The text underneath the headline was actually important to complete the flow successfully, but it wasn't really visible. That was something very easy to show with the users using the prototype, and it was something where we could share short-term actionable results. It was as easy as telling the designer, let's look for another solution. We tested another solution again, that worked better, and we saved a lot of time for the developers developing something that ultimately will not work.

[00:13:09] And then last but not least, I listed here clear recommendations. Especially in the first projects I think that's very important: that we don't just share insights, but that we also help the teams understand what to do with the insights. So we learn the text wasn't visible, but we also go one step further and help designers or product managers with what we can do about it. What does it mean that it wasn't visible to users? How do we address that now?

[00:13:38] When I say choose a smaller project in the beginning, something that generates impact fast, I don't need to park the rest forever. What has worked for me at least is building the longer-term projects already in a parallel track, establishing a base for building empathy later on. On the computer screen on the right-hand side you see an image of a persona. I created personas at Badi, but that wasn't my first challenge. That wasn't the first promise I made, that we will have personas and all the teams will work with personas. It was rather something that I started building in a parallel track. While I kept interviewing and I kept doing surveys, I got this idea of what different types of personas we might have, and at some point I focused more on getting the personas done. The same with customer journeys: don't go in from the beginning and promise you'll get it all, that you will understand the whole journey and all the pain points and all the insights and all the customer needs along the journey. But that is something that you can set up from the beginning, and then you can fill it along the way.

Passion is contagious

[00:14:46] And then last but not least, maybe the most important, and the one I like most: passion is contagious. I'm a researcher at heart. I really love what I do, I really find my job interesting and fulfilling, and I really find it exciting when I talk to people and I find something and I share that with people. I feel that if you share, if you involve them, if you share how exciting it is what you found, how interesting, how impactful that one insight might be, or how surprised you were by something that a user told you today, I really think that's contagious. That increases your chances that others are listening to you and that you will also have an impact.

[00:15:23] So I would say involve your stakeholders along the way by sharing your progress, by sharing anecdotes, by sharing videos, sharing quotes, or asking them "did you know?" and then whatever you heard from the customer. That makes everyone a bit more interested and a bit more excited. At Badi, for example, I created a Slack channel that was called Popcorn Time, and in there I just shared funny stories, or interesting insights, or something that I heard from a user today. I kept getting some traction in there, and questions, and I could see how the interest in user research was increasing.

[00:16:04] The next section here is present engaging reports. By reports I don't mean it always has to be a PowerPoint presentation. I mean whatever material you want to share, be it a video, be it a PowerPoint presentation, be it a Miro board or whatever tool you choose, but make sure you share it in an engaging way. You have people in the room that might not know what research is, or that might have their objections, or might feel like, I'm wasting my time here. So you really want to get them on board.

[00:16:34] I would recommend to share stories, not just data, and really focus on the empathy part as well, that the users are human. So show them with photos, use quotes, use video clips. And most important, also focus on what really matters. Don't share everything you know, but share the key insights that you want teams to remember. Don't go and present two or three hours of all the insights and everything that you considered interesting, but focus, and give people as much as they can consume and actually work on.

[00:17:12] What has also worked well for me is including interactive parts like quizzes or tasks or small little activities. What works well in terms of user research is that you ask in the beginning: what do you think people would have answered to that question? And then you make your audience realize that they don't know. Sometimes they feel after reports like, oh, that was all very obvious, I knew what they would have said. But if you ask them up front, they realize that they are not that sure, and that what you are going to share is actually insightful and interesting. What I also did is a quiz about the personas, for example, where I even told the team I'd send the winner a German mulled wine. So you got everyone a bit more excited, and it was more of a fun activity rather than, I'm asking you facts about our personas.

[00:18:02] And then last but not least: support with acting upon the research. If you have teams that never worked with UX researchers before, they might not really know what to do with the personas, for example, or with the insights that you share. They consume it, they understand it, they go back to their daily work. If you really want to have an impact and you want to see them acting upon your research, implementing things, ideating on your research findings, you probably have to help a little bit with that. So plan time for discussions, either when you share the report or afterwards, or plan for ideation sessions. Guide them through how to work with user research insights.

Summary

[00:18:49] That's the summary of what I shared with you today. Those are just some things that work for me; maybe some of you have other ideas or other advice to share. Those were the four most important tips or tricks I wanted to share with you, because they worked for me in the past. Listen and adjust: don't work by the book. There's no one size fits all, there's no one correct way where the other one is wrong, but figure out where you are, what the company really needs, what your team needs, and where they stand at the moment.

[00:19:20] The second advice would be to involve and co-create, both on a project level but also on a higher level: what am I expected to do here as a researcher, or what do we feel is missing in terms of research in our company? Then third, choose impactful projects for the very beginning. Choose the smaller ones, go step by step. Try to make sure you can very quickly show that research can have very relevant insights and can have an impact and help us all save money and failures. And last but not least, passion is contagious. If you are excited and you share it and you engage everyone, your chances will increase that people are listening to you and that they are acting on your insights.

[00:20:06] That was everything from me that I wanted to share. If at any point you have doubts, questions or comments, I'll be happy to hear from you.