User Journeys Explained

Overview

People don’t experience a website as a series of separate pages. They arrive with something to do.

Someone may want to report a problem, compare university courses, ask for a quote, book an appointment or find and read a specific article. The individual pages they visit matter, but only as parts of something larger. What they remember is whether the website helped them achieve their goal.

A user journey describes the steps involved in reaching that outcome. Looking at those steps together helps organisations understand where people need information, what decisions they must make and where unnecessary barriers may slow them down. It also helps project teams consider how content, navigation and functionality work together to support the complete task, rather than treating every page as a separate item to design or write.

What is a user journey?

A user journey follows the actions and decisions involved in completing a task.

It could be relatively short. Someone might need to find an organisation’s phone number before making a call. It could also involve several stages, systems and interactions over a much longer period.

A prospective university student, for example, could explore courses, compare entry requirements, attend an open day and begin an application. They may then receive emails, provide additional information and wait for a decision. Different departments and platforms might support each stage, but the student experiences them as one connected process.

Depending on the task, someone may need to:

• discover the organisation
• find relevant information
• understand the available options
• make a decision
• complete an action
• receive confirmation
• return for further information or support

The path between web pages is only one part of that experience. A visitor usually does not care how the website is structured internally or which department manages each page. They care about whether they can make progress towards the outcome they need.

A user journey is therefore not just a list of pages. It’s a way of understanding the task from the user’s perspective.

User journeys often begin before someone reaches the website

Organisations sometimes plan a journey as though everybody will begin on the homepage and follow the navigation in a predictable order. In reality, many people enter much further into the website.

People may arrive through a search result, a link in an AI-generated answer, a social media post, an email, a QR code or another organisation’s website. A colleague or friend may also send them directly to a particular page.

Someone searching for a council’s bulky waste service may land directly on a collection page. A prospective student might arrive on an individual course page after searching for a subject.

Any page that can appear in search, be shared or be linked to may be someone’s first page. It should make clear where they are, whether the information is relevant and what to do next.

The wider experience may also include interactions outside the website. A recommendation may create the initial interest, an email might prompt someone to return and a phone call or face-to-face appointment could complete the task.

Looking at the complete journey helps organisations see those connections rather than treating the website as a self-contained experience.

Every organisation supports multiple journeys

Most websites need to support more than one type of visitor and more than one outcome.

A university website may need to support people comparing courses, booking open days, applying and finding help once they have enrolled.

Alternatively, a business website might help prospective clients compare services, ask for quotes or download technical information, while existing customers may return for support or account information.

In all cases, some tasks will matter more than others. They may be completed frequently, support an important organisational objective or involve an area that currently creates confusion or avoidable enquiries.

Organisations do not need to map every possible variation in detail. A useful starting point is to identify a small number of priority journeys by asking:

• Which tasks matter most to the people using the website?
• Which tasks matter most to the organisation?
• Which tasks have the most serious consequences when people cannot complete them?
• Where are people currently struggling, and who may need additional support?
• Which journeys cross several pages, teams or systems?
• Which tasks generate the most enquiries or support requests?

This keeps the work focused on the areas where a clearer experience would have the greatest effect.

A user journey example: making an initial enquiry

Think about someone who wants to find out whether an organisation can help and, if so, make contact.

A simplified journey outline

A fuller journey map would also show what the person needs at each stage, the channels they use, where the route branches and where people may encounter difficulties.

On paper, the route looks simple. In practice, there are several points where the person can lose confidence.

They may land on an outdated page from a search result, then struggle to work out whether the service applies to them. The organisation may describe its services in language that is familiar to its own teams but less familiar to prospective clients or customers.

The next step may take them into a separate form, booking platform or customer system with its own layout and instructions. A form may ask for detailed information without explaining why it is needed. Even after submitting it, the person may still be left wondering whether the enquiry has been received, when the organisation will respond and what will happen next.

None of these problems is necessarily caused by one badly designed page. The difficulty comes from the combined experience.

Looking at the whole task helps the organisation ask more useful questions. Can people tell whether the service is right for them? Do they know how to make contact? Are they prepared for the information they will be asked to provide? Does the confirmation explain what happens next?

Some people will know exactly what they need and move through the journey quickly. Others may need more explanation before deciding what to do next. The journey should support both.

Good journeys reduce unnecessary effort

Common journey problems

Websites can become difficult to use when they reflect organisational structures rather than the tasks people need to complete.

A navigation menu may reproduce departments, teams or internal service names. That structure can feel logical to employees who understand the organisation, but it may offer little guidance to someone arriving with a practical question.

Information can also appear in the wrong order. A page might ask someone to begin an application before explaining the eligibility criteria. A service page may describe the organisation’s expertise in detail while leaving the visitor unsure how to request help.

Other common problems include:

