How user research can help crypto startups to bring real value to the people?

Igor Voloshin at UXDX Community: Research & Content Design for Product Teams. Video: https://youtu.be/74Ct44hJSzw

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.

About me, CoinsPaid and the discovery team

[00:00:00] Igor: What I wanted to tell you about today, guys, is a story I've recently been working on while researching the issues with the export button in our back office product. But I'll tell you about this a little bit later. Let me introduce some more details about me. You already know my name. I'm a discovery team lead at CoinsPaid. I've been working with different companies: startups like Awesome [?], consulting companies like BCG and Deloitte, mobile development companies, and I had my own business as well. But I think the greatest thing about me is that I'm coming to the USA event in a month, and I would really love to see all of you there. If you would like to say hi to me, just come; I'm a really friendly guy and I would love to meet you in person.

[00:00:59] I recently joined CoinsPaid, back in December. CoinsPaid is a company which provides several crypto solutions. One of the main ones is the crypto payment gateway; the other one is the business wallet. Those two products give you the ability to accept cryptocurrencies, manage funds and withdraw fiat currencies. Crypto is developing at a really high pace. The thing is that there are still UX issues in a lot of places, and I truly believe that blockchain was definitely not developed with designers involved, because most of the things are more the IT way of doing things. That's why I've been invited to the company: to help create a different culture, a different approach to how we solve the issues, that will help us boost the customer and user experience.

[00:02:00] My team will consist of five people including me, but currently it's just three. I've developed this idea that we want to have a dedicated team, and the team will be divided based on the stages of the product development process. That's why I've got several researchers. The CX researcher will focus more on external research, when we want to learn something new about the clients in order to develop a new feature or a new product line. The UX researcher will be responsible for helping to decide how a feature will be implemented in the real product, or how to change the current product in a better way. We also definitely need someone to evaluate at the end, because we don't even have the simplest NPS measurement currently. And I definitely need a research ops person who will help make everything happen.

[00:03:06] I deliberately put the three things I'm going to focus on in this presentation at the beginning, so you will learn where I'm coming from. The first thing is the customer-insights-driven product development culture, which I'm trying to evolve here, and I'll be telling you what the current way of doing things is. Second, the importance of context for solution development. As a dedicated discovery team, we gather all the information about the client, and then we need to pass it to the product teams, and it's really important how you actually do this. Context is one of those things that is really important for the discovery team to pass to the product teams, in order for them to create a better solution. And then I will talk, in just a slide, about how the product teams can proceed with all this data. The way they proceed with it is really important to align with the strategy of what you want to do with your product.

From solution-driven to insight-driven product development

[00:04:16] Okay, so let's start. Let's get back to this export button. Our product is a B2B product, so companies sign a contract with us and we help them integrate this payment method. After they install everything and onboard, at some point they need to take the whole list of transactions and reports and export them to do certain things. The thing is that currently, companies and people in the companies complain a lot about it, and they've been complaining for a really long time.

[00:04:58] The way things are usually done at CoinsPaid, I call it solution-driven product development. Customers complain to different people inside the company, usually in our case C-level management and account managers, the ones who actually talk with the clients. Those guys hear these complaints, think about them, then give a solution straight to the product team. Maybe they give them some context, or the decision-making journey somewhere in their head of how they came up with the solution. But the thing is that the product team doesn't have enough understanding of the initial problem, and there are so many solutions that come to the product team that they don't have time to do proper research. That's what I wanted to change in the way things are working.

[00:06:01] This would be an example of how solutions are currently sent to the backlog of the product team. As you can see, there are certain ideas. They describe a problem just a little bit, but mostly there's nothing about the actual context in which the pain happens or anything like this, and the product team has to work with it somehow.

[00:06:44] Then I come into play, and what I want to do is change it to a customer-insights-driven product development culture. As a discovery team, I know that there is an issue with the export button, but I don't want to go to the solutions part. I would rather go back to the customers and do the basic research, asking for the stories: what are they actually doing with the button that then leads to their pain? What are their stories, what is their experience there? Then, by processing it through my team, through the knowledge we have, through the lots of interviews that we've done, we create those customer insights and bring them to the product team in a way that they will be able to comprehend and use further on. Just a second, I think I need to restart the presentation. Yeah, this is the way.

Running the export research

[00:07:44] We decided to do this kind of research, and we put together some questions that we wanted to find answers for. What are the jobs clients hire the export function for? Who uses the export function? What are they trying to achieve there? These were the basic questions. Of course we did an interview guide, but we wanted to find the answers to all those questions with some in-depth interviews.

[00:08:22] First we started with internal ones, because our own employees, in the finance department and the accounting department, also use the back office and this function as well. So we were able to learn, in a safe environment within the company, what they don't like about the export button. Then we also went to five clients. We had eight respondents with different roles, and we learned that there are more roles than we initially thought when we were entering into the research. The number is not really high, but we learned a lot from just 11 interviews. So I would suggest, every time you have any issues with the experience, go to the client and just try to find anyone you can talk to, in order to get a better understanding of what's happening.

