What Is a User Journey Map? How to Use It in Website Design

A user journey map is a visual summary of the steps, thoughts and feelings a visitor goes through while trying to reach a goal on your website. In this guide, Talha Aslan and team explain how we build one, how we pick personas and touchpoints, and how we turn the finished map into a real page structure.

Nielsen Norman Group defines a journey map as a visualization of the process a person goes through to accomplish a goal. In other words, it is not a flowchart. For example, a flowchart shows the order of screens. A journey map shows what a human experiences on those screens. That difference matters in web design, because the same page can raise very different questions for two different visitors.

What are the parts of a user journey map?

A useful map rests on a few fixed layers. These layers keep the map readable and help the whole team speak the same language. In practice, this is the structure we rely on most:

• Actor: The persona who lives through the journey. Each map therefore holds one point of view.
• Scenario and expectations: The situation the actor is in and what they hope to get.
• Phases: High level stages such as awareness, research, decision and contact.
• Actions: What the user actually does in each phase.
• Thoughts and emotions: Their questions plus one emotional line across the phases.
• Touchpoints: Every place where the user meets your brand.
• Opportunities: Improvement ideas, each with an owner and a metric.

In addition, we add one more row on web projects: "related page or component." This row ties the map directly to design work. That way, you can see at a glance where each phase lives on the site.

How does a journey map differ from an experience map and a service blueprint?

Teams often mix these tools up. However, each one answers a different question. An experience map describes a general human experience and does not belong to any one brand. A user journey map focuses on your product or website. A service blueprint shows the internal processes behind the same journey, seen from the company side.

In practice, the journey map is the tool you will reach for most. The experience map helps with big strategic questions. The blueprint becomes useful once forms, quotes and support processes get complex. On small and mid sized web projects, one well built journey map often uncovers most of what the other two tools would reveal.

In short, the journey map bridges discovery and execution. First you understand the user, then you translate that understanding into screens.

Why do you need a user journey map in website design?

Most web projects start with a menu list: about, services, references, contact. That list reflects the order in which a company likes to present itself. Visitors, on the other hand, arrive with their own questions. A user journey map lets you compare those two orders side by side.

For example, a visitor first asks, "Does this company do what I need?" Next they wonder, "Can I trust them?" and "How does the process work?" Once the map shows the order of those questions, you build the page structure in the same order. So visitors stop hunting through menus for answers.

The map also calms internal debates. You answer "Should this section go here?" by checking the phase on the map, not by personal taste. If you want the broader picture of what user experience covers, start with that guide; here we stay focused on the map itself.

What data should you gather before drawing the map?

A map is only as strong as the research behind it. A map drawn from desk assumptions simply dresses up what the team already believes. Therefore, collect your sources before you start drawing:

1. User interviews: Hold short, open conversations with current and potential customers.
2. Sales and support notes: List the most common questions and objections.
3. Analytics data: Review landing pages, exit points and form steps.
4. Site search logs: See what visitors look for in their own words.
5. Competitor review: Understand which other sites users visit while comparing.

A project brief is a good place to pull all of this together. If you follow the questions in our guide on how to write a website design brief, you will also gather most of the raw material for the map.

Which persona should you choose, and how many belong on one map?

A persona is a fictional but realistic character that stands for a target user. According to Nielsen Norman Group's guidance on personas, a persona should come from research and carry only the details that serve design. Age, job, goals and behavior help. Hobbies, however, usually add noise.

Stick to one persona per map. If you put two people on the same map, the emotional line stops making sense, because one may feel calm while the other struggles. If you serve several important groups, draw a separate map for each one.

So which persona comes first? In practice, start with the group that drives your business goal the most. For instance, on a site that runs on quote requests, that person is often the manager who makes the buying decision. Then add the second group.

How do you write the scenario and expectations?

