“Most People Consider Any User Experience Maps as CJMs”, Says Yuriy from UXPressia

8 minutes

26.04.2021

“Most People Consider Any User Experience Maps as CJMs”, Says Yuriy from UXPressia

Our content marketer Lana had a chance to interview Yuriy, founder of UXPressia, for our product research book.

He’s an expert in business analytics, usability, and UX. His creature UXPressia is a tool for CJM and other experience map designs that help businesses make their products better.

See what they discussed during their talk:

why everyone mixes up CJM terms and how to handle this;
what user experience maps can do for businesses;
what is Service Blueprint and how it can help businesses arrange their business processes;
how UXPressia designed the experience map for themselves.

— CJM, UJM, LXM. I can go on with this list forever. Why are there so many names of user experience maps, who needs them all?

— It’s all about your objectives. The type of map is determined by who designs it and why. If you ask yourself “Why do I need it? What am I going to do with it?”, the answers will show you what map you need.

The first thing you should consider is a categorization between “as is” and “to be”. What we imply in our map depends on this type of classification.

“As is” maps are designed based on the customer and user information that we already have. Ideally, this should be data and knowledge. The purpose of this map is to demonstrate the current state of your business or product, that is, what’s good and what needs to be improved.

“To be” maps are based on hypotheses. You need them when your goal is to design a new user experience during new product development.

— How granular should the maps be?

— Granular enough to help you meet your objectives. Begin with higher-level granularity because it’s just less resource-consuming. Then, go deeper, but make sure your map remains descriptive.

A map is a touchpoint. It’s a storytelling means. It helps you communicate things that you can’t perceive if non-visualized.

— When I mentioned different CJMs, I meant exactly the customer journey map. There are also life experience maps and the user journey map. Do they relate to the CJM?

— All these notions are techniques. There’s a technique originally called the customer journey map, but then others appeared when people started using it for other tasks beside the user journey mapping.

Most people interchange these titles just because they don’t care. They don’t see the difference, and that’s okay.

When it comes to differences of the UJM from the CJM, this 1% of opinionated people can tell you that the user journey map is an experience map within your product, this is a user map.

Customer journey maps are a more multifaceted thing. It not only encompasses product usage, but also the purchase of the product and user actions when they stop using it.

— Are there other, more fundamental differences?

— No. Most people using this technique can just say: “I’m designing the customer journey map”, regardless of who’s this map for (if not the customer), let it be a patient or a student.

— How is Service Blueprint integrated into this system?

— Service blueprint is a fancy term for business processes’ descriptions. The terms “business processes” and “business process maps” are the same. People who prioritize people should design the CJM first. When designing the CJM, If you see processes that you can improve, you should design the Service Blueprint.

Do you wonder why I go top-down? People think the CJM reflects the customer interaction with a business. The Service Blueprint is what happens inside the company at the so-called backstage.

The purpose of this technique is to turn the light on inside the company and ask yourself “Who here supports and develops the customer that we’re doing all this for?”.

The Service Blueprint shows why customers may churn at different stages of the CJM.

Let me share my personal experience I had with a carsharing service. I couldn’t receive the activation code and contact customer support. I desperately needed this code, so I went to their website to contact support there. But they only replied, “Try again”.

This is how my customer experience was ruined. I still don’t use this carsharing as I don’t have the activation code. They couldn’t help me. I chatted with their customer support for two weeks, but once they went silent and stopped answering my questions.

What was wrong here: the app didn’t work, and the support didn’t do anything to keep me satisfied. The Service Blueprint could help see this issue.

— When should a company make it to building the Service Blueprint?

— You need to balance processes, people, and resources internally to ensure the best customer experience. This is the moment to start using the Service Blueprint. It should be used when a company sees its growth area and appreciates the need to work on it.

Let me give you a simple example. Suppose customers ask the customer support a lot of questions. The company decided to hold onboarding sessions as a potential solution to this issue. Here comes the question: who’s in charge of onboarding customers? Sales reps? Future account executive? Someone from the support team? How should this onboarding be provided?

Company management may say “Hey, listen, we don’t have the time for that. We need to establish the whole account management institute, but we don’t have resources for that”.

These issues occur at the intersection of different teams when tasks are passed from one team to another. This is where the Service Blueprint comes into play.

Not all companies, I should say, need the full Service Blueprint map. It may work fine if you just add a couple of fields to the CJM and call them “Responsible team”. The CJM is not tightly structured, unlike physics or maths. You can add anything helping you with your issues, including things related to the Service Blueprint.

— What would you say about personas? You can design maps based on buyer personas, user personas, or behavior patterns. When should you emanate from roles or user stories?

— First, we can combine these three terms: a user persona, a buyer persona, and user stories. The persona approach implies segmenting the audience by matching behaviors. If people act in similar ways, we group them together. These are basic implications.

User personas typically use the product. Employ this approach if you aim to improve your product experience.

Buyer personas are the ones buying the product. Use this technique if your goals are improved marketing and sales.

The same person can buy the product and use it, but they can demonstrate different behaviors. Plus, people may buy in the same way, but act differently.

Buying and using are possible behaviors. That’s why I will temporarily combine these three notions and say your character choice depends on the goal of your map.

— How important is it to divide personas by roles?

— Roles are an attempt to segment the target audience. In a company, roles are positions (marketers, product managers, etc). We can only assume that a person performs certain functions if their role is a product marketer, and different functions if they are a CEO. It’s not always like that.

Dividing personas by roles helps us keep our business things in order and negotiate.

The roles and functions approach only works if no mistakes occur. Unfortunately, when you have many users, dividing them by roles may not be enough.

We can call a person a product marketer only implying typical behaviors and not their position. In this case, we’re talking of personas though calling them by their roles.

— I know from Nick (Editor’s Note: Nick is a Chief Product Officer at UXPressia Academy and Product Advisor at UXPressia) that you design maps based on types of thinking. How does that work?

— There are people with extraordinary ways of thinking about why design maps. They do it in their own ways. We discovered them recently, described their mindsets, and portrayed them as our personas.

A mindset is a way of thinking. It shows how people design maps, what notions they speak in, and what are their issues.

We found three mindsets:

The first one is UX/Service Design mindset. These people speak in workflow and process terms (including their modifications). They see issues with customers’ eyes, speak in their words, and design maps based on their notions.

The second is the CX/marketing mindset. They think in marketing concepts. Their maps are based on marketing or sales strategies. They are all about marketing campaigns, channels, and KPIs.

The third one is the IT mindset. Disclaimer: this is an internal title not related to the common understanding of IT. IT mindset owners think in terms of systems, services, and technical frameworks. They probably have a technical background.

— How did you define these categories?

— This wasn’t an easy process. We did nearly 40 in-depth interviews, hundreds of surveys, and considered several maps. At some point, we decided to run a self-identification survey. As we got close to 10k observations, we started to validate them.

— Do you prioritize all three mindsets?

You can’t create a product for everyone, that’s clear. We’re going to consider what people use our product, how satisfied they are, and what their mindsets are. This will help us evaluate the market. Then, we’ll use this information to determine our focus.

Our main objective is to ensure the best user experience at the lowest cost.

— As we draw to a close, could you tell what people should consider if they only begin designing maps? How to tell what map they need to design?

— First of all, you should appreciate why you need the map before you choose the map you’ll design. You should emanate from your objectives. It all starts with an objective which is your business issue.