How to turn interview notes into a journey map

TL;DR

• A customer journey map is a synthesis artifact: the stages a customer moves through, the pain points at each stage backed by real quotes, and what better looks like. Getting from raw interview notes to that structure is the hard part, not the diagram.
• The method: consolidate your notes into one connected record, extract pain points with the evidence attached, cluster them by journey stage, generate the map, then refine and share it.
• The step most teams do themselves, copying quotes into a spreadsheet and arranging sticky notes, is exactly the step AI now does well, if the notes live somewhere it can reach them.
• Tana generates a Customer journey artifact directly from a transcript or chat: a before/after map with pain points and quotes on one side, the improved workflow and success criteria on the other, ready to edit inline and share.

You ran the interviews. Now you have notes, transcripts, and a deadline to show the team what the customer's journey actually looks like. This guide covers the synthesis step of customer journey mapping: turning interview material you already have into a clear, evidence-backed map. If you are still planning the research itself, start with the upstream companion, How to run user interviews for journey mapping, then come back here. The method below works with any stack, and at each step we show how Tana does the work for you rather than leaving you a template to fill in.

What a journey map needs from your notes

A journey map that survives a stakeholder meeting has three things: stages (the phases a customer moves through), pain points per stage backed by quotes someone actually said, and a direction (what the improved experience looks like and how you would know it worked). Notes alone have none of that structure. Synthesis is the process of adding it without losing the evidence, and it is where most journey mapping efforts stall, because doing it in a spreadsheet takes days and strips the quotes of their context.

How to turn interview notes into a journey map, step by step

Step 1: consolidate the notes into one connected record

Scattered notes cannot be synthesized. Get every interview, the notes, the transcript, the moments that mattered, into one place where they stay linked to who said what. If your interviews ran through Tana, this step already happened: each call is captured and extracted into one canonical summary, and you can pin a running research doc to the meetings so extraction updates that record instead of creating a parallel one per call. Ten interviews become one connected body of evidence, not ten files.

Step 2: extract pain points with the evidence attached

Go through the material and pull out every pain point, keeping each one tied to the quote and the person it came from. A pain point without its quote is an opinion; with the quote, it is evidence. This is the step teams used to do themselves with highlighters and spreadsheets. In Tana, extraction does it from the transcript, and everything arrives as a proposal you review before it is written anywhere, so you confirm each pain point is real rather than trusting the AI blind.

Step 3: cluster the pain points by journey stage

Sort the pain points into the stages of the customer's journey: discovering the product, evaluating it, onboarding, the first real task, and so on. Patterns appear here, like three customers hitting the same wall at the same stage. If you want this structure to persist beyond one project, ask Tana's chat in plain language to create a custom type for it, an Insight type with a journey-stage field and a workflow, and your clustered pain points become a living research base instead of a one-off sort.

Step 4: generate the journey map

With the evidence consolidated and clustered, produce the map itself. In Tana this is one step: generate a Customer journey artifact from the transcript or from chat. The artifact is a before/after map. The before side carries the pain points with the customer quotes that ground them; the after side carries the improved workflow and the success criteria that tell you whether the change worked. You get a structured, presentable map built from what your customers actually said, not a blank template to fill in.

Step 5: refine it and share it

No generated map is final. Edit the artifact inline: merge overlapping pain points, sharpen the success criteria, cut what does not hold up. Then share it via a link or with specific people, with the same access controls as any doc, so the product team works from the map itself rather than a screenshot of it. And when the next round of interviews lands, re-run extraction: Tana updates the existing outcomes and de-duplicates rather than spawning a new summary per call, so the map stays current instead of forking into versions.

What this looks like in Tana

A concrete run-through. You have five customer interviews captured in Tana, each with a transcript and an extracted summary, all pinned to one research doc. You open chat and ask for a Customer journey artifact from the research. Tana proposes it: the before side lists the pain points across the five interviews, each with the quote and the customer it came from; the after side sketches the improved workflow with success criteria. You review the proposal, merge two pain points that are the same complaint in different words, tighten one success criterion, and approve. Then you share the artifact with the product team, and ask chat "which pain point came up most across these interviews" to sanity-check the emphasis, with the answer grounded in what was actually recorded. The synthesis that used to take a week of spreadsheet work happened in the review of one proposal.

If you want the same interviews to feed roadmap decisions as well as the map, the companion guide How to turn user interviews into product insights covers that path.

Where a general chatbot fits

You can paste one transcript into a general assistant and ask for journey stages and pain points, and for a single interview you are analyzing alone, the result is genuinely useful. The limits show up when it becomes team research. The output is prose in your chat session, not an editable, shareable artifact the team works from. The quotes lose their link to the person and the moment, so the evidence is hard to defend. And each transcript is analyzed cold, so the pattern across five interviews is yours to assemble. Tana starts where the chatbot stops: the interviews live in one connected record, the extraction keeps every pain point tied to its evidence, and the journey map is a generated artifact you refine inline and share, one that updates as the research continues.

Frequently asked questions

How do you create a customer journey map from user interviews?

Consolidate the interview notes and transcripts into one connected record, extract the pain points with their quotes attached, cluster them by journey stage, then build the map with stages, evidence, and a target state. In Tana the sequence collapses: interviews are captured and extracted into one record, and a Customer journey artifact is generated from the transcript or chat, with pain points and quotes on the before side and the improved workflow with success criteria on the after side.

What should a customer journey map include?

At minimum: the stages the customer moves through, the pain points at each stage grounded in real quotes, and the improved experience you are aiming for with criteria for knowing it worked. Maps that skip the evidence get dismissed in the first stakeholder meeting. Tana's Customer journey artifact is built around exactly this shape, a before/after map where every pain point carries the quote that supports it.

Can AI generate a customer journey map?

Yes, if the AI can reach the interview material. A general chatbot can sketch stages from one pasted transcript, but the result is prose in a private session, disconnected from the evidence. Tana generates the journey map as an artifact from your captured interviews, keeps each pain point tied to who said it, and lets you edit the map inline and share it with the team, so the AI output is a working document rather than a draft to retype.

How many interviews do you need before making a journey map?

There is no fixed number, but a map built on one interview is an anecdote; the pattern across five or more is where stages and recurring pain points become defensible. The practical constraint used to be synthesis effort, since each added interview meant more spreadsheet work. With Tana that constraint drops: every interview extracts into the same connected record, so adding the sixth interview sharpens the map instead of adding a week of work.

How do you keep a journey map up to date as research continues?

Treat the map as a living record, not a deliverable you export once. The failure mode is a new version per research round, and nobody knows which is current. In Tana you re-run extraction as new interviews land, and it updates the existing outcomes and de-duplicates rather than creating a new summary per call, so the shared journey artifact stays the single current map.

What is the difference between a journey map and an interview summary?

A summary recaps one conversation. A journey map synthesizes across conversations into stages, evidence-backed pain points, and a target experience, which is why you cannot get one by stapling summaries together. Tana produces both from the same captured interviews: one canonical summary per call, and a Customer journey artifact that does the cross-interview synthesis, with the quotes carried along as evidence.