[00:09:30] The gathering and processing of the data happened like this. We did the interviews via Zoom. We did Google Meet too, but the quality of the picture was not enough for us. Then the transcription had to be done manually. Some of the interviews were done in English and some in Russian, and the software that we tried to use to transcribe everything wasn't performing well, so we had to do it manually. Then we parsed those insights into quotes, steps, screenshots and pains, in order to get the overall data, and then through induction we did the final presentation. It was all done in Figma; we prefer to work in Figma, at least for some of the projects.

[00:10:24] This is what the interview parsing actually looks like. There are lots of screenshots. The black ones are the back office; all the other ones are screenshots of how the exported data is actually being used, and how many additional steps had to be taken in order to get the information sorted out the way clients needed it for their goals.

Jobs to be done statements, job stories and pains

[00:10:51] After we parsed those interviews and looked into them, we defined a few jobs to be done statements. This is just an example of three of them; there are many more. The great thing about those statements, and I really like them, is that they are more universal. I guess a lot of companies within the payment industry definitely have the same things. For example, the reconciliation role needs to keep the data consistent between both systems, the CoinsPaid back office and the accounting system that they have. That was their goal, and they've been hiring the export button to get this done.

[00:11:44] Then we expanded the statement into a job story, to add the context and the motivation, so it would be packed in a way that the product team could easily understand what is happening there and what their goal and limitations are, so it would be easier for them to create those solutions. This job story sounds like this: when I compare transactions from the CoinsPaid back office and my accounting software daily, I want to quickly and effortlessly identify disparities and edit them, so I can be sure the data is consistent in both systems. To get to this level of simplicity, we had to make several attempts to filter out everything that is too detailed, so it does not have any solutions in it. And I guess it worked.

[00:12:45] We also identified pains, and we tried to create a list which was quite short and enabled product teams to easily understand what the exact pain is. For example, one of them is that the export function freezes for reports consisting of more than 100,000 transactions, which means you click on the export button, but it just doesn't give you anything; it's stuck there forever. Another was that the structure of transactions needs additional actions to calculate the actual fees incurred. The way we presented the transactions and transaction costs was not easy for the clients to comprehend.

[00:13:31] Then we compiled the overall presentation. It looked like this. It was lots of slides, because we had gathered a lot of knowledge, but in essence it had this logic behind it. We had statements, and every statement could have several job stories, because they might have different contexts. For the reconciliation example, one context would be doing the reconciliation every single day, so you would have a limited number of transactions. The other is when you're trying to do the reconciliation once a month with a huge number of transactions, and that gives you a slightly different way of approaching it.

[00:14:22] We had, I would say not mapped out, because it was more like instructions, the current journeys the users had to go through in order to get their things done, and we identified the pains on those steps. The thing about the pains is that the same problem could appear on several journeys. That's really important for us, because by solving one pain we can have a great impact on the user experience for different jobs, and probably for different roles.

Two ways to slice the pains

[00:15:00] With the knowledge that we gave to the product teams, through the presentation and through in-depth discussion of every single slide, the product teams now had enough understanding of what the issues are and what the context is, and they can go on and look for design solutions and try to solve the issues. There are two options here, I would say, for which way to slice all those pains that we found, how to approach them and find the solutions.

[00:15:41] One approach would be to be jobs to be done statement focused. You take a statement, a job story, you have the current journey, and you decide, hey, we want to solve all the issues for this particular journey in order to make this particular journey feel great, and we will take all those things away. While doing so, because those pains happen repeatedly on other journeys as well, you help the other journeys too; you change the other journeys as well. But the greatest experience will only be on this particular journey.

[00:16:23] The other way around is to have, I would say, a pain-focused approach, where you have this list of pains and you prioritize them: what is the pain that has the most impact on the customer experience? Let's solve it, then move to the second one, to the third one. It might happen that those pains are distributed among some of the journeys, and not a single journey would have this great experience. Every single one would have some issues, and you wouldn't have any wow effects anywhere. But it's in the product teams' area of responsibility to decide which approach they want to take.

The importance of context

[00:17:17] On the importance of context: when I was saying that it's really important to give the context, not just the pains, not just the journey, it's because based on the context, different solutions can be made. For example, if we have this export function freeze issue and there's no other context, then the direct solution would be to redesign the way files are generated, to be sure that even if you have a million transactions, you will still receive the Excel file.

[00:17:52] But if we are in the context, and we say, hey, the files are then used for reconciliation with the client's accounting software, we can think, okay, a million transactions would be a really awful thing to have in Excel in order to get them reconciled. Let's develop an API and let the accounting software sync with our back office data, and they will reconcile it on a daily basis, and the reconciliation manager will receive a notification if something differs.

[00:18:28] Another example: if the files are used to calculate the account balance to manage liquidity, then again we can do a really direct thing and add a balance feature. But if we dig deeper and think maybe we can help even better, maybe we can add a liquidity suggestion feature. This way we will give more value to the client and again bring the user experience to a much better level.