The scenario describes the situation in which the persona starts the journey. A good scenario is short, concrete and tied to one goal. "The user browses the site" is not a scenario. "A purchasing manager needs a new supplier within two weeks because the current one keeps missing deliveries" is a scenario you can work with.

The expectations row captures what the user hopes for. Think fast replies, a clear process and convincing proof. After that, this row defines what your pages must promise.

• Write the scenario in one sentence.
• Add context such as time pressure, budget or risk.
• Quote expectations in the user's own words from interview notes.
• Use a separate map for each scenario.

How do you define the journey phases?

Phases form the skeleton of the map. Most maps have four to seven, but there is no strict rule. What matters, above all, is that each phase marks a shift in the user's mind.

For a corporate website, we often use these phases. The user notices the need, searches for a solution and gets to know the company. Then they compare options, make contact and wait for a reply. In ecommerce, phases tend to run from discovery to product review, cart, checkout and delivery.

Do not name phases after internal processes. "Lead generation" is your language; for the user, that moment is "asking for a price." So write phase names from the user's side. This also keeps you from confusing the map with a conversion funnel: the funnel tracks company measurement steps, while the map shows the human experience.

What are touchpoints, and how do you list them?

A touchpoint is any moment when the user meets your brand. In web design most touchpoints are digital, but not all of them sit on your site. Search results, map listings, social profiles, email and phone calls belong to the journey too.

To build the list, ask for every phase: "Where does the user see us at this point?" Then add two notes next to each touchpoint. What does the user want here, and what do they find right now? In other words, the gap between those notes is the design work itself.

• Search result title and description.
• Landing page and first screen.
• Service or product detail page.
• References, case examples and reviews.
• Contact form, chat or phone button.
• Thank you page and automatic email after the form.

Teams forget the thank you page surprisingly often. Yet that is exactly where the user worries, "Did my request go through?"

How do you add the emotion curve and pain points?

The emotion curve is a single line that runs across the phases. When the line is high, the user feels at ease. When it drops, they feel anxious or let down. This line draws the most attention on the map, because it reveals trouble spots at a glance.

Do not draw the curve from intuition. Instead, pin interview quotes such as "I got lost here" or "I couldn't find the price" to the matching phase. That way, every dip in the curve rests on concrete evidence.

Collect pain points in their own row. A pain point can be technical, like a menu that does not open on mobile. It can also relate to content, like a service page that never explains the process. Sometimes it concerns trust: a missing address, team or case example. Next to each pain point, note which phase it hurts. As a result, the deepest dips in the curve become the first items on your fix list.

How should you prioritize pain points?

A map usually surfaces more pain points than you can fix at once. That is normal, but attacking everything at the same time wears the team out. To set priorities, ask three questions about each item. How many users does it affect? How critical is the moment where it appears? Does it stop the user completely?

For example, a broken submit button on mobile cuts off the entire contact phase. Therefore, it comes long before a misaligned icon. On the other hand, small copy fixes take little time and can noticeably improve trust. So put the items that are both critical and quick at the top of the list.

How do you fill in the opportunities section?

The opportunities section turns the map from a presentation slide into a work plan. Write at least one opportunity for each pain point. However, frame each opportunity as a need, not a solution. Instead of "add a big button," write "the user wants to see a price range on the first screen."

Then give every opportunity an owner and a metric. Specifically, the owner is the person or team doing the work. The metric tells you how you will know the change worked. Examples include form completion rate, exit rate on the relevant page or the number of repeated questions reaching support.

Finally, rank opportunities by impact and effort. High impact, low effort work goes into the first release. You then schedule the rest for later phases. This ranking should line up with your website conversion goals.

How do you turn the map into a page structure?

This step connects the map to actual web design. You take the user question in each phase and decide which page or component answers it. Then you decide how those pages link to one another.

In practice, this table is the first draft of your sitemap. Use the principles of information architecture when you set up the menu and page hierarchy. That way, the order on the map also shows up in the navigation.

