CJM in 30 minutes: a map of the user’s path that is actually used in the work

Open any Miro board that says “CJM” in the title. With an 80% probability, you will see a beautiful multi-colored sheet with 12 columns, which was made six months ago, showed once at the strateshoot and never opened again. Sometimes even the user’s emotions are drawn by a curved line, but there are no decisions based on it.

CJM as an artifact stopped working long ago. CJM is a thinking tool that works every time a team sits down and sorts out a scenario in half an hour. The difference is that in the second case, no one is trying to describe "the whole user journey" - just the specific piece that hurts right now.

This article is about the second option. About a map that is made quickly, dirty and on the job. Not for the portfolio, but for the next day in the sprint there is a task that was not before.

## Why Long CJMs Don’t Work

Classical logic: “Let’s describe all the way from the first touch to the second purchase, find the pain, prioritize.” Sounds right. In practice it breaks down on three things.

When the map covers 8 stages and 5 channels, one word is left in each cell. This is no longer a diagnosis, but a table of contents.

**No owner of the problem. There are pains, and who solves them is unclear. The map hangs on the designer’s wall, and the problems are in the areas of support, marketing and product responsibility at the same time.

Made once. Real product changes every sprint, CJM doesn't. After two months, the card is lying, and the team knows it. That's why they don't look at it.

In 30 minutes, the card treats all this automatically. A narrow scope, because you won’t be able to do it again. The owner is the one who initiated the card. Relevance - because it is not a pity to throw it out and make it again.

## When to do CJM and when not

Before calling the team into a negotiation, check yourself.

** Worth doing if:**

• In the metrics you can see subsidence on a particular step, but it is unclear why
• Support receives similar complaints for weeks in a row
• The team argues “the user has a problem or not” without a big picture
• Launch a new feature and you need to understand what it is built into
• We just had interviews and raw insights need to be put into something

Not worth doing if:

• The problem is already clear and you just need to solve it – sit down and solve it
• There is no data, no interviews, no access to users – there will be a fantasy, not a map
• The goal is to “make a beautiful artifact to present to management.” It's not CJM, it's a slide

The main sign that CJM is not needed is that you already know what to write in each cell. Then it's just fixation - not an instrument of thought.

## Minimum set: what should be in the card in 30 minutes

Forget about templates from the Internet with 14 columns. Five is enough for a work card.

### 1. Script steps

Specific user actions, not abstract steps. Not "Awareness - Consideration - Purchase", but "saw the push - opened the application - hit the main one - clicked on the banner." The level of detail is such that each step can be shown in a screenshot.

### 2. The user's goal at this step

Which he's trying to do right now. Not “getting value from the product,” but “getting to know how much it costs to get to my city.” If it is not possible to formulate a goal for a step, then the step is superfluous or you invented it.

### 3. What he does and sees

Action + interface. Here are the channels (application, email, call in support). It’s an anchor to reality: if you don’t have anything in the product at this point, it’s insight.

### 4. Pain or friction

Not an emotion in general ("irritated"), but a specific obstacle: "does not see the button", "does not understand why they ask for a passport", "waits for 40 seconds to load." The pain should be such that it can be turned into a task.

### 5. Opportunity

What can we do about it? One or two hypotheses a step, no more. If there is no idea of pain, it is normal to leave it empty. It’s better to have an honest blank field than to “improve UX.”.

Okay. No "mindsets," "touchpoints," "backstage actors" or anything from textbooks. They can be added later, if the truth is needed - usually not necessary.

## Workflow: How to keep up with 30 minutes

Thirty minutes is not a metaphor. This is a strict restriction that forces you to cut excess. Break the time roughly like this:

• **5 minutes to negotiate the scope. One scenario, one segment, one context. Write on the blackboard with one line: “New user makes the first order from mobile”.
• **10 minutes - take steps. Stickers, markers, no discussion. Until the steps are finished, do not get into pain.
• **10 minutes to fill in pain and observations. Here you need data: quotes from interviews, screenshots from analytics, support tickets. Without them, we honestly write a hypothesis.
• **5 minutes to mark what we are doing. Not “discuss later”, but specific lines → specific tasks with the owners.

If there are more than three people on the team, choose one who holds the marker and pace. Otherwise, after 40 minutes, you're still arguing about the name of the first stage.

### What to bring with you to the session

• One or two raw interview transcripts or at least quotes
• Screenshots of key screens of the script
• A funnel from analytics on this float
• List of recent complaints from support on the topic

Without it, CJM becomes a collective fantasy. With this, into a tool.

## Diagnosis: what to look at in the finished map

The map is ready. Don’t hang it on the wall, run it through diagnostics first.

### Questions for the audit

• At what point is the pain three times worse than the rest? It's a bottleneck. That's where we go.
• Is there a step without pain? Check it out twice: either it’s really good or you don’t know anything.
• Is there pain without step? The “waiting between two actions” often pops up, a separate invisible stage we missed.
• Can each pain be rewritten as a backlog task? If not, the wording is too general.
• Can you see where the user switches the channel (app → mail → call)? Channel joints are the most unproven parts of any product.

