Strategic Tools For Personas & User Journeys
Strategic Tools For Personas & User Journeys
El Passion's, Michal Mazur will discuss how to choose the right toolset when looking at moving from product problem to setting the product vision.
Today, I wanted to talk about this tricky moment between the discovery phase, when you make use of research, when you conduct interviews and how to translate it into an actual product vision, product strategy. I've already been introduced Once again, I'm working for a company called El Passion, which is a digital product house. We have delivered over 300 projects over the last seven years. We went to multiple start-ups, medium and small companies, and we are doing web apps, mobile apps, both Android and iOS. And something that we really touched upon was the problem with aligning the vision and agreeing on the problem. And I think it's a big problem, and I noticed it before as well. How many of you know the fable of the blind men and elephant? Ok, so the fable says that there is a group of blind men and they have been tasked with describing an elephant. So one of them touches the trunk and says, Oh, an elephant is actually kind of like the snake, long and soft. Another one touches the tusk and says, No, actually, elephants are like a spear because it's hard and pointy.
A third man walks up to the elephants leg and says, No, actually, you guys are wrong. It's kind of like a pillar, like a tree. So on and so on. And you've got to fight. And they never agreed on what an elephant actually is. And I see the same problem in organisations when it's really hard to define a single vision, define and agree on the problem. And I think it's a really big impediment on how the whole product development process continues later on. Excuse me. Another problem that I that I've seen and I noticed is that people tend to lean to the premature solutions. So even though sometimes we conduct a discovery phase, we try to explore different possibilities and different problems. People, usually senior executives or clients, tend to stick to their own ideas. And no matter what happens in the discovery phase, they try to push with their own ideas. And it's partially because some people just have big egos and they want to push what's theirs. But partially, it may be because there is no clear indication of what impact the discovery phase had on the actual product vision.
So another problem that I noticed is that also it's quite tricky for people to understand some data, qualitative data. We are used to seeing charts really like numbers. We like having everything laid out clearly. So people are faced with transitioning from a set of user interviews and observations and videos and images and trying to understand how we can build actually a product out of these things. Then it gets quite tricky. And I think that the right tools, the right approach in the in the transition to the next phase, it can help you tremendously with that. So there is no right or wrong tools that you can use in a project. There is no right way to do personas or customer journey maps. You just need to find what's right and what's going to work in your team with your stakeholders, because every project, every team is different. First of all, when the discovery phase ends, when we have conducted the interviews, when you have loads of data, you need to make sense of all the mass of all the unstructured data. And one of the ways to do it is to conduct a workshop where you conduct affinity mapping, which is an activity where a group of people goes through a set of set of insights, a set of information, qualitative information and tries to group it collaboratively with into themes. And these themes will then help you create a product vision. This is a great way to engage the whole team, so you should involve different functions.
You should involve developers, marketing and business stakeholders. You should involve everybody that you can in this process, and it works. It was great to actually explain to people what UX is and what the value is at the discovery phase and how it translates to the actual product vision. As I mentioned, there is no right or wrong way to do personas. They can be really rough like set of Post-it’s on the wall, where you just have tasks and goals and frustrations. It can be something slightly more complex, but you really need to find a way that fits into your process that is not over optimised, that that's just a fit for this particular project. And I think it's really important to state when we actually don't know something. When you make some guesses with their expert guesses or just plain guesses, it should be clear whether a persona was constructed with research. Whether it's a problem for someone based on assumptions, and it's because we have decreed you create a persona, it's an artifact that lives its own life and an organisation. If somebody picks it up in a year, they shouldn't be clear on whether it was actually based on something tangible or whether it was just guesses. A quick, quick method. That's because their personas are sometimes worse than an oversight. So you might not want to have a persona, which is completely wrong because it could eventually lead you to one solution or for solving the wrong problem.
And we remember that personas are not real stuff, so it doesn't work like that you send somebody or show somebody's picture of persona and say, Yeah, you know, empathise with the users that this is it. It doesn't work like that. It's like walking on the street and it's a nice candy store or just a few where you see nice candy store. You want to taste all the chocolates, you want to smell them, touch them. But actually, when you end up doing it, this is what this poor kid does. And it's the same with persona, so you can't really taste. You can empathize the users if you don't spend some time, if you don't explore their lives in a proper way. A really good way to engage other people with your personas is to keep them moving. And if you do that by implementing user scenarios, the easiest areas are narratives that put your personas to work. You know, you basically write or tell stories about them, you make them move and you make them a lot by telling those stories. And it's really important to do because stories are something that we naturally resonate to. We are naturally receptive to narratives and we should use them on everything. Another framework, and he's already touched on that. So thanks is just to be done. And what I wanted to add here is that the jobs to be done in a defined in two ways or they have two aspects to it.
So one is functional and one is the emotional and the emotional aspect is something that's sometimes overlooked. And we don't care about what emotions our users are going through when we go through an experience. And there would be situations where there are more, more emotional challenges than the user experience malfunctioning. You may have situations where you have very simple functional interfaces, but the challenges are actually in the head or in the heart, and a great way to motivate. Ah, empathy maps. Empathy Map is a tool where you explore different senses of your persona. You go through what the person thinks and feels and sees. So you explore. You immerse yourself in the hearts and minds of your users. And it's a great, great way to engage people in in your team from different functions. Because if they are there, if they build up the empathy map that you based on your research, that they can really empathize with the end users. So definitely try that in your next project. That probably most of us know is also a journey map and personal journey maps. Again, they can be done the right or wrong way. There is no right way to do it. Just to reiterate what the customer journey is about, in case this is something we don't know. It's basically a map where you list actions or steps that your users go through.
You show relationships between these steps. You may show the emotions, whether they're positive or negative. And what's really important is that you can highlight things that don't occur necessarily on certain screens or certain elements of your experience, but also in between the steps. And this is where the customer journey map is really useful from these of opportunities and then personalised to solve problems. And this is a great way to highlight these pain points and try to find solutions for it. Sometimes we end up creating customer journey maps that show an experience that is not linear. And we try to force our way and make it a list of steps that somebody goes through. But actually, sometimes it's better to take a high level look at an experience and create an ecosystem map, which shows the relationships between the company or the customer and different actors, something that that applies to forces from outside of the experience. To give you an example. And it's totally, random that I picked an airline. If you if you work in an airline, you interact with an airport, you interact with flight search engines or with regulations. You also have competitors and you can have all these all these interpretations on an ecosystem map. And then if you want to go into detail, you can go through particular journeys and. How users interact with those particular actors or themes. So it's a great way to take a bird's eye view on your user experience.
Again, the same point, either keep it real and base everything on research or not, and clearly state that they either created those articles based on assumptions. It's a great way not only to map the whole experience but also to find gaps in your own knowledge. So when you go through a customer journey mapping exercise, you may realise that at some point you don't know anything about a particular step. There is no data, there is no knowledge in the organisation, and this will help you determine what maybe more research could be done to fill in those gaps. So how do we make this work and how can we make the whole team see the whole elephant, see a unified product vision of problem vision? Well, first of all, you need to involve everybody as soon as possible, and this is also what we did in the past. And the projects get everybody from different functions, from different departments ready to research; you involve them in usability testing and analysis. And it's a really good way to engage the whole team. And I know that it's tricky to find time. I know that sometimes, especially in the agency environment, it's tricky to find time to involve a group of people for a couple of hours. But it's definitely worth it because it will save time on further communication. In my previous job at John Gallagher, I ran a workshop where we went into the room and I have gathered all the outcomes from the user research that I've done.
We have gone through all the insides of the walls with both hands and the affinity mapping activity. And basically, this created our next product vision or the next function and a great way. An amazingly great thing that happened is that the senior marketing manager came up to me later on and she said, Anyhow, this was great. I just realised I've been doing things wrong all along, and I've been just pushing my ideas and I will listen to users and I finally see what the UX is about. I do understand that, and I think it's a great way to also show people and educate people about what the UX really is. If they just feel about it, if they see or act fast, they may not understand what I did in this situation. I acted as a facilitator, as a steward, but not as a dictator. I didn't say, Hey, this is my research. This is what I've done. And now just we need to just go and build my vision. No, I got it. Everybody in the team and working on a shared vision that worked out together. I think that sending emails is really tricky because you actually can't tell a story through an email. It's really fragmented. Sometimes people miss emails so always, always present whatever you've done to the team, to the stakeholders, and basically keep your people out of a line in that way.
Again, the same point always naming your assumptions always name where you don't know what you miss, and in the artifacts, always make sure that it's clear to everybody on the team and also describe them despite all the implications of the outcomes of the research. Because if you don't do that, it's kind of hard for people to understand, OK, this is a persona. These are the customer journey maps and how we've progressed from here. Sometimes people don't make the connection. And what's really important is to describe some of the implications that you might have from a particular user's pain points. You may write some assumptive solutions to problems. So if our personas have these little problems that perhaps we need this feature, this feature, it's really important to connect this further, further stages in the process. And what I think is also important is remember, always remember about the emotional side of the user experience, because I can see that sometimes we focus on the function, some of the features that we try to sell our process that way. But we are making technology procurements and we should always think about how we can make it better for them. So if I would have to choose one strategic tool that would work in every project, every product is the project. It would simply be everything.
Thank you very much.