#67 Collaborating with UX researchers
47:04 Share

If you're operating in complex environments with complex products, B2B kind of technical products, it becomes impossible to design and research at the same time because research demands for more sophisticated efforts and methods and essentially the toolbox needs to be deeper. So that's when, as a designer, you might be able to do, let's say, the surface work and

of research quite well. But if you need to do deep work, like go in the details and go deep in the problem or in exploring that ecosystem of needs, of pain points, of how the product would be used or is used, then you would need specialized help. ♪

Hello, everybody, and welcome on the next episode of Onyx UX Talks. My name is Anvisa, and I'm joined today by my lovely co-host, Ioana. Today, we're going to tackle the topic, how to collaborate with UX researchers. And that's the topic that we wanted to naturally progress and advance since recently we had an episode about the UX research. I think it's just natural that we kind of want to talk a little bit more about how do we collaborate with our partners in the project? How do we get insights? Who's responsible for what? Why designers do or do not do research?

There is a lot of questions up there. So let's go through them one by one. But before we do that, I would also like to mention that we have a sponsor of our podcast, which is Figura Digital. And this is a platform for anyone who wants to find perfect client match.

So imagine you have a perfect company or perfect, let's say, project or even industry you want to work in. You have some experience, most likely, in design. You know what you're worth. And you can find that perfect match without going through multiple application processes, multiple arrangements, multiple client interviews and stuff like that. You just go through the process once and the platform will match you with the perfect client.

client for you. So that's a vetted process. All the clients are high tier, very good budgets. Also, what's important to mention that this platform particularly is focused on designers. It's managed by designers. The application process is very focused on design, as well as you're getting access to a community. You're having resources for the growths, for helping each other. It's a

for you, but also you have an access to community and help and resources for the growth. Definitely a win-win for both the clients and for you. And obviously a nice payment on top of that is a great benefit as well. So make sure to check out DeFigura the digital if you're interested in freelancing. And other than that, that is it on our site. Thank you so much again, Figura, for supporting our podcast. Now, also before we dive into the topic, I wanted to ask how you're doing, Ioana. How was your last week?

Hi everyone and welcome to a new episode. Happy to be here with you. Actually, now I think I have some sort of addiction to our weekly chats because they really feel like I'm looking forward to this moment. We're always recording on Sundays and it really helps me reflect on what happened for the previous week and also like every design topic we discuss. So it's pretty addictive in a positive note.

So my past week was exciting because for the past year, I've been consulting and helping and sort of supporting Romanian startup with building their design foundation and making design decisions. And sometimes I facilitate design decisions for them and I ask them meaningful questions and guide them and help them find their way with their product.

And they officially launched last week and it was everywhere in the news. And I'm also mentioned as a founder because I've been with them from the very beginning and part of this journey. So it was very exciting to see the light of day. It's called Good Legal.

It's a product in the legal tech space and everyone who has anything to do in their work in regards to legal and managing documents and managing workflows, legal workflows and so on. I would recommend checking out this product because I essentially helped build it.

And that was very exciting. And also in my full-time role, as everyone already knows, if you've listened to the previous recent episodes, I'm very excited about the product I work on. I think it's a very exciting challenge to embed, let's say, the new AI capabilities for improving our work processes in the everyday life of our users. So that's very exciting. That's a huge opportunity and I'm very passionate about it.

Right now, I feel like I'm in a point in my life where I get to do design work that I'm very, very excited about. And I think that's a privilege. So I'm very happy for that. Yay, more design work for me. That's what actually made me a bit quieter on social media, because right now I'm in a mental space where I just want to do design work and be very focused and do, let's say, focused work. And so I've been defocused from my social media stuff. So if anyone has noticed that,

It's because I'm doing a lot of work designing these days. So that's it in a nutshell. How have you been, Anfi? I totally understand you with this mindset because I actually have been in the same state for at least a couple of months now. Actually, since starting the new job, I was still like trying to be active in social media. And then since summer, maybe like midsummer, I kind of couldn't find energy for social media. And I honestly, for multiple reasons, actually, but I stopped also posting and I'm really not active there. Business with feelings.

But it's something I had to do to at least help myself going through this year. And other than that, I've been doing pretty well. Actually, next week will be very exciting because again, I'm going to travel with my company. I think two weeks ago, I was traveling to Amsterdam. I mentioned it briefly for the field trip.

And tomorrow I'm going to Stockholm and we are going to do the hackathon with one of our biggest clients, Nordic Choice Hotels. We're going to do the innovation hackathon. We have some cool ideas, really exciting stuff. I'm not sure how much we'll be able to build, but we are super excited. It's like this innovation space where it's not really a part of the official objective in your company, some serious thing, a lot of collaboration, all that. No, it's just really hackathon, cool stuff, team of five people hacking things off. This is something I'm crazy about.

