Strategic Tools For Personas & User Journeys

Michal Mazur at UXDX Community: Warsaw. Video: https://youtu.be/aE73-Sl3BA8

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.

The tricky moment between discovery and product vision

[00:00:00] Today I want to talk about the tricky moment between the discovery phase, when you make user research, when you conduct interviews, and how to translate it into an actual product vision, product strategy.

[00:00:23] I need to turn this on. So, have you already been introduced? My name is Michal Mazur. Once again, I'm working for a company called El Passion, which is a visual product house. We have delivered over 300 projects over the last seven years. We're working mostly with startups, medium and small companies. We're doing web apps, mobile apps, both Android and iOS.

[00:00:49] Something that Rory touched upon in his talk was the first problem, the problem with aligning the vision and agreeing on the problem. I think it's a big problem, and I noticed it before as well.

[00:01:03] How many of you know the fable of the blind men and an elephant? The fable says that there is a group of blind men and they have been tasked with describing an elephant. One of them touches the trunk and says, oh, an elephant is actually kind of like a snake, it's long and soft. Another one touches the trunk and says, no, actually, an elephant is kind of like a spear, because it's hard and pointy. A third man walks up to the elephant's leg and says, no, actually, you guys are wrong, an elephant is kind of like a pillar, like a tree.

[00:01:38] And so on and so on and so on, and they've got to fight and they never agreed on what an elephant actually is. I see the same problem in organizations, when it's really hard to define a single vision, to define and agree on the problem. And I think it's a pretty big impediment on how the whole product development process continues later on.

Premature solutions, and the trouble with soft data

[00:01:59] Another problem that I've seen and noticed is that people tend to cling to their premature idea solutions. 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 should have on the actual product vision.

[00:02:45] Another problem that I noticed is that it's quite tricky for people to understand soft data, qualitative data. We are used to seeing charts, we 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 actually build a product out of these things. Then it gets quite tricky, and I think that the right tools, the right approach in the transition to the next phase, can help you tremendously with that.

Affinity mapping and personas

[00:03:20] There is no right or wrong tool set that you would 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.

[00:03:38] First of all, when the discovery phase ends, when you have conducted the interviews, when you have loads of data, you need to make sense of all the unstructured data. 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 insights, a set of qualitative information, and tries to group it collaboratively into themes. These themes will then help you create a product vision.

[00:04:09] This is a great way to engage the whole team, so you should involve different functions. You should involve developers, marketing, business stakeholders. You should involve everybody that you can in this process. And it was great to actually explain to people what UX is, and where the value is in the discovery phase, and how it translates to the actual product vision.

[00:04:34] As I mentioned, there is no right or wrong way to do personas. They can be really rough, like a set of Post-its 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-optimized, that just fits for this particular project.

[00:04:55] I think that it is really important to state when you actually don't know something, when you make some guesses, whether they are expert guesses or just plain guesses. It should be clear whether a persona was constructed with research, or whether it is a proto-persona based on assumptions. And that is because when you create a persona, it is an artifact that lives its own life in an organization. If somebody picks it up in a year, they should be clear on whether it was actually based on something tangible, or whether it was just guesses, a quick method.

[00:05:30] That is because bad personas[?] are sometimes worse than no personas. There would be projects where you don't believe the persona at all. Maybe you will find different substitute methods that will allocate you[?] in the whole process. So you may not want to have a persona which is completely wrong, because it could eventually lead you to the wrong solution, or to solving the wrong problem.

[00:05:53] And please remember that personas are not the real stuff. It doesn't work like that, that you send somebody or you show somebody a picture of a persona and say, yeah, go empathize with the users, and this is it. It doesn't work like that. It is like walking on the street and you see a nice candy store. You see a nice candy store and you want to taste all the chocolates and you want to smell them, touch them. But actually what you end up doing is what this poor little kid does. And it is the same with personas: you can't really taste, you can't empathize with the users, if you don't spend some time, if you don't explore their lives in a proper way.

User scenarios, jobs to be done and empathy maps

[00:06:30] A really good way to engage other people with your personas is to keep them moving, and you can do that by implementing user scenarios. User scenarios are narratives that put your personas to work. You basically write or tell stories about them. You make them move, you make them alive by telling them stories. And it is really important to do, because stories are something that we naturally resonate to. We are naturally receptive to narratives, and we should use that in our everyday work.