[00:18:59] So currently we've done this research, we've given it to the product teams, and now we are supporting them to understand it in a detailed way. It's still in progress, and it's really interesting to see how they will create those solutions and implement them; I think that's going to be this quarter or next quarter. But I think the three things that I mentioned at the start are the ideas that this presentation proves. The customer-insights-driven product development culture really helps you give more freedom to the product teams, and it helps you create better solutions. If the product team doesn't have the ability to go and do the research, then you definitely have to create a dedicated team like us.

[00:20:03] Context is really important for solution development, and that's why it needs to be collected and packaged in a way that product teams can consider when they're creating solutions. And it's up to the product teams how they will slice the pains and approach all the things that they have found, or we have found. So it's really interesting to see what will happen further on. Thank you for your attention. I hope you found something interesting in my presentation. If yes, then please write me three ideas that came to your mind while you were listening to me. And if you have any questions, just find me somewhere on social networks, or send a WhatsApp message to me, and I'll be really happy to answer everything that you ask me.

Q&A

[00:21:03] Host: Brilliant, thank you very much, Igor. I really enjoyed that, because I'm a massive fan of jobs to be done, so I tend to get excited. Just to reiterate, if anybody has any questions, please do write them in on whichever platform you're watching this on, and I'll collate those and pass them through to Igor.

[00:21:23] One thing that came up as I was listening to your talk: the export feature is a brilliant example of "this is as far as I'm going to go with our product, and after that it's up to you." That's something that teams often have a real challenge with: where is the boundary of the product? How do you manage that? With any product you could keep digging and digging, and you could keep finding problems. So what do you use to make sure that you're not stretching beyond what you should be focusing on?

[00:22:03] Igor: Well, regarding the research, I'm not a product manager. A product manager would definitely have really strict borders. For me, when I'm doing research, I'm trying to expand those borders as much as possible while we're having this conversation with the client, making them larger than the product manager's borders. Otherwise, if I don't bring enough knowledge to the product manager, he would just say to me something like, you've missed it, because I don't understand why this third thing is happening.

[00:22:51] Also, because I'm new to the company, I'm trying to understand how far we really want to go into the customer's life. I'm still trying to find this border. But if we come back to my previous job, at Awesome, when I was doing a lot of research mostly on internal processes, every single time, the more I dug, the more I expanded those borders for the product managers, the more helpful it was. So I guess maybe a researcher's task is to show the product manager that there's much more than he can think about regarding the customer's life. And maybe this is the way the product manager will finally think out of the box and create something that will have this wow emotion that we would really love to hear from the clients.

[00:24:08] Host: Great, no, that is good, because I guess they might not even be aware of some of these challenges that people are facing.

[00:24:16] Igor: Yeah, that's true, that's true.

[00:24:18] Host: And Kayla has just put in a comment saying she appreciates your emphasis on context, because it is so imperative to drive out well-informed solutions that eliminate confirmation bias and return the value back to the user. So she says, very well done presentation.

[00:24:33] Igor: Thank you very much. I truly believe that when I'm doing research, we'll definitely have a lot of different ideas about how to solve things. When we are pushing this information to the product team, we are deliberately not saying anything about the ideas and solutions that we have, or that clients might have said. Because when you just give them a space, saying, hey, this is the context, and you can create whatever you want, I think it gives great freedom to the people who are responsible for creating solutions. They don't need to be thinking, okay, I've got this idea, but the client said the other idea, which one is better? Without that social pressure or idea pressure from anyone else, it's really up to you how you solve it. That's why context gives you all this data without the need to say the idea that the client said or something like this.

[00:25:47] Host: Great. I love that, and it actually ties in a little bit with my next question. You're providing all of this context and all of these problems, but at the same time they're probably still getting, from the stakeholders in that diagram you showed at the start, the sales teams, "just go build this." How does your product team balance that out: actually, we should solve this export and not the other thing?

[00:26:22] Igor: What we're doing currently is trying to solve several issues at the same time. On one hand, we are trying to balance the business strategy with the product strategy, to align them with each other, and also align them with the backlog that we have, with all those complaints. Because I think we currently have a really big debt in terms of UX features that need to be done. We are coming to the conclusion that this year should be the year when we try not to create new features, but rather reiterate our own product, the core product and the core features that are there, making them better, simpler to use, a better experience, more stable. And after that, probably next year, we will be able to scale up a little bit.

[00:27:29] It's also really important for us that we are not just giving the interview results and this presentation to the product team; we also go back to the account managers and C-level managers and tell them, hey, we found these things, so that everyone is in the same context, on the same information board, the information whiteboard, I guess that's what we call it. If everyone has the same amount of information, it's much easier to come to the same solutions, rather than everyone having different portions of the information and not knowing anything about someone else's vision. So that's how we try to manage it.

[00:28:20] But again, I really want to emphasize that the product team should have autonomy in making those decisions. And the reason why is that they should deeply understand the client's context. I don't believe that C-level managers or account managers are able to do this; they have different jobs. The product team has this ability, and they just need the context and the empowerment.

[00:28:55] Host: Excellent, that brings us to time. Thank you very much, Igor. I really enjoyed that.

[00:29:01] Igor: Oh, thank you very much. I really appreciate you giving me a chance to do my speech. Thank you very much, and see you in New York, if I'll be there.