craving usually in any design project. And this is a great opportunity. Plus, you get to travel. So it's always nice. So I'm definitely excited about that one. Other than that, it was a good week, actually, on my side, because I've been preparing the design thinking workshop that I'm running again today, a bit later, like literally a few hours after we record this podcast. It's going to be particularly focused on the whiteboard challenge. And plus, I didn't mention it for a while, actually, but I'm doing the home renovation for the last...

almost two and a half, three months or something. And it's been a crazy journey. Honestly, it's a crazy journey. I don't think I've ever had such an intense design project in my life so far because we have a very, very strict deadline. We must finish until December 19th. Otherwise we'll be kicked out.

of our current home and we will have no place to stay when we have lots of luggages since, you know, we have five years of life here. And so we need to have our home ready, at least in a way that, you know, you can live there. There is a water, there is a heating and there is a kitchen. Yeah, it's been going really crazy because the timeline is super tough. And every single day, it's like a domino effect. If you don't manage one thing, the rest will not take place. And then at the end, you will not have either heating or I don't know, the water or your...

toilet or whatever. So every day is like the last day and you must manage a lot of things and must make like 100 decisions a day. It's a very, very intense project. So I'm looking forward already to the end of it. It's getting more and more scary, but we will see how it goes. Definitely will report back on that. So yeah, that is it on my side. I think we are good to go with the

podcast episode today, right? To remind everyone, the topic of today's episode is how do we collaborate with the researchers? I think we talked a little bit about the research, when we run research, in which context we run research in one of the previous episodes to make sure to check it out if you haven't. Today, we want to focus on actually collaboration part of it. And I would actually want to start our conversation by asking you, Joanna, what is your favorite

Why in general do we even have researchers? Why not designers do the research? In some companies, we know there are research role and in some companies there is no research role. Sometimes you're actually wearing all the hats and doing the research yourself. So why and in which part of the company development you need to start having researchers and why designer cannot handle it?

So it's a very interesting question, and I think it's the first time I think about it. I hope that my answer will make sense. So essentially, I feel that it depends on a couple of things, right? So on one hand, different companies have different levels of complexity when it comes to their research needs and different stages of the design process or of the, let's say, product maturity, product journey.

demand for different needs. So that's one thing. And also, I feel that the scale of products is sort of different. So if you're building an app that is essentially doing this, solving one problem, it's a one trick pony, you as a designer could probably do the research yourself. But if you're operating in complex environments with

complex products, I don't know, B2B kind of technical products, things that are very complicated, it becomes impossible to design and research at the same time, because research demands for more sophisticated efforts and methods. And essentially, the toolbox needs to be deeper. So that's when, as a designer, you might be able to do, let's say, the surface work of

of research quite well. But if you need to do deep work, like go in the details and go deep in the problem or in exploring that ecosystem of needs, of pain points, of how the product would be used or is used, then you would need some, let's say, specialized help.

Or if you are to do it yourself, that's everything you're going to be doing because it's a full time job. So you shouldn't be asked to do deep research work and also design work at the same time because there aren't enough hours in the day for that. Yeah. And also there are cycles, let's say. Sometimes the stage in which a product is in doesn't require so much research, although you could argue that research is always needed. So you could run continuous research. You should run continuous research throughout the life of a product.

But sometimes the risks that you need to de-risk through research, the de-risking that your design decisions need through research is much bigger, more important than at other times when you can just say, I'm going to own this risk. I'm just moving forward.

a button from left to right. I'm going to own whatever comes out of that because it's not such a risky decision, right? This kind of risk shifts, evolves over the life of a product. And sometimes it's essential that you do deep research. Other times you could just make your best bet and own the outcome if that's a bad decision. So a very long intro, a bit abstract, I think.

To make it easier to grasp, I feel that designers should have time to design. And if there's a lot of research that needs to be done, it's a role in itself. And somebody who's trained in research will definitely do a much better job with those tasks. I think that's essentially it.

What are your thoughts around it? I agree with you with the fact that when the product company is growing, scaling, when you have more and more people joining, more in-depth responsibilities building up, more like pillars building up, maybe even specialties in a way. So you kind of like when the company is young, but let's put it in a more like organized way, right?

To my understanding, when the company is younger, not enough UX mature, first years, they're figuring itself out on a market from zero to one, looking for their client base, still building up like a core feature set, value proposition on the market. There, you often need more like generalist designers who can quickly adjust and be super agile in their process, right? Quickly building things, quickly researching things, quickly pivoting things. And this is when you need like the generalist designer.

