Goals and Journeys

A journey is a story; a map is one way to visualise it.

We’ve identified key user personas and presumably developed a business model canvas. Now, the user journey map paves the way for better, more efficient, and intentional product development.


In the startup environment, the impulse is to “build first, ask questions later.” But pausing to ask yourself the right questions early on can save you and your team a lot of grief. A good user journey map is one such tool to get you and your team asking the right questions.

  • It creates a single source of truth - Capture an entire experience with a single system of record. It’s a shared team artefact, connected together around the user experience.

  • It helps us look beyond symptoms - A user journey map helps us look beyond the symptoms and get to the root of what might be broken. Are users having a hard time learning to use your product? Are they opting out once there’s nowhere left for them to go?

The most important mindset to start with is keeping your focus radically and unapologetically on the user. It’s not about what your dev team wants or your marketing team wants – it’s about what your user wants and needs from your product.

Each persona has a distinct need or expectation and thus demands a different journey map. The map will also look very different at different stages of your product development journey. It’s advised to revisit it every 6 to 12 months for a healthy product.

Often, the goal of creating a journey map is to educate internal parties about user pain points and unmet needs, or persuade stakeholders to invest in fixing existing problems. In such a scenario, it is helpful to visualise the experience as a storyboard. A storyboard has the advantage of being more expressive and better positioned to be presented to a larger audience.

The level of detail of a user journey map depends on your goals for building a journey map

Identifying the right user goal

A goal describes the overall thing the user is trying to achieve. Goals should refer to real-world end states and ideally not be confined within the scope of your solution. Goals can be layered. Depending on the phase of your product launch, we could be looking at different type of user goal. As Don Norman puts it in his book, Emotional Design, we can think about

  • Visceral motivations—how a user wants to feel (Experience Goals)

  • Behavioural motivations—what they want to do (End Goals) and

  • Reflective motivations—who they want to be (Life Goals).

At this stage it’s typically preferred to consider a high-level reflective or life goal, since we will have an opportunity to get more granular in the chapter about user interfaces — where we will chalk out a specific moment from this journey in more detail to create task-based user workflows. A task is a more specific activity that helps users achieve their real world goals.

Be sure the goal is based on a solid insight form the field, and that it truly reflects the human needs of the user we're mapping for.


The Mapping

Decide with your team whether you're mapping the current experience or a desired or imagined future experience of the user? Then place the persona or user that you're building the journey for at the beginning, and their goal at the end of the map.

[User Name]
Phase 1
Phase 2
Phase 3
Phase 4
[Goal]

Doing

Thinking

Feeling

At the very minimum, these are a few swim-lanes that can get us started with drawing out a user journey map —

1

Phases

Go through the process step by step: How does the customer hear about you? Then what? How do they find you? What do they do next? What do they do next?

2

Doing

Once you get the basic structure of the journey down, go back over each step, and add more layers — What technology are they interacting with? Who or what are their main points of contact (touch points)?

3

Thinking (and Feeling)

What are the users thinking at this stage in the interaction with your product? Consider how are users feeling or what’s motivating them to take the next step?

4

Pains and Opportunities

Finally, identify what the possible obstacles may be in your context. What technologies or tools exist at these intersections and what makes it harder for users to get what they need? A common obstacle simply describes the relationship — or roadblock — between the key user and the desired changed state.

Chances are, this is not a lack of knowledge or a lack of desire to act. Instead, think about the competing priorities, demands for attention, conflicting beliefs, habituated behaviours, and social pressures that hinder the desired behaviour. Some areas of recurring obstacles we find when we look at people first might be Fear, Choice, Social Norms, Ambiguity, Uncertainty, Optimism Bias, News, Attention Scarcity.

Be open to encountering a mismatch between user goals and your solution’s ability. In his book The Design of Everyday Things, Don Norman refers to two kinds of such gulfs — the Gulf of Execution (“How do I work with this tool to accomplish my goal?”) and the Gulf of Evaluation (”Did this work how I wanted it to?”). A lot of user mistakes happen when users do not get enough help in bridging these two gulfs, and the designers’ mental model and interpretation of how the system should work does not match users’ mental models. More on this on the chapter about designing Interfaces.


At the end of this exercise you've either found complexity in a specific phase that you want to double click into — In which case you can create a detailed service design blueprint — to include the backend activities that support the journey. Alternately, you can take a note of the challenges and opportunities that have surfaced, and use them as the fodder for further synthesis. Sometimes a comparison of different user journeys surfaces good insights too.

Last updated

Was this helpful?