### Signs that the map turned out

• At each step, the user’s specific goal is visible, rather than “getting an experience.”
• There is at least one quote or number in the pain column, not just an interpretation
• From the map 2-5 tasks were born, each has an owner
• The team argues not "whether it's true," but "what to do about it."

## Typical errors and anti-patterns

** Map as a retelling of the interface.** Steps word for word repeat product screens. Then CJM doesn't add anything - you already have Flow in Figma. The map should show not what is, but where it breaks.

**Pain level "user irritated."**Emotion is not a diagnosis. Then it is necessary to dig: what exactly is irritated, at what moment, what exactly saw. Otherwise, the task will be the same blurred - "to improve the experience.".

Hypotheses instead of data unmarked. The team discusses the step for half an hour, agrees that "there's definitely a problem" and writes it down as fact. After a week, it turns out that everything is normal in the metrics at this step. Mark hypotheses right in the map - at least with the question icon.

**A map with no next step. **Done, discussed, separated. After a month, no one remembers what they decided. Rule: We leave the session with a list of tasks in the tracker, not with a photo of the board.

Designer makes CJM alone. You can, but this is no longer a CJM, but an analytical note. The power of the map is that different roles see one picture at the same time. Without product, support, and analytics, you’ll only get half the truth.

## How to transfer the map to the layout and product

The map itself does not change anything. It changes what you do the next day.

### From step to screen

Take the step with the most intense pain and open the screen in Figma that matches it. Put it next to you. Next for each pain is one of three solutions:

• Changing the screen. The pain is solved by the interface: add a hint, rewrite the button, remove the field. It's a straight path to the layout.
• The pain is not on the screen, but in the order of steps. Then we rule not the pixels, but the structure: move the step, combine, remove.
• Pain outside design: email from marketing, support script, return policy. It's not your job, but you still need the owner of the pain.

### Checklist before going to the layout

• I understand the specific pain this change solves
• I know how I know what’s better (metrics, feedback, test)
• The change does not break the next step of the script
• If the pain was a hypothesis, there is a way to test it to a major alteration

### When the card lies

Two to three weeks after the changes are implemented, go back to the map and check. If the funnel did not move where it was expected, the map in this place was wrong. It's not a failure, it's a normal cycle. Worse is when the card is not reopened and remains a monument to one session.

## Segment summary

CJM works in 30 minutes not because it is fast, but because it is built into the sprint: narrow scope, live data, clear owner, access to tasks. Everything that gets in the way of this cycle -- extra columns, beautiful frames, no hypotheses -- turns the map back into an artifact. Next, we will discuss how to make such cards in a remote team and how CJM, Service Blueprint and user flow coexist.

## CJM on a distributed team

The remote breaks the main thing for CJM - the total time at one board. On a call, it is harder to catch halftones, it is easier to miss a silent analyst, and the pain from a support chat turns into a screenshot without context. Therefore, the format does not change “the board in Miro instead of stickers”, but the whole format.

### What works in the distribution

• Asynchronous data collection before the call. The day before the session, everyone throws in the common document what he sees from his side: product - hypotheses, support - top appeals, analyst - dips in the funnel. They come with facts, not memories.
• One owner of the cursor. One person moves the stickers on the call, the others comment. Otherwise, the map spreads in six directions and no one remembers who rearranged what.
• Timebox for each block. 5 minutes for steps, 7 for pain, 5 for hypotheses. Without a hard timer, the call goes into discussion of one screen for half an hour.
• ** Recording and transcription. **Not for reporting, but to get back to a contentious place in a week and not reassemble context from scratch.

### Anti-Distributed Card Pattern

The session turns into a brainstorm without data: someone “heard that users complain”, someone “thinks that it’s a long time.” Offline, it's caught by facial expressions, in zoom, it's not. It is treated with one rule: any pain without a source is marked as a hypothesis and goes to a separate “check” column, not to the main map.

## CJM, Service Blueprint and User Flow

These three artifacts are continually confused, especially in teams where they are drawn by the same designer.

• User Flow - What happens in the interface. Screens, buttons, branches. Answers the question “How is the path inside the product?”.
• *CJM - What happens to the user? Goals, actions, emotions, channels. He answers the question “where is it bad and why?”.
• **Service Blueprint - what's going on behind the scenes? Backstage processes, systems, employee roles. Ask yourself why the product behaves this way.

A rule of thumb: if the pain on CJM rests on “here is a long load” or “the manager calls back in two days” – it’s time to draw a piece of Blueprint. If it comes down to “it is not clear where to click” – open the user flow and layout.

## AI and CJM: where it helps, where it lies

The temptation to feed the LLM unloading from support and get the finished card is big. In practice, AI closes narrow tasks, but does not replace a session.

### Where does LLM really accelerate