And as soon as the company figures itself out and sort of has speciality, has its place on the market and has a strong value proposition, everybody knows you for something specific and strongly good for something. In that case, you need to start building a depth.

And very often in these companies, especially on the scaling stage, like a scale up, usually they are called. When you're not a startup anymore, you have funding, you have recurring revenue, but now you're building like the, let's say excellence of the product or expanding on the market. There it's where you start needing people with like a depth knowledge or expertise. Oftentimes it will be like very experienced designers. You need like a research team. You need people working maybe on service design, maybe speciality designers like visual designers or,

information architecture designers and whatnot. And this is when, again, it's more going in-depth rather than being general in terms of the resources as the company. I could see a lot of companies start scaling up and attracting or building their research team as they figure themselves out on the market and as the depth of understanding responsibilities is growing.

I think that also the reason or another demand for the research, or I guess the responsibility of the research team is also to scale up the research as a notion or as a process across the whole company. So for me, to my understanding, part of the responsibilities for the research team is to evangelize the research as the core part of the design process, make sure everybody's having the resources, the tools, the knowledge, the information, the processes, maybe calling it also a research ops process.

research operations, making sure that all the stakeholders are aware about it. And so not only like running specifically, let's say just moderated research, and that's it, qualitative research, but to also building it as a part of the culture. And I think it's a very important part, not just to, you know, have a very mature, not mature, but like, let's say, company that is established in the market. And then, oh, you know, we don't have research, let's just put some people into that. And then the company is already huge. And it's never been a pillar for the

company. Just, you know, for a company, I don't know, let's say 1,000 people, you know, hiring two researchers will not make it easy to change the culture. So I think it's very essential, important for like companies, as soon as it's like scaling, investing in the research, so this becomes a part of the process and the culture, and the company is basically prioritizing a human-centered approach, if you wish. So that's how I kind of see it. And that, of course, for me means that the responsibilities of the research teams will not be only to

run the research and help designers on the high level, but to also evangelize the process, evangelize the culture. So let's say we establish our understanding of why the research team usually takes place in the company. Now, I wonder, let's talk about your experience maybe on how did in the past you usually collaborated with researchers, right? We often know that in the beginning, when the research team is new, you have much more designers than researchers.

And so let's imagine you have a team of 10 designers, two researchers. How would we collaborate with them? How would we use these shared resources? How do we pick them for different projects? What was your experience in the past?

Well, I would much rather talk about my experience in the present because it's very fresh. It's ongoing. I'm currently working with a very, very senior UX researcher, and he's essentially been doing research from before I was even born, which for me is on one hand intimidating and on the other hand, extremely exciting because I get to work with this very, very seasoned professional and that really understands how to do deep work.

And so it's just a pleasure to work with him. Hi, George. I hope you're listening that I'm making you a public compliment right now. But so it's great. The only issue is that I'm based in Bucharest, so Eastern Europe, and he's based in Seattle. So we have a 10 hour time zone difference, which on one hand, you could think it makes collaboration harder. But I think it's great that we both can do focused work during the times that don't overlap and then meet when the time sort of overlaps for three, four hours and my evening and his morning. Getting back to the

process itself. I would say that generally speaking, and this is also my experience right now, the collaboration should sit somewhere along these lines. The UX designer has to figure out what we need to find out, what they want to find out, and then it's the researcher's job to decide what's the plan for finding that thing out.

Of course, the reality is that in our case, we decide together what we need to find out. He's the one that's leading the research process, but I also get involved in it sometimes. So I go through the, we're using user testing. So we're doing a lot of both moderated and unmoderated studies. So I'm going through the unmoderated studies myself to see what comes out of them. So I'm also involved in the process, but he's leading it. And then I lead the design decisions that we're making based on the research.

So if you want to envision it as a process, I would say it's something like, hey, I need to find out how people feel about this particular point in our product. And then it's his job, his responsibility. He decides what are the best methods, what's the best plan for finding out whatever I say we need to find out. And then after we kind of elicit that feedback, elicit the responses we're looking for, then I'm the one who should make the design decision based on that.

The truth is that he's also contributing a lot to design decisions and he's also contributing to understanding what we need to find out. So ideally, the collaboration is in a way ongoing, but each of the parts own a part of the process. So I own design decisions and he owns everything research.

but we're in this together in a way. And I think it's great. I think we managed to still move very quickly, even though we have to permanently align. So that's not slowing us down at all, or it might be slowing us down, but to a very good reward. So that's it, a very high level. In the past, I'm trying to remember...