Example scenario: how do you map a quote request journey on a corporate site?

This section is an example scenario; it does not describe a real client. Picture a company that makes industrial packaging. Our persona, Selin, is a purchasing specialist at a mid sized manufacturer. The scenario: her current supplier keeps delaying deliveries, and she must get a quote from a new supplier within two weeks.

1. Awareness: Selin types the product type and the word "manufacturer" into a search engine. She feels neutral, but she is under time pressure.
2. Searching: She opens three sites. On ours, the first screen shows only a slogan, and she cannot find her product type. The emotion line drops.
3. Getting to know us: She finds the products page through the menu. However, it lists no minimum order quantity or production capacity. Her worry grows.
4. Comparing: A competitor lets her download a spec sheet. Our site asks her to send an email for it.
5. Contact: The form has twelve fields and feels hard on mobile. Selin abandons it and decides to call instead.

In other words, the site did not lose Selin, but it made her work harder. The value of the map lies in making this kind of friction visible.

Which design decisions came out of the example map?

Let us continue with the same example scenario. Every dip on the map turned into a design decision. The team then ranked those decisions by priority:

• First screen: A clear headline listing product types and served industries instead of a slogan.
• Product page: A fixed info box for minimum order, capacity and lead time range.
• Spec sheet: A document users can download without a form, next to a short quote prompt.
• Form: Four required fields plus an optional notes box.
• Thank you page: A clear message about reply time and the next step.

Notice, however, that none of these decisions concern color or typefaces. A user journey map fixes structure and content first; the visual language then sits on top. For wording and placement of calls to action, see our guide to CTA buttons. If you want to turn a map like this into a new site structure, our web design service covers the full path from research to page plan, and we build it together with you.

How does the mobile journey differ from desktop?

The same persona in the same scenario lives through a different journey once the device changes. On mobile the screen is narrow, attention splits and the connection may be weak. That is why you should treat the mobile journey as its own row, or even its own map, for key personas.

On the mobile map, look closely at a few questions. How many scrolls does the user need to reach the answer? Can they fill in the form fields comfortably with a thumb? Do the phone and message buttons stay visible in every phase? For example, a comparison table that works fine on desktop may become unreadable on a phone.

Also add device switches to the map. A user may discover the product on a phone and fill in the quote form later on an office computer. In that case, they need an easy way back to what they saw on the phone.

Also, small details make that switch easier. An option to email the spec sheet to themselves, a saved product list or memorable page addresses all help users find their way back. Mark the device change on the map with an arrow and note the need at that point. Then the design team will not overlook that moment.

Where does accessibility fit on a journey map?

Accessibility is not a separate project. It is a condition users meet in every phase of the journey. For a visitor who navigates by keyboard, uses a screen reader or has low vision, barriers appear in different places. So add at least one point of view that represents an accessibility need to your persona set.

The W3C WCAG guidelines are the international standard for making web content usable for people with disabilities. In the pain points row, use them to check form labels, clear error messages, focus order and color contrast.

As a result, you catch accessibility issues during design instead of after launch. For the basics, read our article on web accessibility and WCAG.

How do you run a journey mapping workshop?

You usually build the map in one or two working sessions. Preparation decides whether those sessions pay off. Before the meeting, send participants the research notes, the draft persona and the scenario. That way, the session goes into interpreting data rather than reading it for the first time.

We suggest splitting the session into three parts. First, place the phases and actions. Second, add thoughts, emotions and pain points. Third, write the opportunities and rank them.

• Keep the group small; a mixed team that can make decisions is enough.
• Assign one facilitator who keeps the discussion anchored to the phases.
• Write the source next to every claim: interview, analytics or support ticket.
• Move ideas without a source into a separate "to verify" area.

For instance, if sales says "customers always ask about price," match that against support logs. If it matches, it goes on the map; if not, it waits on the verification list. As a result, this discipline keeps the map trustworthy.