[00:07:03] Another framework, and Rory has already touched on that, so thanks, is jobs to be done. What I wanted to add here is that jobs to be done can be defined in two ways, or they have two aspects to them. One is functional and one is emotional. The emotional aspect is something that is sometimes overlooked, and we don't care about what emotions our users are going through when they go through an experience. And there will be situations where there are more emotional challenges in the user experience than functional. You may have situations where you have a very simple functional interface, but the challenges are actually in the head or in the heart.

[00:07:42] And a great way to map it are empathy maps. Empathy maps are a tool where you explore different senses of your persona. You go through what the persona thinks and feels and sees, so you explore, you immerse yourself in the hearts and minds of your users. And it is a great, great way to engage people in your team with different functions, because if they are there, if they build up the empathy map with you based on your research, then they can really empathize with the end users. So definitely try that in your next project.

Customer journey maps and ecosystem maps

[00:08:20] A tool that probably most of us know is the customer journey map. And customer journey maps, again, can't be done right or wrong. There is no right way to do it. Just to reiterate what the customer journey map is, in case some of you don't know: it is basically a map where you list actions or steps that your users go through, and you show relationships between these steps. You may show the emotions, whether they are positive or negative.

[00:08:47] And what is really important is that you can highlight pains. Pains that do not occur necessarily on certain screens or certain elements of your experience, but also in between the steps. And this is where a customer journey map is really useful. And from these pains come opportunities. The best products solve problems, and this is a great way to highlight these pain points and try to find solutions for them.

[00:09:12] 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 is better to take a higher look at an experience and create an ecosystem map, which shows relationships between the company or the customer and different actors, something that applies some forces from outside of the experience.

[00:09:46] To give you an example, and it is totally random that I picked an airline: if you are working on an airline, you interact with an airport, you interact with flight search engines, or with regulations. You also have competitors. And you can map all these interrelations on an ecosystem map. And then, if you want to go into detail, you can go through particular journeys and see how your users interact with those particular actors or themes. So it is a great way to take a bird's eye view on your user experience.

[00:10:21] Again, same point: either keep it real and base everything on research, or not, and clearly state that you have created those artifacts based on assumptions. A customer journey map is 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 realize that at some point you don't know anything about a particular step. There is no data, there is no knowledge in the organization. And this will help you determine what more research could be done to fill in those gaps.

Making the whole team see the elephant

[00:10:58] So how can we make this work, and how can we make the whole team see the elephant, see a unified product vision or program vision? Well, first of all, you need to involve everybody as soon as possible. This is also what Rory did in his projects. Get everybody from different functions, from different departments, ready to research with you. Involve them in usability testing, involve them in analysis. It's a really good way to engage the whole team.

[00:11:29] 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 you will save time on further communication and basically on solving further conflicts.

[00:11:46] In my previous job at CutGyger[?], I had a workshop where we went into the room and I gathered all the outcomes from the user research that I'd done. We went through all the insights, mapped them all on the walls with posters, and did the affinity mapping activity. And basically this created our next product's vision, or the next function.

[00:12:09] A great thing that happened is that the senior marketing manager came up to me later on and she said, anyway, this was great, I just realized that I've been doing things wrong all along. I've been just pushing my ideas and I've been listening to users, and I finally see what UX is about. I didn't understand that. And I think it's a great way to also show people and educate people about what UX really is. If they just hear about it[?], if they see your artifacts, they may not understand it.

[00:12:40] 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 we need to just go and build my vision. No, I gathered everybody on the team and worked on a shared vision that we worked out together.

Present, name your assumptions, remember emotion

[00:13:01] What I always try to do is present, over sending emails. I think that sending emails is really tricky, because you actually can't tell a story from an email. It's really fragmented, and sometimes people miss emails. So always, always present whatever you've done to the team, to the stakeholders, and basically keep your artifacts alive in that way.

[00:13:23] Again, the same point: always name your assumptions. Always name what you don't know, what you guessed in the artifacts. Always make sure that it's clear to everybody on the team. And also describe all the implications of the outcomes on the research findings. If you don't do that, it's kind of hard for people to understand, okay, this is a persona, these are customer journey maps, and how do we progress from here? Sometimes people don't make that connection.

[00:13:48] And what's really important is to describe some of the implications that you might have from particular user pain points. You may write some assumptive solutions to problems: so if our personas have these sorts of problems, then perhaps we need this feature or this feature. It's really important to connect this to further stages in the process.

[00:14:13] And what I think is also important is always remember about the emotional side of the user experience, because I can see that sometimes we focus on the functions and the features and we try to sell our process that way. But we are making technology improvements, and we should always think about how we can make it better for them. So if I were to choose one strategic tool that would work in every design project, every product development project, it would simply be empathy. Thank you very much.

[00:14:46] Thank you.