I've worked with him as well on a different project in UiPath a couple of years ago. But before that, we only had like market research. For example, in ING Bank, where I worked before UiPath, we were doing research, but it was more commercial. So it wasn't so focused on UX. We were touching on some points regarding usability, regarding the overall experience that people have with our digital products. But mostly it was more like, are you happy with ING? Yeah.

kind of thing. So let's say NPS-ish kind of market research, right? Apart from that, I've been doing a lot of research myself, but that's for another episode. What has been your experience? Yeah, in a way, it's a similar experience. There were some nuances around how I collaborate with the research team, depending on the company. I mean, in the last three years, I've changed the company three times. Experience was quite different in each of those companies, if I reflect back. But I can remember that in one of the companies, the research was a

not as heavily embedded in the beginning of the project. Actually, I think the core of it would really depend on how the design team is structured, who report to who. Like there are typically two types of companies, especially in the product area. So one of the companies would have like an agency model where the design sits as like a group reporting to specific design manager or design director. And then there is this other model where it's like a

product squad model where designers sit under the product team. So you kind of work together with the product director, product PM, product tech leads and stuff like that. I think it would heavily depend really on how the company is structured, whether it's hierarchical, whether it's distributed. But three years ago, I was working in a company that was structurally

structured in a way where we would just work on the product and I would only know my product partners. And then there was this research team in the US, which I didn't see much often. Only let's say, like you said, Ioana, when you have information or the gaps you want to fill, or you have questions, you have the frame gaps you want to ask and get answers for, you would then require, I guess, the research. And I didn't even know who I'm going to have as a researcher. It would be just like whoever is available and have the time in their timeline would be just picking it up and

at the end, I would get a report. So it was not as collaboration, but we had some input and it was usually okay, good input. Like for example, I remember we were doing something like usability testing for the icons and we were not sure if the icons would be clear enough and stuff like that. So they would just send us reports for the card sorting, how the icons were perceived, which one worked out, which one had a poor comprehension.

In the next company I worked, the collaboration was much more design process centered. So it was really engaged from the beginning. From day one, we would have researchers, we would pair as researchers. As a product designer, I would be leading the collaboration with the team. I would be gaining like sort of alignment.

I would be trying to understand the challenge, the product space and stuff like that. So then I will be framing all those gaps. The researchers would very often be sitting in the same room with me from the get-go. They would be sometimes helping you even with the workshop. They would be helping me with framing the challenge. And they would be immediately right after, let's say, the kickoff workshop with the partners, framing the question. So it was very collaborative. They were always in the process. Honestly, as soon as you design, they already know what to test and they're like,

very involved in the detail part of it. So for me, it was, I didn't even have to prepare the research plan. At this point, so I'm working in a different company right now where the design is sort of in a hybrid model where we report to design squad kind of agency model. However, we work in the products. I'm reporting to design, but I'm working under the product. So it's a hybrid model. In this case, I'm actually doing a little bit less collaboration with the research team. They are a service team.

the shared research that we can ask for help or collaboration. In their turn, what they do mainly, they try to operationalize where research research, so they would take care mainly on the discovery stage of the process, and we would take care of the usability part of the process. So we would be doing the validation of the research, and they would be doing the discovery of the research. And so today, it's slightly different. I would be the one who's framing everything from the beginning and finding those gaps.

gaps. And then only if I feel like I don't have enough information and we didn't have like enough insight to this particular challenge, then I will be involving them a little bit later in the process. Once we have figured out some gaps, then I will be asking them to help me. They will be managing the structure of the research. So they will be actually running the qualitative research, preparing the plan for the research, the screening parts of it and stuff like that. They will be involving us only during the meetings. For example, you have a call

with the user and I would be invited to that call. I can make the notes. I can maybe make my own sort of assumptions based on it. Then at the end, I will share my insights or my, I guess, understanding or interpretation. For that, we use Dovetail, by the way. I would be sharing my part of it. They would have their parts of things. They have the videos. They will be reviewing them again and like,

deriving the insights. But at the end of the day, they will be the ones handling that discovery part of things. And they will be preparing the reports. And then they will be sharing the report with the whole team, not just with me as a designer, but literally with the whole product team who I was working on that project.

And oftentimes I would see them preparing some sort of mural boards with like journey stages they have figured, the insights, the pains they have figured. Very often they would sort of frame everything around the customer journeys. They would sometimes suggest the next steps, which is very nice. But sometimes I would just pick it up from there and say, let's do the prioritization metrics together with the team. And based on those insights, prioritize what we need to focus on.

So this is the part when we actually heavily collaborate or sort of work together, not really collaborating, but working together with a research team. What happens next is that we only have few researchers. So I think we have two researchers for a group of around 12 up to 15 product designers and different products. You know, it's a small ratio designer to researcher. Many times...

