Customer Journey Map, Flows and IA
Enterprise UX case study (part 3).
Hello 👋, Aliaksei is here) This is the third article about crafting UX artefacts to the need of the product. We continue to discover the redesign of the EPAM’s time-off management system — Vacation portal. The first part—‘Value of the design artefacts and how to make Personas work’, the second — ‘Problem statement, Value Proposition Canvas and Hypotheses’.
Let’s discuss some practical aspects of creating CJM.
Customer Journey Map (CJM) is an approach to systemize and visualize the travel a user takes to get a beneficial outcome in the product.
As you can see, I treat it wider than a UX artefact.
Why do we need it?
It is a good way to analyze the user’s flow in the product. With it, we could shine a light on the user’s problems and help the team to solve them.
How could I explain the concept of CJM to a newbie?
Image a classic fairy tale—we have a Hero, the Place and Actions, required from the Hero to achieve his Goal.
If you will try to make it all on a single piece of paper, as a linear sequence, you’ll get a timeline with events.
Our hero is a Persona.
His action steps are gathered into Scenarios.
The product is a Place for the actions.
The Goal is the desired outcome for the user.
To make our Journey mapping more precise, better to take a single hero and a single scenario with a definite goal.
Examples:
A warrior, rescuing the princess from a dragon in the dark castle.
A zoomer, buying running shoes in the online sneakers store.
Well, the second story looks not very exciting… but you got the point.
Some details about what the designer could add to the CJM:
- Channels — how a user comes to the product.
- Pains/gains—here your work could be eye-opening to the stakeholders.
- Emotions—in some cases, it’s useful to analyze a user’s feelings on the steps.
- Points to improve—the place to gather the insights, how to make the journey better.
- Other—any part, that will help to understand user’s behaviour.
Where to do the CJM?
It depends on the product’s environment.
If you could do it with a team, stickers and board—great.
If you are in the remote team, it’s better to make it in Miro, or another web service.
Often it is done simply, without graphics, in Excel or Spreadsheets. Team members could add their impact in the cloud.
In Miro, CJM process is far more collaborative, with digital stickers and wide interaction with a team.
By my experience, the best way to learn how to build the CJM—simply do it, validate, fix the mistakes, and repeat.
Tips for better CJM
Before (re)making any digital artefact, try to understand the existing solution. Even if you are doing a product from scratch, usually you have a competitor’s product.
- Designer as a QA of the product. At this stage, you know basic information about users. Test it, try it, explore the behaviour of the user. What are the limitations? What are the channels for the user to interact with your product? How does he use it? The platform, device? How much content could be consumed from an old low-res screen? What is the average speed of his actions? What external factors are influencing him?
- A designer could use templates, but templates shouldn’t use the designer. A template is not dogma, it could be disassembled to understand the logic.
- Only good Scenarios are boring even in tales. Analyze not only the shortest paths, win-win situations. A user buys the goods quickly, nothing to improve… Really? Imagine the tale without conflict and problems for the hero. Does anybody like such kind of story?
What if the user gets a problem in the middle of the process? How to resolve an issue? How to give the user feedback about issues? How to get help in the service? What if the connection lost during the request’s submittal?
- CJM is not a solo play, the team is needed. A good designer always tries to involve other teammates in the work on it. Explains the rules of work, marks important points in the process. Accepts routine of making the notes, uses ideas of teammates.
- The research data is a free pizza for all. Sounds obvious, but there are issues with that point. Our designer makes the results of the research comprehensive and accessible. Team members should be on the same page, especially in understanding user’s needs.
- A single map isn’t supposed to look like a country budget. It’s not good to have a wide artefact without focus. But when people use a microscope to get some details, that’s doesn’t make any sense.
How to show value
Often we, designers, are focused solely on user’s needs. Sure, the designer is a user advocate, but usually business isn’t evil. So we could find a good solution for both. Remember about the value loop.
Your manager is clever but busy. Help him get the context of CJM without unnecessary details. The management shouldn’t get the outcome of the CJM out of the blue.
The CJM itself is not a result.
Good designer involves stakeholders in the process.
And usually, he does it peacefully). Maybe, they would not participate deeply, but their attention is important. Without this, the risk of hitting the wall (misunderstanding) is very high.
Our designer wouldn’t have hours to tell every detail of the CJM to the C-management. Only the important stuff presented: results, problem points and points to improve, verified insights, etc.
Result
After making the CJMs for main Personas, I had almost all the cards in hand.
The team was aligned, the design process was established, users and their needs were discovered. And we have almost all the crucial flows of the user in the service built by words.
Managers also gain a product view, current problems assessment and see the possibilities for improvement of the solution.
Flows
In some cases, it’s necessary to make the most problematic current flows more visually appealing to stakeholders.
Below you can see an example of the flow for the user to take a time-off in the original system.
Too many ways to do the same thing (book a leave). Messy flow, fragmented requests forms.
Reworking such flows with stakeholders and users helped us to get the next solution.
At first, some stakeholders were surprised, that it could be so simple—you could take any request in any place.
How to show value
If the designer could simplify the user flow, tests it with users, this data could give arguments to sell the idea to stakeholders.
To do that, necessary to look at them—some people could be persuaded by numbers, better conversion rates, etc. Others accept qualitative research data.
Clear UX flows, presented by the designer, help to win both types of stakeholders.
Result
The new service concept where a user is in power on any page, easily switches between the variety of request types was unanimously accepted.
Information Architecture (IA)
It was high time to continue radical changes.
Researching, I already saw a lot of issues in the navigation of the service.
I made an expert review, analyzed the structure of the information in the service. To highlight issues, I took prioritized Personas and did sitemaps for them.
Below is the sitemap for the original navigation for the Administrator, who could do everything in the service.
Stakeholders clearly saw the problem with navigation: duplicated elements, difficult orientation in the service, and other IA issues.
After decomposition, I understood the links and interconnections in the service. We made a card sort, to see essential navigation elements and what could be removed.
Below you can see the result of the work—improved navigation for the Administrator.
How to show value
On the team demo, I could defend my decisions, using the researched data. The accessible and comprehensive audit report helped to rework the Information architecture. As the team was involved in the card sort, their opinion impacted the result.
Working with information to the user with PO, we applied a new approach to giving the user the necessary power. After improving the navigation and flows, we could gather everything in one place.
Result
The change was supported by team members. In the demo, they actively participated, by themselves answering on some sceptical questions about navigation. We eliminated almost 70 % of the previous structure, gaining clarity and functionality.
Most of the existing back-end solutions were supported, that was especially appreciated by management.
We moved step by step, applying UX techniques in the redesign process.
With developed and prioritized Personas, we understand key users.
Making Value Proposition Canvas, the designer finds the balance between the needs of the user and business.
The Problem statement helps to reduce the risks of solving the wrong problem of the product.
Working on Hypotheses builds the basis for finding the right answers.
Building CJM and Flows is connecting the dots between the user, existing problems, product and behaviour.
Analyzing Information architecture, the designer acquires the logical and clear structure of the product.
We were ready to make the UI and implement our design.
Outcome
Let’s look at the original service main page.
In the redesign, based on the result of the research, we changed the approach user’s starting point.
We used the good-working pattern: the user wants to make all his actions in a single place. If he needs the details, he could have them here.
All actions for the leave could be done in the Dashboard. Navigation is simpler, too.
Sometimes users were in trouble because they don’t know the rules of different types of time-offs. Previously, to get this info, they needed to go to the external knowledge base. We give them a handy ‘cheat sheet’ for terms, numbers, etc.
Sure, the rules for time-offs are complex, and often people don’t know the legal information.
To aid new people quickly get the point about business workflow, details and align it with a new service, we wrote a short and concise User guide.
Previously, to take a specific request, the user needed to go through complex navigation to find a form. We totally reworked the request forms, the user now could take any request from any place.
We used sidebars as the main approach to have all items underhand. Also, the approach to the legal notes and informers was changed—only essential info is shown.
All these changes (and many others) helped both users and business.
Our product was successfully released for more than 12,000 users in Belarus on 09 November 2020. Afterward, we had a launch in Ukraine.
We got excellent feedback about the changes. Users loved the clearness of the new design, appreciated the handy possibility of quick access to the request details, etc. As a result, support tickets dropped heavily.
The lessons I’ve learned during the implementation are waiting for you in the ‘From UX to UI: implementation insights that matter’ article.
Thank you for reading!
I hope, my articles helped you to move a step closer to the Goal — making a good digital product, valuable for users and business.
Feel free to connect with me on LinkedIn!