• *Clustering appeals. A thousand tickets turn into 15 topics in minutes. Then the themes are hung on the steps of the map with their hands.
• Script steps draft. Based on the product description and user role, the model gives a 7-10 step skeleton. This is the starting point, not the final map.
• Reformation of pain into tasks. "Irritating form" → "reduce form to 3 fields, add autofill by TIN". Works well as a review assistant.
• **MCP access to Figma and tracker. ** If configured, you can check in one pass which steps of the card are already covered with layouts and which tasks hang in the backlog without the owner.

### Where AI consistently lies

• Invents pains that are not in the data, because “this usually happens in these products.”.
• Smooths the wording to a common place: instead of “does not understand that the subscription will be written off in 3 days”, it turns out “worries about the subscription”.
• Confidently puts emotions on steps that are actually neutral.

The working rule: AI prepares a draft and summaries, a person makes decisions. Any pain that the model endured, we check by source - quote, ticket, recordings of interviews. No source - transfer into hypotheses.

## How to explain the map to the team and stakeholders

CJM often fails not at assembly, but at presentation. The map is shown as a picture, and the supervisor sees “the designer drew another diagram”.

### Structure of conversation for 10 minutes

1. Scenario and segment in one sentence. New b2b client connects integration for the first time. Without it, the listener comes up with a context.
2. **Two or three points of pain with the source. **Not the whole map, but the hardest one. Each has a quote or a number.
3. **A list of tasks with owners and expected effect.
4. What we don't do and why. This removes half of the objections: it is clear that you weighed, and not seized on the first.

### Questions on which the map is checked

• What would we do differently by looking at this map?
• What in the map is a fact, what is a hypothesis, what is a guess?
• What steps do we not see because we do not have data?
• Who is the owner of each task next week?

If there are clear answers to these questions, the map has been reviewed. If not, it is a presentation, not a working tool.

## Segment summary

Distribution, AI and related artifacts do not change the essence of CJM, but add disciplines: data is collected asynchronously, hypotheses are separated from facts, the model is used as an assistant, not an author. Next, we will see how to build regular mini-CJMs into a sprint so that the map is updated itself and does not turn into a one-time ritual.

## Mini-CJM in the sprint: how the card does not die after the first presentation

The main reason CJM stops being used is because it is drawn once and put in Confluence. After a month, the data became obsolete; after two, no one remembers who collected it. For the map to live, it must be updated in pieces, not the whole.

### Rhythm that really takes root

• Take one scenario or one segment and check 3-4 steps: what has changed in the data, what has been closed with layouts, what pains have surfaced in support.
• Once a quarter - reassembly focus. Does the main scenario change? Is there a new segment? Has the old priority gone?
• Pinpoint - for the feature. Before a major task, draw a mini-CJM 5-7 steps around it. It's cheaper than picking up a big card.

The rule “the map lives where it is visible daily” works well: a Figma file next to the layouts, a link in the project header, a screen on the dashboard. In the archive file, she dies in a week.

## The final checklist: the card is ready to work

• The map has one scenario and one segment, both formulated in the same phrase
• Each step is described by a user action verb, not a screen name
• Pain is separated from hypotheses: next to each pain is the source or mark of the “hypothesis”
• Emotions stand only where there is confirmation, the rest is left neutral
• Each feature has an owner and a clear next step
• The date of assembly and the author are indicated so that in a month it is clear how fresh the data are
• There is a note that from the map is a fact that is a hypothesis, that is a guess
• The map is visible from the team’s work file, not just a direct link

If at least three points fail - the map is too early to show stakeholders, it is still a draft.

## Anti-patterns that are regularly encountered

### Monument map

Huge sheet with 40 steps, 6 channels, 12 segments in one table. It looks impressive, impossible to use. It is treated by splitting into separate cards according to scenarios.

### Painless map

Carefully drawn steps, smooth emotions, everything is fine. Usually it means that the data was not looked at, but drawn according to sensation. If there is no sharp wording on the map, it is a marketing slide, not a CJM.

### Charge card

“At this step, the manager is stupid,” “marketing has adjusted here.” The map quickly becomes a political document, and teams stop bringing honest data. It’s about the process, not the people.

### Map with no next step

After the presentation, everyone nods, disperses, after a week, no one remembers what they discussed. If the card was not born tasks with the owners – it did not work, even if beautifully drawn.

### Map by interview of one person

One conversation with a single customer turns into a card that is passed off as a segment path. At least three sources of different nature: interviews, data, support.

## Questions for map review

These are questions you should ask yourself before carrying a map to the team and the team before taking the map to work.

• What would we do differently by looking at this map?
• At what point is pain the most expensive for the business and at what point is pain the most expensive for the user? Is it the same step?
• What will be the first thing to get out of date in the map and how will we notice it?
• What steps did we draw from feeling rather than data?
• What are we not doing on the map and why?
• Who is responsible for the fact that in a month the map is still relevant?

If half of the questions are unanswered, that’s fine, but these places need to be highlighted on the map instead of pretending they don’t exist.

## Practical outcome

CJM in 30 minutes is not about the speed of drawing, but about the discipline of focus: one script, one segment, honest sources, clear next steps. A map doesn't work when it's beautiful, it works when you take out solutions and tasks every week. Everything else is design.