you would have to try to do your own research in whatever research is possible. We have like accessible dashboard or insight mapping in the dovetail. So you can do your research on existing information. If not, you will involve the research team. But at the end of the day, once you start using that information and start doing the design, discovery design and stuff like that, and then you're validating the design. Right now, my approach is that we are doing usability testing, very often unmoderated one. And for that

I think we discussed already tools in the previous episodes. I personally use and love using Usbury, where you really just connect your Figma prototype, set up a quick test, set up the metrics you want to derive and learn the behavior, and you analyze it very often. So at this point, my experience is usually, again, divided between the stages of the process. And not so much we're involving them because obviously they just can't afford having so many projects at the same time.

Sometimes you even have to really like make a case and prioritize why they should focus on this project and not the other one, which is a tricky thing, usually, especially if you don't have a huge design research team. I guess what I'm really curious to know more about your experience right now, Ivana, is once you're collaborating with the researchers, in what shape or in which form

forum do you usually get the information from them like maybe is there reporting is there I don't know workshops anything like that so how do you usually get information from the researchers as the output or outcome whatever is the form there great question in my case particularly I get insights firsthand in a meeting face-to-face nothing very formal I

we're not formalizing this because for us, it's an ongoing conversation. The PM is also very involved. So we just have these conversations. And so there's no need to formalize it with reports or things because we know immediately when we kind of feel that we're heading towards an insight or an interesting finding or we discuss them very often. But

I think it's a very interesting question around how you should typically socialize research findings, research insights in a company. So I think because I'm a designer, I don't need a formal artifact. I don't need the formal process of being handed over the research insight. But if I were to be, let's say, a business person or the VP or the CEO or someone who's not involved so heavily in the process, then we would need formalization.

other artifacts, other formats for communicating research and what we've learned. So I think that it all depends on the audience, like with anything that you present, or even if I want to get the design teams buy-in, sometimes we would create, of course, personas so the entire company understands who we're designing for, or you would create research presentations and so on. So it depends on what you're trying to achieve at any given moment in time. So maybe you're trying to get

buy-in maybe you're trying to convince people to invest more in that product maybe you want to convince people that there's a big problem with one of the products and it needs a redesign or whatever so depending on that you will choose different formats different structures in which to communicate what you're learning but in my case right now we're just talking a lot about it

And so we do have, of course, some structures where we document. Essentially, it's just confluence. We're documenting what we're learning, what we're discussing. I'm trying to be very well documented in this process. And it helps everyone feel that, okay, we're starting the meeting with this understanding. And then at the end of the meeting, we have

misunderstanding and we've discussed this, this. And so every time we meet, there's clarity around what we've learned through that conversation. I remember that when I was doing research myself, again, probably not the topic for our conversation, but I was creating a lot of, let's say, artifacts. You know, personas get a bad name and empathy maps sometimes get not such a bad name, but

still not a good name. But they're great instruments of showing people who don't have the design role, the archetype, right? That you're solving a problem for. So yeah, that's how it goes for me. What's your experience? What has been your experience?

I agree with you. I think it depends on each company. Again, our typical phrase. I think we should rename our podcast into It Depends. Maybe sometimes even more relevant name. I mean, it's still a conversation. It's an honest talk, but I'm thinking that we use the words It Depends too often. My experience with the artifacts as well was really different depending on the company culture and the UX maturity as well. So in some cases, it was just as simple as reports and then they would be just

somewhere stuck in the shelves and nobody will be able to access them. I think it's a very old school way of doing things. I could still see this happening a lot in some corporations, in the companies where the processes are just a little bit more rusty and longer and more bureaucratic. But I really hope that, you know, modern tools kind of

help making insights and making research more actionable and more useful for the teams. So in the next corporation I worked, it was also usually handled on the Jira level or like a Confluence level. It was very commonplace for many product teams to access information there. I personally was not a fan because I find it very hard to connect all the dots. And so today my favorite tool is Dovetail, where it's easy to sort of upload the video. There is automatic subtitles there. You can

You can kind of derive the information or all the quotes and turn them into insights and connect them to projects. So it's more tackled better for research. Key problem with using tools like Dovetail is that it's not a part of the process of many other stakeholders. So it doesn't live in Miro, in Confluence, in other places.

where usually our partners go to. It's not the same knowledge base. It's an extra place and that usually creates this feeling like, oh, I have so many tools and not always we take advantage of them. They're not a part of our habit. So I think this is a good space for like design and research collaboration. But at the end of the day, we would usually still need to make either a Miro board, which used to be a little bit more complex

collaborative for us as a team, or they would just kind of make a presentation and suggest the next steps. And usually the designer is the one who's like taking over and then uses this information and make sure we are using this as the outcome.