How does the map shape your content plan?

A user journey map shapes the words on your pages, not only the page skeleton. The thoughts row in each phase is really a list of questions. Those questions can become subheadings on service pages, FAQ entries and blog topics.

For example, "How long does this take?" in the research phase leads to a section that explains process steps. "Why this company?" in the comparison phase turns into case examples and a description of how you work. So the content team reads what to write from the map instead of guessing.

Also try to keep the user's language in your copy. If users say "price range" in interviews, do not write "investment options." Put simply, the best headline is the sentence already in the user's head. This approach helps readability and also helps your pages match real searches.

How do you validate the map with analytics?

A map is a hypothesis, so you need to test it with data after launch. First, set one measurement point for each phase. For example, track the move from the landing page to a second page for the search phase. For the contact phase, track form start and form completion events.

Next, check whether the dips in the emotion curve also show up in the data. Is the exit rate really high on the page the map flagged? Do users abandon the form halfway? If the data supports the map, your priorities are right. If it does not, either the map misses something or the tracking needs work.

On the other hand, numbers do not answer "why." Therefore, pair quantitative data with short usability tests. For a deeper review, our UX audit process works well alongside the map.

What are the most common user journey map mistakes?

The mistakes we see most often come from how teams prepare the map rather than from the map itself. Share this list with your team before you start:

• A map without research: Presenting team assumptions as the voice of the user.
• A persona for everyone: Merging several user groups on one map.
• Phases in company language: Writing the sales team's steps instead of the user's.
• Opportunities without owners: Leaving improvement ideas unassigned.
• Draw once and forget: Leaving the map in a project folder with no updates.
• Looking only inside the site: Skipping outside touchpoints such as search results, email and phone.

What these mistakes share is treating the map as a deliverable. Instead, the map should be a living tool that guides team decisions.

What belongs on your prelaunch checklist?

After you turn the map into a page structure, tick off this list before the new design goes live:

1. Each persona has at least one map, and each map ties to one scenario.
2. Every phase question has its answer on a specific page or component.
3. The first screen answers the visitor's question: "Am I in the right place?"
4. Trust signals appear before the decision phase.
5. Your form asks only for fields you truly need and works well on mobile.
6. The thank you page explains reply time and the next step.
7. Accessibility barriers listed on the map went through hands on testing.
8. Analytics has a measurement point for every phase.
9. Every opportunity has an owner and a target metric.

The list looks short, because each item stays focused. Still, each item closes a breaking point in the journey. If you cannot tick an item, go back to the map.

How often should you update a user journey map?

There is no fixed calendar. Update the map whenever your business or your users change. In practice, reopen it when you add a new service or product, when your audience shifts, when you redesign the site, or when analytics shows an unexpected drop.

Repeated questions from support and sales also signal that an update is due. If the same question keeps coming in, that phase of the map has a gap. This view fits Google's guidance on helpful, people first content: a page should answer the question the visitor actually asks.

Keep the map where the whole team can reach it. A file buried deep in a project folder fades from memory fast, so link it from a shared board or a document the team opens every week. In addition, add a short change note with each update. Which phase changed, which data triggered it and which pages did it affect? These notes help you remember the reason behind a decision months later.

Above all, keep updates small. Rather than redrawing the whole map every time, update the changed phase and the related pages. That way the map stays a working document in the team's hands.

How can we build this into your site together?

You can create a user journey map with your own team; the steps in this guide give you a solid start. However, when the same team handles research, mapping and page planning, decisions reach the design without getting lost along the way.

On our projects, we usually follow this order. First, we collect existing data and interview notes. Next, we agree on the persona and scenario with you. Then we draw the map, rank the opportunities and translate them into a page structure. Finally, we launch the design with measurement points in place.

If you want to build your new site structure this way, you can request a quote from our web design service page. A short note on your target audience and the main action you want from the site makes the first conversation far more productive.