• important actions that are difficult to find
• pages that answer a different question from the one that brought the visitor there
• forms containing unnecessary or unexplained fields
• links that send people backwards and forwards between sections
• dead ends with no clear next step
• confirmation messages that don’t explain what happens afterwards
• essential information held in separate documents or systems
• routes that depend on everyone beginning from the homepage

Problems like these are often overlooked because pages, forms and external systems tend to be checked separately. Each one may work well enough on its own, but the task can still become difficult when someone has to move between them.

What is journey mapping?

Journey mapping is a practical way to record the experience of completing a task.

A map can be a simple sequence of steps on a page or a more detailed workshop output showing what someone needs, does and experiences at each stage. The format matters less than whether it helps the team understand the task more clearly.

The exercise gives people from different departments a shared view of the experience. It can reveal where information is missing, where responsibilities are unclear and where separate systems or teams create friction for the user.

What a journey map can include:

Base the map on evidence wherever possible. Where evidence is missing, identify assumptions and look for ways to test them. A journey map does not tell the team exactly what to build. It gives them a stronger basis for deciding what needs to change.

How to map a user journey

A simple mapping exercise might follow six steps:

1. Choose one goal and context. Be clear about who is trying to do what, and in what situation.
2. Gather what you already know. Use research, analytics, search data, support enquiries and insight from customer-facing teams.
3. Map what happens now. Start before the person reaches the website and continue until they receive an outcome or understand what happens next.
4. Add what happens at each stage. Record what the person needs, what they do, the touchpoints they use and where they encounter barriers.
5. Decide which problems matter most. Focus on barriers that create the most confusion, delay, risk or unnecessary effort.
6. Test changes and keep the map updated. Treat it as a working tool rather than a finished poster.

How journeys influence website projects

Understanding priority journeys helps shape many of the decisions made during a website project.

A simplified view might group that work into three connected stages:

Understand –

Shape –

Validate and improve –

Website projects do not usually follow such a clear sequence. Research may continue while content and design are being developed, and testing may reveal that an earlier decision needs to be changed. The value of the journey is that it gives each discipline a shared point of reference.

Suppose research shows that prospective students need to compare entry requirements before deciding whether a course is suitable. That finding may affect where entry requirements appear, how consistently they are presented and whether course pages need comparison tools or clearer links between related subjects.

If residents describe a council service differently from the organisation, that insight may influence navigation labels, headings, website search and external communications.

It can also expose problems that sit between disciplines. A technically sound application form may still pose difficulties if the preceding content does not explain who is eligible or what information the applicant needs to provide. A polished confirmation page may still fail if it does not explain when the organisation will respond.

Content, design and development decisions may all make sense on their own. The difficulty often appears when someone has to move through the finished experience. Mapping the journey gives the team a clearer view of how those decisions connect.

One journey often leads to another

Completing one task does not always end the relationship with an organisation.

Someone who downloads guidance may decide they need to make contact. A person who books an appointment might then need directions, accessibility information or advice about what to bring. An applicant may want to track progress, update their details or understand the next stage.

These follow-on needs can be easy to overlook because the organisation may treat them as separate services. To the person involved, one naturally leads to another.

Confirmation pages and messages are especially important. They should do more than state that an action was successful. They can explain when a response is likely, what the person should do next and where to find further help.

Thinking beyond the immediate form submission or completed action helps organisations support what people need next. It can also reduce avoidable enquiries by answering the questions that commonly arise afterwards.

Improving journeys after launch

Journey planning helps organisations make informed decisions before launch, but it cannot predict every real-world situation.

People will arrive through routes the project team did not expect. Services will change, new content will be published and external systems will be updated. An experience that worked well at launch may become less clear as the organisation evolves.

Analytics can provide a partial view of where people enter, which routes they take and where their recorded activity ends. Website search data may reveal the terminology visitors use or information they cannot find through navigation. Feedback, customer enquiries and usability testing can expose repeated uncertainty or show how people approach important tasks.

The numbers do not explain the reason on their own. Someone may leave a page because they found what they needed, not because the page failed to help. A page with a lot of traffic may be especially useful, but it could also be attracting visits because the same information is hard to find elsewhere.

A change in the numbers does not always mean the website needs to be changed. What matters is recognising consistent evidence that an important task could be easier and making improvements where they will have a meaningful impact.

Common misconceptions about user journeys

Design the whole task, not just the page

Good websites help people complete what they came to do.

Understanding user journeys makes it easier to decide on structure, navigation, content, functionality and design because the team can assess each choice against real outcomes. Does the information help someone make progress? Is the next step clear? Does the experience continue to make sense when the person moves between pages, systems or departments?

Not every visitor needs to follow an identical route. The organisation needs to understand the goals people bring and provide clear ways to achieve an appropriate outcome.

Individual pages still matter, but the experience is defined by whether they work together to help someone complete the task.

How we can help