I think at the moment, if the initiative is huge, for example, service design or service blueprint, service design mapping, that's a huge one. It would involve every person in a company and would involve a lot of interviews and a lot of mapping and a lot of research and a lot of understanding. That's a bit of a bigger artifact and it will have an official outcome, which would be this service design blueprint where it will be mapping all.

all the products, all the relationship between products, all the key roles and stakeholders in that process. And that's a big one. But then there are like a smaller efforts, like you have specific objective and insights derived based on that goal. And there's a smaller scale. Artifact would really depend on it.

I think for the ongoing projects, it's more common today to see some sort of project like I use Dovetail plus Miro, at least in my experience. And then for the bigger ones that are more related to the company initiatives, maybe even personas sometimes, honestly.

I think at some point every company starts doing thinking, what are the roles, the segments and the specific behavioral patterns that we use to see right now? And how can we make them actionable? How can we always operate with them in mind? Yeah, like you said, Johan, I think personas used to be a typical answer. Today, we are reframing them a bit more into archetypes, which is very similar, but different.

takes away the face, I guess, for me personally. But yeah, I think it's still very important to have this artifact shared across at least your specific product unit. Because otherwise, when I started working at Nuze, we didn't have personas per se. So all I had was like some patterns, some intentions,

Really based on like many assumptions, I had to map out who we are designing for because I'm working in the travel industry. And as you can understand, pretty much the whole world is travelers. So there's multiple variables there. And I had to make a little bit more of a structured approach there. But then we, yes, we still would have to do the research. Our research team right now, what they are working on is on the model of the continuous research where you don't just run research per project, but at least you're trying to reframe it and map

making it an ongoing process. So weekly, you have a project, you don't have a project, you have an interview scheduled with a user from one or another segment, one or another archetype to help you understand the space better. And that's, I think, an interesting another topic, because I feel like when you are running a continuous research, you don't necessarily have the reports or artifacts per se, or at least you're making them a little bit more

of the living processes, living artifacts, if there are any, based on that approach. Did you actually have any continuous research experience or your team ever worked on slushy efforts in the past? Why?

Well, to be completely fair, not really. It would have been ideal. I mean, I think continuous research is just something amazing to have. And I know all the big products and big companies definitely have them. So I think that in big companies, research is sometimes one year ahead of design or something along those lines. I think I remember the podcast from a design leader at Facebook.

It wasn't meta back then. And they were talking about having a dedicated team that runs research for initiatives that were supposed to happen in the following year. So they start very early and it's just continuous. And that's the ideal process. I think you're constantly learning how to embed better design decisions in your product, right? I haven't experienced it. So I think that, again, it comes down to what I was saying initially, that in my experience, I've been through different stages of a product or different processes.

let's say, levels of need, levels of criticality. So sometimes it's critical to run research, especially when you're building a product that you're not very confident that it's the right product. Is it the right problem? Do I understand it fully? And so on. So that's a big risk. But other times when you have a product and it's out there, it's kind of good. You still get some feedback from maybe, I don't know, call center folks or support team in general, or maybe just you're talking to users.

you don't feel that it's as critical as in the first example, right? So I think ideally you would have continuous research, but in my experience, I've had research when it was like much needed, right?

So that's what was my experience so far. Yeah. Yeah, I understand. I actually also didn't work in the companies that had it figured out in a nice way. I think we're only like in a stage of planning it or enabling resources for it or enabling the processes for it. So our research team, like I mentioned in the beginning of this episode, is partly working on

operationalizing the research across the whole company because only two people cannot make it enough. But it's a very interesting challenge to tackle. And I'm really hoping that next year it's something that we will be having more in place. And some of the puzzles, which I mentioned, like you have to enable resources for this. For our case, it's usually to enable

not just like, here is the presentation, here's how we're going to do this right now. From now on, you do this and it's not going to work like this, right? It has to be, again, a cultural shift. A few things that are easier to pull is to start building the user panel specifically with the variables you look in participants with. You know that you usually have these roles in your product or these segments or these behavioral nuances or like behavior patterns and you want to sort of grasp them in that user panel so that for every single research you have,

people with specific characteristics that will be relevant for that initiative. So starting with the user panel is usually a very good place to start from. Currently, there are sectors that are harder in the B2B specifically because there you need people with very specific knowledge, with very specific habits, and it's a bit harder and takes longer to build. Sometimes I've seen the companies that they make partnerships with their business partners. Based on these partnerships, maybe business partners have cheaper services, better discounts or something like that. And then in return, they are more open to participating

