Hello everybody! My name is Oleksandr, I work at SM Lab as a testing supervisor. Today I would like to talk about such an interesting thing as CJM on a product and how it can be useful for a tester.

Let’s start by defining what CJM is.

CJM (from the English customer journey map) reproduces the path taken by the customer from awareness of the need for the product to its purchase, and sometimes after it. All this time, he interacts with the product and the company and makes decisions based on the experience gained. In other words, it’s a visualization of the customer’s journey through the product

What does CJM consist of?

Description of the protagonist

Received information:

• Browser type

• OS used

• Means of access (mobile, desktop)

• Customer location

This is very similar to the TOR for the product. Such data will help us to understand the client faster – which devices he uses more often: mobile, or also a PC, and if a PC, what operating system does he have. It will also be clear on which browsers to conduct cross-browser testing, which devices and screen resolutions should be taken into account. After all, if your project traffic from mobile devices is only 10%, then, most likely, this part can be sacrificed for the sake of time. And a completely different situation when your mobile traffic will be basic or equivalent.

You should not miss such information as the location of the client. Perhaps the client’s profile will show that he uses the mobile Internet more. Therefore, in the tests, do not forget to see how the site works with weak Internet.

By tracking this information, we can adjust our testing more quickly without waiting for the PO (Product Owner) to come in with updated data.

User goals

Received information:

• User journey map

• Top pages/screens

• Functionality map

One of the most interesting points and the eternal question “Why are we all gathered here?”. This point reveals the end goal the customer has, where and from where he enters the product, where he goes next, and what he does.

Based on this point can be obtained as map of the path itself, as well as the direction the user then took within the product, how they interacted with it. “But these are e2e-tests,” you say. And you will be right. This will again show whether you passed the checks correctly or not. Such information is especially valuable if you are new to the product or receiving it from a contractor. Usually in such cases, time plays against us, and this card is simply a salvation. This allows us not to scatter over the entire product, convulsively deciding what to tackle first.

And if the road map helps us pass the smoke test, then top pages of the product can be used as a starting point for analyzing the speed of operation. You will understand whether you should pay attention to the speed of the project, or ask questions about how often errors occur on these pages. Maybe you need to see if the team has the right metrics.

Functionality map may be part of the product portfolio, but I have often encountered situations where this description is sacrificed. But if you are lucky and this map was provided to you, it will help to make a complete picture about the errors in the project. Which functionality is more buggy, which gives you more errors – front or back.

All this will help to form an idea of ​​where there are more bugs and what should be covered by autotests in the first place. If the unit-test project is poorly written and the business does not see the sense in this, this will be a good argument in your favor.

Stages of the user journey

Received information:

Dividing the user journey into stages can most likely correspond to slicing project teams if the product is large. Let’s say you have an online store. One team will deal with the authorization service, the second with the catalog, and the third with the shopping cart. This logically falls on CJM: each team will have the goal of forming the value of the product at its level and transferring the user to the next one. Knowing these stages, each team understands what value it will bring to the customer and how it can affect the product.

Based on such knowledge, you can build product metrics, the team will have a metric at hand that will show how this or that feature helped the product. In other words, every team makes sense — we don’t just release features, we work on the customer journey, improving their experience.

Such metrics help bring the development team and the business closer together.

Obstacles faced by the user

Everything here is more or less clear, as well as customer support complaints – what problems the customer is experiencing and how we help the customer deal with them.

As testers, we can’t always influence the final product, because in front of us are the product owners and the customers of the functionality in the product. But we can show in testing that customer complaints can increase with this feature, or that we can increase the customer journey. Knowing these difficulties, within the limits of testing, you can pay attention to the specific expectations of the client, each time answering the question: “Do we make the product better or not?”. Check with your PO on support and customer service, it’s a well of not only pain, but test cases you might not have thought of.

Another product metric that is not included in CJM but is extremely useful is this amount of traffic.

Understanding the amount of traffic and some historical data is useful. We will be able to understand if there is seasonality, if there is an increase in traffic, or if there are peak days. All this helps to make a release calendar, and not just sit and repeat the mantra “No release on Friday”. This approach will be more reasoned. If there is seasonality or big sales days, that is also useful information that is better known than not known.

Conclusion

CJM and product metrics are not only a good way to understand a product, highlight its key functionality and mission or value to the customer. It also helps to see exactly how our releases affect the product and customer behavior.

Immerse yourself in business metrics and user behavior scenarios, so you can not only better understand how the customer behaves, but also understand the business itself that brings us initiatives.