participate in the research and provide us with help, with details, with insights. So that's one and another way to go about it. But other than that, our research team at the moment, I believe, was working a lot on like, what's the model? How do we organize it? How do we put it in our calendars? How do we make it so that there's always somebody out there to join that research? Because, you know, if let's say...

you're the only one designer in that product space and you're on vacation and the research session is scheduled every, let's say, Wednesday and you're not there, then it's not going to work. So you need to think about all those, I guess, variables in the life to make sure it is possible to enable and you need to have a buy-in from the

Not just your leadership, but every product team and every product could work, especially product teams could work in different ways. So very big initiative. And honestly, as soon as we have it figured, I will definitely try to share how we do this. But at the moment, I only seen it in the process of cooking. And I'm looking forward to have in my calendar every week some sessions scheduled as well. Yeah. Predictability helps you build your own process in a more coherent way, right?

I wanted to add one more thing. I think it's interesting that, for example, in the case of my company, we are doing continuous research, except we have like 20 products. So we're doing continuous research, but I can't be demanding that my product gets that continuous attention. So if multiple initiatives, if multiple products compete continuously,

for the research attention, then you could say in a way that, yes, we're doing continuous research, but the product might not feel that, right? Because it's like just taking turns in terms of what product we're looking into, or again, the criticality of everything. Like this product needs it more because people complain about it. And this product is in a pretty good place. So we're going to postpone looking into it. So.

And yeah, I think that, again, we're talking about scale and complexity. And the more complex companies, the more it needs an army of resources to sustain the effort of answering all the questions that come up on different products, business lines, and so on. So yeah, that's also something interesting. And I think to this point, that's very important that you mentioned it. Because sometimes maybe you already have data and you don't need to repeat the same research. Maybe somebody already had those questions just applied in a different project space.

I think one of the biggest challenges with establishing the continuous research is to have a database or whatever is the form of it, a project space or whatever space where the information is accessible in the format that everybody could read and use and contribute to. For example, you as a designer were running this continuous research session and you have interesting insights. You definitely want to document them. It's not just for you to have on that project, but this is a token that everybody could reuse in the future if you are

apply it in the right shape with the right context, right? It's not just like our users likes X, Y, Z. So now everybody has to assume that our users likes X, Y, Z. It's of course very nuanced, but that's where the complexity is coming in. I think it's really in organizing that live-in document that everybody could

contribute to, have a model of the contribution, have a model of making it visible and unbiased, I guess, and that making it accessible across the whole organization, not just design teams, but also for PMs, for leadership team to kind of be able to operate with real data and not just assumptions. That's the biggest challenge in my opinion right now. And

hopefully, yeah, it's something that we will start democratizing across, you know, just the whole industry so everybody could take advantage of this. By the way, a quick example here I just couldn't not mention. I was really inspired when I discovered it, like, I think two or three years ago, was an atomic research framework. I believe it was first introduced by VBORC. And it was like, again, this living document where

really every role or every stakeholder in the process, in the customer journey, guest journey, was able to contribute their insights in an organized manner under organized correct pace of that insight. I think they framed it around the customer journey again and like the stages through which their customers are going through so that they would start framing like a bulk of

in sort of bulk of information, let's say around before signing up, during sign up, the experience during, and if they decide to opt out and quit the service, why they would do this, what are the opportunity spaces and stuff like that. So I find it very interesting. You can actually Google that Atomic Research Framework by Vivore. Pretty sure there is an available Airtable database where you can look into it. But yeah, I think there could be many multiple forms on how to have it and how to organize it

Depends on what your company is using, what's the centralized place where everybody could have access to it.

Alrighty, I think we have talked a lot about this today. So we can actually start wrapping it up. And yeah, I would like to ask you, Ioana, what are your top three takeaways for our listeners from this episode? I don't know why it's harder than usual to pick three takeaways. I think because our conversation touched on so many places that were interesting, but none of them like laws of anything.

So I would say one of the most interesting findings around working with research is that everybody does a better job when there's a UX researcher and a UX designer. So obviously, if someone is researching deeply the design questions you have, you as a designer will be able to answer

those questions in an organized, more structured, more reliable manner. So I think it's ideal. If any company or if anyone is contemplating hiring both a researcher and a designer, I would say absolutely do it because it's going to make everyone work better and even faster, right? Because then the designer doesn't have to do the research and then wait until the research is over because they're one person and then start designing. They could absolutely move faster. So it's more efficient.

And then another interesting insight is that to each company, their own process, their own needs, right? Their own very specific kind of infamous already depends. And I think it depends from company to company. And that's an interesting insight. Like I would say everyone who...

who has the power or has the question, should I hire a researcher? How should designers and researchers work together? And all sorts of questions about this collaboration or just in general about the researchers. I think they should first start with what's going on in their company and product. So that's the foundation to every conversation around this topic. And then the last finding...

It's not something I said already. So it's just a new thought. Sometimes researchers and designers can feel like maybe they're overlapping. There could be this level of threat that you might be experiencing. Like I've heard about teams where there were tensions between the designers and the researchers because the designers were feeling that maybe the researchers were sort of stealing from their plate of things and they felt

threatened by researchers. And then again, the researchers felt like they don't have the freedom they need. They don't have the autonomy they need because their designers get very involved. And sometimes it's what we as designers also experience with the product managers, right? So we feel like we're sort of, sometimes we have overlapping responsibilities or we kind of cross the lines where we feel, again, threatened in our egos and stuff like that.

So I've heard all sorts of stories. I haven't personally been in this kind of, let's say toxic kind of, or not toxic, but stressful kind of collaborative setup. But my point is that we're actually enhancing...

each other's work so it's really a very good example of what should be collaboration over competition so cooperation over competition and I think that if you leave out the ego out of anything professionally everyone is going to do a better job and the product will just be essentially better so those are my top two findings and one new idea what do you want to add

Yeah, I think I would only add that research comes with the UX maturity of the company, of the product in particular, because we work in a product space. Every company at some point starts scaling. The processes became more complex. The responsibilities become more fragmented. The depth of knowledge grows exponentially.

I think it's very important for designers, the person who's early on in any project or any company, honestly, to promote their research as soon as possible. So I think as soon as your company starts growing, it's your responsibility as a designer to start advocating for the research power. And even though, like Ioanna said, sometimes it could feel like maybe overlap and I can still do this. I think for you, as soon as you start seeing that your design plate is being more and more heavy and

busy with everything and it's very hard to handle everything in a deep enough and qualitative way, it's very important for you to start advocating for the research. And for sure, there will be a space for you how to collaborate best. In the beginning, you can definitely discuss and figure out the zone of responsibilities or look for the person who you believe will best

fit the current needs of the company, right? So maybe you're good with design testing, but you need somebody who will have to form the bigger picture and will be forming like all the discovery stages. So again, trying to understand and really building the case for your company to understand the need of it, because the earlier you do it, the more user-centered culture you're building. Because in my experience, when I joined a company that had many thousands of people, I'm not going to mention, but we did have like more than 10,000 employees.

employees and they only had like a team of

three or four researchers that was not making the company user-centered. It was just very tactical, last-minute wrestlers for us, sometimes available, sometimes not taking a long time, et cetera, et cetera. It was just not a very good user-centered UX mature space. So I feel from that experience, I've learned that it's very important to attract a user-rich team as early as possible to build it as a part of the culture, to build it as a part of your design process. So everyone early on in the company starts understanding the

need of it and even starts operationalizing that the research is a part of the process. That's actually my second takeaway. And the takeaway is helping to operationalize the research. For that, again, the research team is usually very helpful because you probably don't have like too many researchers, more than designers for sure. So that will be important for you to collaborate with researchers. Well, maybe they will actually take care of this, but it's just the point that the

operationalizing the research, having the tools in place, maybe processes and best practices will help your company to scale up that culture and make research always a part of your process, making research always data-driven, user-centered, etc.

I think my third takeaway would be, I don't even know if there is a takeaway. I just think that collaboration is always the key. And even though this is our topic of today's episode, I think that's just the backbone of any design work to collaborate with researchers. No matter what you're looking for, information you're looking for, to always involve them, making sure they're aligned, they understand the needs and making sure they could always help you form in the right place.

picture and you could also in the collaboration agree on the best form of socializing it across the partners etc etc so for me the collaboration would always be a key and a good researcher will help you to make the company much more user-centered there's the tools again best practices maybe the places where we document everything how we document everything and stuff like that collaboration would be my third takeaway i guess and it's as simple as that

So I think that's it for our episode for today. Thank you so much for tuning in. I'm sorry if this episode was a little bit nerdier than usual, but I think it's an important one because we work in a very collaborative and cross-functional spaces. And thus it's important to also talk about this topic.

If you learned something today, that's awesome. We would appreciate it if you could rate us on Spotify or any other platform you're listening to us on. That usually is really motivating us to keep recording new episodes. And also, if you have any feedback, we have an anonymous form where you can submit it.

Plus, you can submit there the next questions or the next topics for new episodes. We definitely want to make it as relevant for you as possible. So please help us with forming the next questions, the next episodes. You can always find the resources in the show notes or under the episode specifically in the Spotify or just reach out to us on our Instagrams. And that will be it for today. Thank you so much for joining and we will see you in the next episodes. Bye, everyone. Bye-bye. Bye-bye.