journey mapping agile

Customer Journey Mapping

Journey mapping helps you visualize how customers experience your product or service, and how they feel along the way. Scroll to step 6 for a real-life example from one of our product teams!

USE THIS PLAY TO...

Understand the customer journey from a specific persona's perspective so that you can design a better experience.

Running the play

Depending on how many touchpoints along the customer journey you're mapping, you might break the journey into stages and tackle each stage in pairs.

Sticky notes

Whiteboards.io Template

Define the map's scope (15 min)

Ideally, customer journey mapping focuses on the experience of a single persona  in a single scenario with a single goal. Else, the journey map will be too generic, and you'll miss out on opportunities for new insights and questions. You may need to pause creating a customer journey map until you have defined your customer personas . Your personas should be informed by  customer interviews , as well as data wherever possible.

Saying that, don't let perfect be the enemy of good! Sometimes a team just needs to get started, and you can agree to revisit with more rigor in  a few months' time. Once scope is agreed on, check your invite list to make sure you've got people who know the details of what customers experience when using your product or service.

Set the stage (5 min)

It's really important that your group understands the user  persona  and the goal driving their journey. Decide on or recap with your group the target persona and the scope of the journey being explored in your session. Make sure to pre-share required reading with the team at least a week ahead of your session to make sure everyone understands the persona, scope of the journey, and has a chance to delve deeper into research and data where needed. Even better- invite the team to run or attend the customer interviews to hear from customers first hand!

E.g. "We're going to focus on the Alana persona. Alana's role is project manager, and her goal is to find a scalable way for her team to share their knowledge so they spend less time explaining things over email. We're going to map out what it's like for Alana to evaluate Confluence for this purpose, from the point where she clicks that TRY button, to the point where she decides to buy it – or not."

Build a customer back-story (10 min)

Have the group use sticky notes to post up reasons why your target persona would be on this journey in the first place. Odds are, you'll get a range of responses: everything from high-level goals, to pain points, to requested features or services. Group similar ideas and groom the stickies so you can design a story from them.

These narratives should be inspired by actual customer interviews. But each team member will also bring a different perspective to the table that helps to broaden the lens.

Take a look at the example provided in the call out of this section. This back story starts with the pain points – the reasons why Alana would be wanting something like Confluence in the first place.

• E.g., "Her team's knowledge is in silos"

Then it basically has a list of requirements – what Alana is looking for in a product to solve the bottom pain points. This is essentially a mental shopping list for the group to refer to when mapping out the customer journey.

• E.g., "Provide structure"

Then it has the outcomes – goals that Alana wants to achieve by using the product

• E.g., "To keep my team focused on their work instead of distracted by unnecessary emails and shoulder-taps"

And finally the highest-level goal for her and her team.

• E.g., "Improve team efficiency"

Round off the back story by getting someone to say out loud what they think the overall story so far is, highlighting the main goals the customer has. This ensures a shared understanding that will inform the journey mapping, and improve the chances that your team will map it from the persona's point of view (not their own).

• E.g., "Alana and her team are frustrated by having to spend so much time explaining their work to each other, and to stakeholders. They want a way to share their knowledge, and organize it so it's easy for people outside their team to find, so they can focus more energy on the tasks at hand."

For example...

Here's a backstory the Confluence team created. 

Map what the customer thinks and feels (30-60 min)

With the target persona, back story, and destination in place, it's time to walk a mile in their shoes. Show participants how to get going by writing the first thing that the persona does on a sticky note. The whole group can then grab stickies and markers and continue plotting the journey one action at a time.

This can also include questions and decisions! If the journey branches based on the answers or choices, have one participant map out each path. Keep in mind that the purpose of this Play is to build empathy for, and a shared understanding of the customer for the team. In order to do this, we focus on mapping the  current state of one discrete end to end journey, and looking for opportunities for improvement.

To do a more comprehensive discovery and inform strategy, you will need to go deeper on researching and designing these journey maps, which will need to split up over multiple sessions. Take a look at the variation below for tipes on how to design a completely new customer journey.

Use different color sticky notes for actions, questions, decisions, etc. so it's easier to see each element when you look at the whole map.

For each action on the customer journey, capture which channels are used for the interactions. Depending on your context, channels might include a website, phone, email, postal mail, face-to-face, and/or social media.

It might also help to visually split the mapping area in zones, such as "frontstage" (what the customer experiences) versus "backstage" (what systems and processes are active in the background).

Journey mapping can open up rich discussion, but try to avoid delving into the wrong sort of detail. The idea is to explore the journey and mine it for opportunities to improve the experience instead of coming up with solutions on the spot. It's important not only to keep the conversation on track, but also to create an artefact that can be easily referenced in the future. Use expands or footnotes in the Confluence template to capture any additional context while keeping the overview stable.

Try to be the commentator, not the critic. And remember: you're there to call out what’s going on for the persona, not explain what’s going on with internal systems and processes.

To get more granular on the 'backstage' processes required to provide the 'frontstage' customer value, consider using Confluence Whiteboard's Service Blueprint template as a next step to follow up on this Play.

ANTI-PATTERN

Your map has heaps of branches and loops.

Your scope is probably too high-level. Map a specific journey that focuses on a specific task, rather than mapping how a customer might explore for the first time.

Map the pain points (10-30 min)

"Ok, show me where it hurts." Go back over the map and jot down pain points on sticky notes. Place them underneath the corresponding touchpoints on the journey. Where is there frustration? Errors? Bottlenecks? Things not working as expected?

For added value, talk about the impact of each pain point. Is it trivial, or is it likely to necessitate some kind of hack or work-around. Even worse: does it cause the persona to abandon their journey entirely?

Chart a sentiment line (15 min)

(Optional, but totally worth it.) Plot the persona's sentiment in an area under your journey map, so that you can see how their emotional experience changes with each touchpoint. Look for things like:

• Areas of sawtooth sentiment – going up and down a lot is pretty common, but that doesn't mean it's not exhausting for the persona.
• Rapid drops – this indicates large gaps in expectations, and frustration.
• Troughs – these indicate opportunities for lifting overall sentiments.
• Positive peaks – can you design an experience that lifts them even higher? Can you delight the persona and inspire them to recommend you?

Remember that pain points don't always cause immediate drops in customer sentiment. Sometimes some friction may even buold trust (consider requiring verification for example). A pain point early in the journey might also result in negative feelings later on, as experiences accumulate. 

Having customers in the session to help validate and challenge the journey map means you'll be more confident what comes out of this session. 

Analyse the big picture (15 min)

As a group, stand back from the journey map and discuss trends and patterns in the experience.

• Where are the areas of greatest confusion/frustration?
• Where is the journey falling short of expectations?
• Are there any new un-met needs that have come up for the user type?
• Are there areas in the process being needlessly complicated or duplicated? Are there lots of emails being sent that aren’t actually useful? 

Then, discuss areas of opportunity to improve the experience. E.g., are there areas in the process where seven steps could be reduced to three? Is that verification email actually needed?

You can use quantitative data to validate the impact of the various opportunity areas identified. A particular step may well be a customer experience that falls short, but how many of your customers are actually effected by that step? Might you be better off as a team focused on another higher impact opportunity?

Here's a user onboarding jouney map our Engaging First Impressions team created.

Be sure to run a full Health Monitor session or checkpoint with your team to see if you're improving.

MAP A FUTURE STATE

Instead of mapping the current experience, map out an experience you haven't delivered yet. You can map one that simply improves on existing pain points, or design an absolutely visionary amazeballs awesome experience!

Just make sure to always base your ideas on real customer interviews and data. When designing a totally new customer journey, it can also be interesting to map competitor or peer customer journeys to find inspiration. Working on a personalised service? How do they do it in grocery? What about fashion? Finance?

After the mapping session, create a stakeholder summary. What pain points have the highest impact to customers' evaluation, adoption and usage of our products? What opportunities are there, and which teams should know about them? What is your action plan to resolve these pain points? Keep it at a summary level for a fast share out of key takeaways.

For a broader audience, or to allow stakeholders to go deeper, you could also create a write-up of your analysis and recommendations you came up with, notes captured, photos of the group and the artefacts created on a Confluence page. A great way of sharing this information is in a video walk through of the journey map. Loom is a great tool for this as viewers can comment on specific stages of the journey. This can be a great way to inspire change in your organization and provide a model for customer-centric design practices.

KEEP IT REAL

Now that you have interviewed your customers and created your customer journey map, circle back to your customers and validate! And yes: you might learn that your entire map is invalid and have to start again from scratch. (Better to find that out now, versus after you've delivered the journey!) Major initiatives typically make multiple journey maps to capture the needs of multiple personas, and often iterate on each map. Remember not to set and forget. Journeys are rapidly disrupted, and keeping your finger on the pulse of your customer's reality will enable your team to pivot (and get results!) faster when needed.

Related Plays

     Customer Interview

     Project Poster

Want even more Playbook?

Drop your email below to be notified when we add new Health Monitors and plays.

Thanks! Now get back to work.

Got feedback?

Drop a question or comment on the Atlassian Community site.

Shared understanding

Different types of teams need to share an understanding of different things.

LEADERSHIP TEAMS

The team has a  shared vision  and collective  purpose  which they support, and  confidence  they have made the right strategic bets to achieve success.

Proof of concept

Project teams.

Some sort of demonstration has been created and tested, that demonstrates why this problem needs to be solved, and demonstrates its value.

Customer centricity

Service teams.

Team members are skilled at  understanding , empathizing and  resolving  requests with an effective customer feedback loop in place that drives improvements and builds trust to improve service offerings.

• Get started Get started for free

Figma design

Design and prototype in one place

Collaborate with a digital whiteboard

Translate designs into code

Get the desktop, mobile, and font installer apps

See the latest features and releases

• Prototyping
• Design systems
• Wireframing
• Online whiteboard
• Team meetings
• Strategic planning
• Brainstorming
• Diagramming
• Product development
• Web development
• Design handoff
• Product managers

Organizations

Config 2024

Register to attend in person or online — June 26–27

Creator fund

Build and sell what you love

User groups

Join a local Friends of Figma group

Learn best practices at virtual events

Customer stories

Read about leading product teams

Stories about bringing new ideas to life

Get started

• Developer docs
• Best practices
• Reports & insights
• Resource library
• Help center

How to create an effective user journey map

No matter what you’re working on, the key to customer satisfaction and business growth is understanding your users. A user journey map helps you uncover pain points, explore the touchpoints from their perspective, and learn how to improve your product.

Imagine you just launched a new ecommerce platform. Shoppers fill their carts with products, but they abandon their carts before checkout. With a user journey map, you can pinpoint where the customer experience is going wrong, and how to enable more successful checkouts.

Read on to find out:

• What is a user journey map, and how it captures user flows and customer touchpoints
• Benefits of user journey mapping to refine UX design and reach business goals
• How to make user journey maps in five steps, using FigJam’s user journey map template

What is a user journey map?

Think about the path a user takes to explore your product or website. How would you design the best way to get there? User journey maps (or user experience maps) help team members and stakeholders align on user needs throughout the design process, starting with user research. As you trace users' steps through your user flows, notice: Where do users get lost, backtrack, or drop off?

User journey maps help you flag pain points and churn, so your team can see where the user experience may be confusing or frustrating for your audience. Then you can use your map to identify key customer touchpoints and find opportunities for optimization.

How to read a user journey map

Most user journey maps are flowcharts or grids showing the user experience from end to end. Consider this real-life journey map example of a freelancing app from Figma's design community. The journey starts with a buyer persona needing freelance services, and a freelancer looking for a gig. Ideally, the journey ends with service delivery and payment—but customer pain points could interrupt the flow.

Start your user journey map with FigJam

5 key user journey map phases.

Take a look at another Figma community user journey template , which uses a simple grid. Columns capture the five key stages of the user journey: awareness, consideration, decision, purchase, and retention (see below). Rows show customer experiences across these stages—their thoughts, feelings, and pain points. These experiences are rated as good, neutral, and bad.

To see how this works, consider a practical example. Suppose a new pet parent wants to learn how to train their puppy and discovers your dog-training app. Here's how you might map out the five key user journey stages:

• Awareness. The user sees a puppy-training video on social media with a link to your product website. They're intrigued—a positive experience.
• Consideration. The user visits your product website to preview your app. If they can't find a video preview easily, this could be a neutral or negative experience.
• Decision. The user clicks on a link to the app store and reads reviews of your app and compares it to others. They might think your app reviews are good, but your price is high—a negative or neutral experience.
• Purchase. The user buys your app and completes the onboarding process. If this process is smooth, it's a positive experience. If not, the customer experience could turn negative at this point.
• Retention. The user receives follow-up emails featuring premium puppy-training services or special offers. Depending on their perception of these emails, the experience can range from good (helpful support) to bad (too much spam).

2 types of user journey maps—and when to use them

User journey maps are helpful across the product design and development process, especially at two crucial moments: during product development and for UX troubleshooting. These scenarios call for different user journey maps: current-state and future-state.

Current-state user journey maps

A current-state user journey map shows existing customer interactions with your product. It gives you a snapshot of what's happening, and pinpoints how to enhance the user experience.

Take the puppy training app, for example. A current-state customer journey map might reveal that users are abandoning their shopping carts before making in-app purchases. Look at it from your customers' point of view: Maybe they aren't convinced their credit cards will be secure or the shipping address workflow takes too long. These pain points show where you might tweak functionality to boost user experience and build customer loyalty.

Future-state user journey maps

A future-state user journey map is like a vision board : it shows the ideal customer journey, supported by exceptional customer experiences. Sketch out your best guesses about user behavior on an ideal journey, then put them to the test with usability testing. Once you've identified your north star, you can explore new product or site features that will optimize user experience.

How to make a user journey map in 5 steps

To start user journey mapping, follow this step-by-step guide.

Step 1: Define user personas and goals.

Gather user research and data like demographics, psychographics, and shopping behavior to create detailed customer personas representing your target audience.  In your dog-training app example, one key demographic may be parents. What’s their goal? It isn't necessarily "hire a puppy trainer"—it could be "teach kids how to interact with a puppy."

Step 2: Identify customer touch points.

Locate the points along the user journey where the user encounters or interacts with your product. In the dog training app example, touchpoints might include social media videos, app website, app store category search (e.g., pets), app reviews, app store checkout, in-app onboarding, and app customer support.

Step 3: Visualize journey phases.

Create a visual representation of user journey phases across key touchpoints with user flow diagrams , flowcharts , or storyboards .

Step 4: Capture user actions and responses.

For each journey stage, capture the user story: at this juncture, what are they doing, thinking, and feeling ? This could be simple, such as: "Potential customer feels frustrated when the product image takes too long to load."

Step 5: Validate and iterate.

Finally, show your map to real users. Get honest feedback about what works and what doesn’t with user testing , website metrics , or surveys . To use the dog-training app example, you might ask users: Are they interested in subscribing to premium how-to video content by a professional dog trainer? Apply user feedback to refine your map and ensure it reflects customer needs.

Jumpstart your user journey map with FigJam

Lead your team's user journey mapping effort with FigJam, the online collaborative whiteboard for brainstorming, designing, and idea-sharing. Choose a user journey map template from Figma's design community as your guide. With Figma's drag-and-drop design features, you can quickly produce your own professional, presentation-ready user journey map.

Pro tip: Use a service blueprint template to capture behind-the-scenes processes that support the user journey, bridging the gap between user experience and service delivery.

Ready to improve UX with user journey mapping?

Agile workflow

The Ultimate Guide to User Story Mapping [2023 Guide]

Whether you’re planning your first user story mapping session or you’ve got a few under your belt, it can be a little overwhelming 🤯

• What’s the process?
• Who do I need to get involved?
• Why are we even bothering with this when we have a perfectly good backlog? (Okay… it might be slightly dysfunctional, but you know...)
• Why are there sticky notes EVERYWHERE?

Most product managers and Agile teams could benefit from a deeper understanding of user story mapping so they can create a more customer-centered view of the work that needs to be done.

Plus, over the last 15 years (since user story maps started to become a thing thanks to Jeff Patton), some of the processes and terms have evolved and there are new tools and apps that can make your life a whooooole lot easier.

We’ve put together this ultimate guide with all the info you need to get up to speed on the latest user story mapping definitions, techniques, and tools. Let’s start with some basics 👇

What is user story mapping?

Here’s a super simple user story mapping definition:.

User story mapping is a visualization of the journey a customer takes with a product, from beginning to end. It includes all the tasks they’d typically complete as part of that journey.

To expand on that, user story mapping takes all your user stories (across all your persona types) and assigns them to epics in the order that delivers the most value to the customer. From there, stories are prioritized and mapped to releases.

“User story mapping is a facilitated, curated conversation that brings everyone along for the journey. It’s an opportunity for the product manager to brain dump their insights (who is deep in this stuff day in, day out) and get it into the minds of the team who are about to deliver on it.”

What isn’t user story mapping?

While user story mapping might have a few things in common with other methods, it’s not the same as journey mapping or event storming.

User story mapping vs journey mapping

Journey mapping is a UX tool that helps teams visualize the journey a customer needs to take so they can accomplish a goal. Journey maps focus on the journey for a single persona or customer, based on the persona’s specific scenario and expectations. This is useful for aligning the team, getting them focused on the user experience, and basing decisions. Unlike user story mapping, it’s focused on the user experience and the vision for the product.

User story mapping vs event storming

Event storming involves running a workshop with key business stakeholders present. The attendees write down business events (things that happen), commands (things that trigger the events), and reactions (things that happen as a result) on sticky notes. These notes are organized sequentially to map out the business processes. Unlike user story mapping, which is focused on refining the backlog to deliver a working product for the user, event storming is more high-level and done early in the product planning process.

User story mapping for agile teams

User story maps can be useful for all agile teams, whether they’re full SAFe or Kanban, but especially if they’re working on a complex product.

User story mapping is a useful technique for agile software development teams because it can help your team deliver working software and respond to change.

This fits right in with the Agile Manifesto.

And let’s not forget the number one agile principle:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

User story mapping puts the focus on the user, ensuring that the backlog contains stories that add real value to the customer by helping them achieve their goals.

Plus, story mapping allows your team to plan and order their work so that it delivers the highest value to customers first.

The anatomy of a user story map

User stories, epics, the backbone and story mapping - oh my! To break down the steps and processes involved in user story mapping down further, let’s define some of its moving parts.

User stories

A user story is a goal, from the user or customer’s perspective. It’s an outcome they want. It’s also the smallest unit of work in an agile framework with the purpose of articulating how a piece of work will deliver value back to the customer.

User stories usually follow the structure:

As a [persona type], I want to [action] so that [benefit].

For example:

Tip: it’s a good idea to focus on just one type of user/persona during your user story mapping session. If it’s your first session, choose your most ideal customer type and write our user stories that will deliver value to them. You can always come back to your other users in future.

Read ➡️ How to write good user stories in agile software development.

Stories can be associated with epics.

Epics have different meanings depending on who you talk to. But for the sake of this article, we’ll define epics as bigger, overarching stories or steps in the journey that contain user stories. An epic on its own isn’t small enough to become a work item or development task, but the stories it contains probably are.

For example, the epic “Sign up” might contain the following user stories:

• As a customer, I want to read the privacy policy before I sign up for my account so I can decide whether I trust the company with my details
• As a customer, I want to see a list of features and benefits on the sign-up page to remind me about what I’m signing up for
• As a customer, I want to sign up for an account using my Facebook login so I don’t have to remember my username or password
• As a customer, I want to sign up for an account using my email address so I can control access to my information
• And in this example, the next epic might be “Set up and customize my profile”.

The backbone

The backbone is the top row of your user story map. It outlines the essential capabilities the system needs to have.

Your backbone should show the customer journey or process from beginning to end, including all the high level activities the customer will complete while using your product. Depending on how you use your backbone and story map, it could be made up of epics.

The backbone is critical because it gives your team the “why” behind the journey, even if they’re just focused on a single step. It takes away ambiguity around what might lead up to that step and what might follow it, which gives important context for creating a smooth customer journey.

More on: The Anatomy of a User Story Map

Why do user story mapping?

The purpose of user story mapping is to make sure you understand the problem the customer has, and then find a solution to that problem.

You’ll know the answer to:

• Why are we building this?
• Who are we building this for?
• What value will it provide them?
• When do we expect to deliver this?

This will help align your teams, groom the backlog, and more quickly deliver a product that your customers want and need.

John Walpole explains the value of user stories beautifully:

“[There’s] one technique and tool which time and time again I’ve gone back to when I felt like a project maybe isn’t thoroughly understood by the team, or I’m worried that we’re going to end up shipping software that isn’t going to delight customers. This is my go-to technique. I believe it’s going to help you ship software that will delight your customers.”

Without user story mapping, there’s a much greater chance that your team will come up with complicated, non-customer-focused solutions to a problem.

User story mapping helps ensure the team is aligned around what problem the customer has, and how you, as a team, are going to try and solve that problem.

It will keep you focused on delivering the highest impact and greatest value pieces first, enabling you to iterate based on feedback.

Read ➡️ Why User Story Mapping

Benefits of user story mapping

“User story mapping is the best technique I’ve come across to gain shared understanding within an agile team. Alex Hennecke at Atlassian talked about being able to see the forest - instead of just the trees, right in front of him.”

There are so many benefits to user story mapping, like:

• Plan better - Seeing the user journey mapped out makes it easier for teams to see the big picture of your product and identify any risks, dependencies, and blocks ahead of time
• Greater empathy - It forces your team to see the product from your users’ perspective
• Better prioritization - Organize work into releases based on what’s most important to users and what will deliver a new or complete experience for users
• More value sooner - Frequently delivering new value to users is easier when you can order the stories based on value and map them to iterations or releases
• Realistic requirements - By breaking user stories down and visually mapping them, it’s easier to estimate work and see how all the pieces fit together
• Better collaboration - With all the upcoming work mapped out, marketing, sales, and other teams can see when you expect to ship new features and updates so they can adjust their marketing communications and sales conversations (without asking you for daily updates)

User story mapping helps your team understand the bigger picture, the why, and the end-to-end customer journey before they dive into the what and how.

Read ➡️ Understand what your customers want with agile user story maps.

The flat backlog vs user story mapping

Before we had user story mapping, we had the flat backlog. Actually, a lot of agile teams still use the flat backlog (no judgement if this is you!). So, let’s talk about what that looks like and how user story mapping has improved this practice.

Read ➡️ DEEP: The 4 Characteristics of a Good Product Backlog

What’s a flat backlog?

Essentially, it’s a to-do list. It includes all the items your team needs to do so they can provide value to your customers, ordered from most valuable to least valuable to the customer. The backlog may be split into current and future sprints to show what outputs are likely to be delivered when.

But I like our backlog!

A simple to do list might be fine if your product is simple, your team is small, and your to-do list is very short. But most products are complex, with multiple teams working on it. And most of the time, the backlog is massive (and constantly growing and changing).

Flat backlogs are complex at scale

If you’ve got hundreds of issues (or more), a flat backlog makes it impossible to see the big picture and surrounding context - which your team needs in order to refine the backlog, find dependencies, and prioritize the work into releases. It can also get pretty overwhelming!

• Specific challenges of using the flat backlog include:
• Arranging user stories in the order you’ll build them doesn’t help you explain to others what the system does
• It provides no context or ‘big picture’ around the work a team is doing
• For a new system, the flat backlog is poor at helping you determine if you’ve identified all the stories
• Release planning is difficult with a flat backlog - how do you prioritize what to build first when you’ve got an endless list?
• It’s virtually impossible to discover the ‘backbone’ of your product

User story maps were designed to overcome these challenges and restructure the backlog to add context, make it easier to prioritize, and put the focus on the customers’ needs. It introduces the X axis, with the backbone at the top to show the customer journey, and the user stories below.

When you go from a flat backlog to multiple axes, your team (and the rest of your organization) can understand what value we intend to deliver to the customer and when.

Read ➡️ The difference between a flat product backlog and a user story map.

When is user story mapping done?

So, when do you actually run a user story mapping session?

Generally, a team will collaboratively create a story map at the start of a project or product. It might be an entirely new product, or the product manager might want to pursue a new idea or feature as part of an existing product.

This involves getting subject matter experts and team members together to run a session where you look at your personas and overarching customer journey, then brainstorm ways you can provide the most value to customers. Then you’ll write user stories for each of your persona types and each step of the journey, based on their needs.

As we’ve already mentioned, it’s best to focus on one persona type per story mapping session to avoid confusion. So, start with the persona who is the best fit for your product or likely represent the largest chunk of your audience first.

Overall, the process could take several days or even several weeks, depending on the complexity of your product (and therefore, the number of steps in the customer journey) and the number of personas.

Getting the most out of User Story Mapping

Who should be involved in user story mapping.

Some folks you might invite to your user story mapping party session include your:

• Subject matter experts (whether product owner, product manager, customer support team member, or someone else who interacts with the customer)
• Business owner
• UX designer
• Facilitator or Scrum Master (it’s useful if you can get another product manager to facilitate the session)

Tip: Try to keep your numbers below 10 participants. Diverse perspectives are useful, but any more than that and it can get tricky to manage and get input from everyone. All the people present should be able to contribute insights into the personas/product/business, or help estimate how long tasks will take to complete.

Mapping the user stories

Once the backbone is established (and your team agrees on the order), you can put the flesh on it. Under each item in the backbone, go the user stories (steps, processes, and details) that support that activity. This involves some brainstorming and creative thinking.

Encourage your team to imagine the different options available to the user, how they might want to experience each step in the backbone, and actions they might take. It can't hurt to do a paper prototyping session alongside your user story map to mock up ideas as you go. Or perhaps that step will come later, depending on the scenario and maturity of your team.

Then you can put your user stories in a sequence to deliver maximum value to the customer as quickly and consistently as possible. So, put the most important user stories at the top, and the least important ones at the bottom.

Cut lines or swimlanes

Your team will get together and discuss and estimate the work involved in each user story. After that, you can add cut lines (usually sprint or version lines) to mark out what your team will deliver and when. At this point, you might shuffle some stories around if it makes sense for the user to get them in the same release.

Read ➡️ Anatomy of an agile user story map.

Tips for successful user story mapping

Involve the right people.

It can be tricky to get your team and stakeholders together. They’re busy and probably have a plate full of commitments. But it’s always worth getting everyone to set aside time and step away from the keyboard. User story mapping is important - and you’ll need input from everyone so you can:

• Brainstorm stories then prioritize and estimate them
• Get your team to commit to implementing them

Break it up

“Typically, I’d run these things to try and get as much of the planning, personas, and backbone done on day one as possible. By that point, most people are tapped out because the cognitive load is high. Then the team can go away and sleep on it. Once they’ve had time to reflect on it, they’ll come back with other ideas for user stories and thoughts about how they’d do the work before they start sequencing.”

You don’t have to do your whole user story mapping session in one go. Depending on the size, complexity, and phase of your product, you might not be able to fit it into one day, either.

Instead, break your session up into 2-3 hour chunks and do it over several days. You might do the first session in the afternoon and the next session the following morning. This comes with a few advantages:

• It means you don’t have to get your stakeholders and teams together for an extended period
• You might find it’s a lot easier to coordinate your calendars when you split your sessions up
• It gives your team time to reflect on the initial story map (they’ll probably think of a million new things to add on day two)
• Your team can get lunch after the session is done and debrief over food and drinks 🍻🍔🍕

A single facilitator

While you DO want all your team and stakeholders at your user story mapping session, you don’t want everybody driving the discussion (too many chefs in the kitchen = not a good idea). Instead choose one person to facilitate the session. Sometimes it even works better if you can choose a product manager from another team to run things.

No phones/laptops

For in-person user story mapping sessions, only your designated facilitator is allowed their device. To avoid distractions, ask folks to leave their phones and laptops in a stack at the door. That way, your team can be fully present for all discussions.

Start with data and evidence

Before you get stuck into user story mapping, bring in relevant data and supporting evidence. All of that is great context for what's to come. And of course, you can’t do user story mapping without a clear understanding of who your users are - and what their goals, objectives, problems, and needs are.

So, create your personas before you build out your customer journeys. That way, you’ll understand how your users will engage with the product, and you’ll be able to write user stories that more accurately reflect reality.

User Story Mapping Approaches

User story mapping example.

Let’s go through an example of user story mapping to help you visualize the process for your own product.

• Identify product/outcome

In this example, our product is a free online educational kids game. The outcome is for the user to find and play the game.

• List high level activities (in chronological order):
• Navigate to games website
• Log into account (or sign up if a first-time user)
• Search for game
• Choose game
• Share with a friend or on social media
• List user stories under each activity

For example, searching for a game could include the following options:

• Free text search - As a parent, I want to search for a specific keyword so I can quickly navigate to a game
• Browse by category: age group - As a parent, I want to find an age appropriate game that my kids will easily pick up
• Browse by category: type of education - As a parent, I want to find a game that will help my child improve their knowledge and skills in a specific area
• Browse by category: game type - As a parent, I want to find a new game that’s similar to one my child already likes
• Order by top rated - As a parent, I want to find a game that’s likely to keep my kid engaged for a while so I can get some work done
• Order by newest/oldest - As a parent, I want to help my child find a game they haven’t already played, to give them a new experience
• Order by most popular - As a parent, I want to help my child find and play the most popular games
• Order stories from most to least valuable to users

Value is identified from analytics on usage patterns, customer interviews, and other insights.

Your team might check feedback forms to see what parents’ top requested features are, and prioritize these first. That way, they’ll deliver more value, more quickly.

Sequence the work so you know what to deliver and when

Your team will estimate the work involved in each user story and decide what stories you can complete for upcoming sprints or releases. They may group stories that are needed to deliver an MVP, or stories that need to get released together - for example, all the “browse by category” features might go live at the same time.

Split it up over releases or sprints

The team sets your cut lines (for the sprint or version), allowing them to distinguish what they think they can deliver in that sprint/version. This will be based on their capacity and what they need to deliver to users for a minimum viable product (MVP).

A user story mapping… story

During his time at Twitter, our Co-Founder, Nicholas Muldoon, facilitated a session for another team whose goal was to figure out how they should fix an issue with the app. This example (in Nick’s words) shows another interesting application of user story mapping, including the types of issues you might work through and how you can hone in on a particular persona or subsection of your audience.

Step 1: Kick off

We started by getting everyone in the room. Attendees included several subject matter experts - not just the immediate team who were working on the project. This included someone from the user authentication team and a UX designer who had worked on password resets in the past.

The product manager kicked off the session by explaining the situation: “A whole chunk of users are having trouble getting into the app because they can’t remember their password. But in order to get them to go through the tedious password reset process, we want to give them value first to show that it’s worth doing. How?”

Step 2: Persona identification

To figure out the next steps and do user story mapping, we needed to narrow down the audience so we could use it as a framing reference or persona. After all, we were looking at a huge audience of 30 million people, not a single persona.

So we asked: who are we not targeting? Then we were able to take out any pro users and government users, which brought the audience size down to 28 million.

Next we asked: what’s the easiest place to experiment and test this? At the time, there was a feature we couldn’t access on IOS, so we went with Android. Plus, we had great relationships with the US-based phone carrier, AT&T. So we looked at our audience of Android users on AT&T in the US, which left us with a much more reasonable audience size of 3 million people.

We used this persona to experiment with this particular feature without touching all the different use cases.

Step 3: The big steps

Once we’d outlined the persona we were going to focus on, we could talk about what’s in or what’s out. So, we talked about the big steps, like:

• They’re on the Android home screen
• They open up the app
• They see all the features
• They attempt an action (Tweet, like, or retweet)
• They perform a password reset
• These customer-facing epics form the backbone of the user story map.

Plus, in this session, we also included technical epics for stuff we needed from other teams at Twitter. For example, this team didn’t control all the authentication, so they added a technical epic to have a conversation with another team to get that piece on their backlog so they had everything they needed for the experiment.

Step 4: The stories

As we fleshed out the epics, we built out the user stories below each of them.

Step 5: Cut lines

Typically, your team would do estimation and cut lines at this point, but we didn’t need to because timing was less relevant. We had to include all the essential stories to successfully run the experiment.

We did our user story mapping physically on a whiteboard, so we used tape to separate what was in and out of sprint one, two, and three. We had the backlog on the right hand side, which consisted of anything we’d discussed that we couldn’t include this time, but we wanted to come back to later. Maybe some items weren’t applicable to this persona, or we’d come back to it for IOS.

In other scenarios, we’d order the stories based on what we understood would provide the most value, estimate with story points , and then plan the capacity for a week or fortnight of work, based on historical velocity. Then we’d sequence the stories into sprint and versions. Sequencing might involve moving up something of lower customer value because you can fit it in. You might also need to break down a bigger or riskier story and split it into two user stories.

Throughout the process, everyone had the opportunity to voice their opinions (there’s nothing more frustrating than not being heard or listened to) and we’d put it on the board. One of my roles as the facilitator was to manage everyone in the room - from the quietest person to the most outgoing person.

If someone was being quiet, I’d pull them into the discussion and ask them for their thoughts directly. It’s important to pull in from different participants to get a holistic vision or understanding. Because at the end of the day, the purpose of user story mapping is to get the team on the same page. If the team sets off and they haven’t bought into the vision, they’ll soon find that everyone has a different understanding of what’s meant to happen. It’s less about the process, and much more about the alignment of the team.

As a result of this user story mapping process, the project took a new direction where the app would use the device identifier along with the username to figure out who the user was before they log in. This would allow them to get straight into the timeline so they can get value.

But if they wanted to complete any actions (like Tweet, RT, or like a Tweet), they’d need to put in a password (and would hopefully be engaged enough to complete the process). Overall, it was a very successful user story mapping session!

Physical vs digital user story mapping

So, now that you know the steps in user story mapping, how do you actually implement them?

Traditionally, user story mapping is done physically. You get your team in a room, write out the backbone and user stories on post-it notes, arrange them on a wall, and use a string to represent the cut lines or swimlanes.

It might look a bit like this:

But this process does come with some challenges:

• You’ll have to find and book a room for a day (or longer if you need to map a complex product and user journey)
• We all know that post-it notes have a tendency to lose their stickiness and fall off the wall (even if you totally nail your peeling technique)
• Even if you involve remote team members using video conferencing, it’s tricky for them to read post-its - and of course, much harder for them to contribute
• A team member will still need to enter all the data into Jira once your user story mapping session is done (it’ll look like the below screenshot, which doesn’t resemble your physical story map too much)

“When I worked at Twitter, they tried to do physical user story mapping over video conferencing to include distributed team members. It was challenging. There’d be a lot of ‘Hey Nick, what does this say?’ and I’d need to read it out or type it out on chat.”

That’s why it’s often better to use a tool or app to do your user story mapping digitally.

While there are a couple of user story mapping apps and software options, the most efficient approach is to use a user mapping tool that integrates directly with Jira.

That way, you don’t have to transfer your work into Jira - your team can move straight into working on their top priority stories as soon as you wrap up your mapping session.

Read ➡️ User Story Mapping for Remote Teams

If the last year is anything to go by, read more on: User Story Mapping for Remote Teams

Jira + Easy Agile TeamRhythm

Jira on its own doesn’t allow you to do user story mapping. It doesn’t replicate the physical session with sticky notes and an X axis. The best it can do is a flat backlog - and hopefully by now, you know that’s not good enough for most teams.

Fortunately, you can run a digital and collaborative story mapping session right inside Jira with Easy Agile TeamRhythm, which is an add-on for Jira.

Here’s how it works:

Add user story mapping capabilities to Jira

Add Easy Agile TeamRhythm to your Jira account. You can get started with a free 30-day trial.

If you open TeamRhythm from an agile board that’s already in use, it’ll automatically get populated with your board’s data, with current issues added to the backlog panel in the right hand panel. But don’t worry - you can easily edit this data. And if it’s a new agile board, you can easily add your backbone, stories, and swimlanes from scratch.

Set up your backbone

Across the top of the board you’ll create a horizontal row of epics (if you already have epics associated with your board, this will be pre-populated). Each epic represents an activity of the users flow through the product. This is often referred to as the 'backbone' of the story map.

These epics can be dragged and dropped and the order of the epics will be reflected on the backlog using Jira ranking.

Creating new epics right inside the story map is simple with Easy Agile. Simply click the “Create Epic” button in the top right of the screen. Add the name and description, then click “Create”. Scroll to the far right of your story map to find your new epic.

Don’t worry about getting everything perfect right away. You have the ability to edit them in-line later.

Add the flesh (or stories!)

Beneath each epic on the backbone, you’ll see any linked User Stories that are ordered by rank. To add a new story, hover over the space where you want to create your story and click “new”. Enter the name of your story and select your issue type from the drop-down (e.g. task, story, or bug). You can also access the Backlog panel to add existing stories or issues - simply click “existing”, search for your issue, and add it.

You can also drag issues in from the backlog panel.

And just like epics, you can edit your stories in-line by clicking on the name of the issue.

Order your epics and stories

Now, put your epics and stories in order. Your epics should reflect your customer’s journey from beginning to end. And your stories should be ordered by the value they deliver to customers.

In Easy Agile apps, you can click and drag to rearrange your stories and epics. And if you move an epic, the associated stories underneath will move with it.

Estimate work

Hover over the estimate field (the gray number on the bottom of each story item). Click to add or edit story points .

Read ➡️ Agile Estimation Techniques

Add and arrange swimlanes (version/sprint)

Now it’s time to decide what issues your team will tackle when by horizontally slicing up the work. Click on the swimlanes button in the top right. You can choose to sequence work by sprints or versions (depending on whether you’re Scrum or Kanban*). Your sprints or versions will appear in chronological order on the story map, and there’s an “add sprint” button at the bottom of the story map where your team can add additional sprints and versions.

* With Kanban, you’d typically sequence work into versions, as there is no sprint. This can help your team whittle down the long list of stories into the 'now' and 'future' buckets.

You can easily drag and drop stories, mapping them to the appropriate swimlane.

Check team velocity to avoid over committing your team during each sprint or version. Hover over the “Not started”, “In progress”, and “Done” indicators on the far right of the sprint or version swimlane to see how your story points are tracking across all the stories and issues. If you have too many story points , you can move some stories to the next sprint or version.

Read ➡️ Agile Story Points: Measure Effort Like a Pro

Try out different views

You can search or create a Quick Filter based on a text search (e.g. contains "As a parent"). Or if you’re using our other product, Easy Agile Personas, we have a tutorial on how you can create a Quick Filter by persona. That way, you can refine your story map and narrow in on what’s really important to you.

Get to work!

All changes made inside the story mapping session are automatically reflected in Jira, so your team can leave the story mapping session ready to start their work.

Get started with Easy Agile TeamRhythm

Easy Agile TeamRhythm works out of the box with your existing backlog (so getting started is super quick and simple). But it gives you that extra dimension to help bring your backlog to life. It’s aliiiiive!

Want to check it out for yourself? We have two options:

OR play around with our demo (no installation or sign-up needed) :-)

But don’t just listen to us. Here’s what some of our customers have to say:

Jira software is great for following activities and backlogs, but it’s easy to lose the vision of your product without user story mapping. Easy Agile User Story Mapping allows the teams to communicate - not only about activity but also the vision of the product. Some of our teams regularly refer to this tool for retrospectives, and it helps them make the product their product.

We’ve found that Easy Agile User Story Maps brings the team together in one room. As a result, we find ourselves mapping more as a group, which creates a common understanding. Since using the add-on, we’ve been able to speed up planning and more efficiently conduct large story mapping exercises.

Since using Easy Agile User Story Maps, we’ve improved our communication and team alignment, which has helped give us faster results.

Easy Agile User Story Maps has helped us visualize our workload and goals, as well as speed up our meetings. We love the simplicity!

See what all the fuss is about

Start your free 30 day trial

Psst: It’s the fastest growing and highest-rated story mapping app for Jira! You’re going to love it.

6 ways to keep your story map alive

Speaking of bringing things to life, we’ve got a few final tips...

Your user story map is designed to be a living, breathing thing so that it can help your team continuously deliver value to your customers. But you’ll miss out on these benefits if your team doesn't continually use it, reflect on it, and refine it.

Here are 6 ways you can keep your backlog alive:

1. Progress tracking

As your team delivers releases, they can visually track their progress against the user story map. With Easy Agile User Story Maps, updates in Jira are reflected directly in the user story map so you can check what percentage of work has been completed. This enables you to identify problems early on and adjust your team’s workload (and future versions/sprints) if needed.

2. Backlog grooming

The purpose of backlog grooming is to maintain a healthy, up-to-date product backlog, ready for efficient sprint planning. A few days before your sprint planning meeting, your product manager will:

• Delete user stories that aren’t relevant anymore
• Create new user stories as needs become clearer
• Assign and correct estimates
• Split user stories that are too big
• Rewrite stories to make them clearer
• Ensure stories are ordered by priority
• Make sure stories at the top are ready to be delivered

It’s much easier to do this using Easy Agile User Story Maps (rather than a flat backlog) because your product manager and team can see all the contextual information. They can shuffle the order around by clicking and dragging, and can quickly update issues with in-line editing.

3. Sprint/release planning

Sprint planning is done at the beginning of every sprint. It’s designed to help your team agree on a goal for the next sprint and the set of backlog items that will help them achieve it. This involves prioritizing backlog items (this should be straightforward, thanks to backlog grooming) and agreeing on what items your team has capacity for during the sprint. Sprint planning sessions tend to run a lot more smoothly when you refer to your user story map. With Easy Agile User Story Maps, you can update your story map with backlog items as you go, and all your changes are reflected in Jira so your team can start work on the sprint straight away.

4. Sprint reviews

At the end of each sprint, your team will do a sprint review to see whether the goal was achieved and that your increment led to a working, shippable product release. Your product manager will look at the “Done” items from the backlog, and the development team will demonstrate the work they’ve done.

The team talks about what went well, any problems, and how they were solved or could be solved. They review the timeline, budget, and potential capabilities for the next planned product release, which puts the gears into motion for the next backlog grooming and sprint planning session.

In Easy Agile User Story Maps, you can easily filter your view to show “done” issues, see sprint statistics, and update story point estimates. That way, you can do a quick and collaborative sprint review meeting, right inside Jira.

5. Roadmaps

You can use your story map to communicate your roadmap with stakeholders and share the product vision. With your upcoming releases and sprints mapped out, it’s easy to see which parts of the customer journey are going to see an update or improvement, and when.

6. Retrospectives

Retrospectives are often held at the end of your sprint or release. Or you might hold them after an event, presentation, every month, or every quarter. Retros are used to help your team reflect on what’s gone well, what could have gone better, and what they’d do differently next time. Your user story map can give your team a visual point of reference during retrospectives, and help them stay focused on the user.

How to learn more about user story mapping

We’re almost at the end, but don’t stop here! There’s so much more to learn if you want to go deeper with user story mapping.

Here are some resources worth looking into:

User story mapping books

Jeff Patton wrote THE book on user story mapping, called User Story Mapping: Discover the Whole Story, Build the Right Product . Jeff was the original user story mapper - at least, he’s credited with inventing the concept and practice.

User story mapping articles

Here are some articles written by us over the last few years:

Story maps - A visual tool for customer focused development (this one has a great video)

How to write good user stories in agile software development

The difference between a flat product backlog and a user story map

Anatomy of an agile user story map

That’s it! You’ve finished the user story mapping ultimate guide! 👏

You have all the tools and info you need to…

• Run your first user story mapping session
• Do story mapping more effectively (and confidently)
• Get more from your story map
• Prioritize your work to deliver maximum value to customers, as quickly and as often as possible
• Work more collaboratively
• Accurately schedule your work
• Understand the why behind the work

Go forth and story map! And let us know how you go.

If you have any questions about user story maps, we’d love to hear from you. You can contact us or send us a tweet @EasyAgile. We’ll update this guide as we come across more user story mapping tips, techniques, and frequently asked questions.

Don't forget to try

Easy Agile TeamRhythm

Online user story mapping for remote teams

Story Points: definition, how-to & why they matter

How Ubisoft fosters focused creativity with Easy Agile

Subscribe to our blog.

Keep up with the latest tips and updates.

Skip navigation

World Leaders in Research-Based User Experience

When and how to create customer journey maps.

July 31, 2016 2016-07-31

• Email article
• Share on LinkedIn
• Share on Twitter

In This Article:

What is a customer journey map, deconstruction of a customer journey map, why do you need a journey map and when should you have one, key elements of customer journey maps, rules for creating successful journey maps.

In its most basic form, journey mapping starts by compiling a series of user goals and actions into a timeline skeleton. Next, the skeleton is fleshed out with user thoughts and emotions in order to create a narrative. Finally, that narrative is condensed into a visualization used to communicate insights that will inform design processes.

Storytelling and visualization are essential facets of journey mapping because they are effective mechanisms for conveying information in a way that is memorable, concise and that creates a shared vision. Fragmented understanding is chronic in organizations where KPIs are assigned and measured per individual department or group because many organizations do not ever piece together the entire experience from the user’s standpoint. This shared vision is a critical aim of journey mapping, because without it, agreement on how to improve customer experience would never take place.

Journey mapping creates a holistic view of customer experience, and it’s this process of bringing together and visualizing disparate data points that can engage otherwise disinterested stakeholders from across groups and spur collaborative conversation and change.

Zone A: The lens provides constraints for the map by assigning (1) a persona (“who”) and (2) the scenario to be examined (“what”).

Zone B: The heart of the map is the visualized experience, usually aligned across (3) chunkable phases of the journey. The (4) actions, (5) thoughts, and (6) emotional experience of the user has throughout the journey can be supplemented with quotes or videos from research.

Zone C: The output should vary based on the business goal the map supports, but it could describe the insights and pain points discovered, and the (7) opportunities to focus on going forward, as well as (8) internal ownership.

Journey maps should always be created to support a known business goal. Maps that do not align to a business goal will not result in applicable insight. The goal could be an external issue, such as learning about a specific persona’s purchasing behaviors, or an internal issue, such as addressing lack of ownership over certain parts of the customer experience. Some potential business goals that journey mapping could be applied toward are listed below.

Shift a company’s perspective from inside-out to outside-in. If an organization lets internal processes and systems drive decisions that affect customer experience, a journey map could help turn the culture of that organization by refocusing on the thoughts, actions and emotions of customers. Journey mapping sheds light on real human experiences that often organizations know very little about.

Break down silos to create one shared, organization-wide vision. Because journey maps create a vision of the entire customer journey, they become a tool for creating cross-department conversation and collaboration. Journey mapping could be the first step in building an organization-wide plan of action to invest in customer experience, as it helps answer the question, “Where do we start?” by highlighting areas of friction.

Assign ownership of key touchpoints to internal departments. Often, areas of inconsistencies and glitches in customer journeys exist simply because no internal team has been tasked with ownership of that element. Journey maps can create clarity around alignment of departments or groups with different stages or key touchpoints in the journey that need addressing.

Target specific customers. Journey maps can help teams focus in on specific personas or customers, whether that means understanding differences or similarities across the journeys of multiple personas, prioritizing a high-value persona or exploring ways to target a new type of customer.

Understand quantitative data. If you are aware through analytics or other quantitative data that something specific is happening—maybe online sales are plateauing or an online tool is being underutilized—journey mapping can help you find out why.

While journey maps can (and should) take a wide variety of forms, certain elements are generally included:

Point of view. First and foremost, choose the “actor” of the story. Who is this journey map about? For example, a university might choose either students or faculty members, both of which would result in very different journeys. “Actors” usually aligns with personas, if they exist. As a guideline, when creating a basic journey map, use one point of view per map in order to provide a strong, clear narrative.

Scenario. Next, determine the specific experience to map. This could be an existing journey, where mapping will uncover positive and negative moments within that current experience, or a “to-be” experience, where the mapper is designing a journey for a product or service that doesn’t exist yet. Make sure to clarify the user’s goal during this experience. Journey maps are best for scenarios that describe a sequence of events, such as purchasing behavior or taking a trip.

Actions, mindsets, and emotions. At the heart of a journey map’s narrative is what the user is doing, thinking, and feeling during the journey. These data points should be based on qualitative research, such as field studies, contextual inquiry, and diary studies . The granularity of representation can vary based on the purpose of the map. Is the purpose to evaluate or design an entire, broad purchasing cycle or a contained system?

Touchpoints and channels. The map should align touchpoints (times when the actor in the map actually interacts with the company) and channels (methods of communication or service delivery, such as the website or physical store) with user goals and actions. These elements deserve a special emphasis because they are often where brand inconsistencies and disconnected experiences are uncovered.

Insights and ownership. The entire point of the journey-mapping process is to uncover gaps in the user experience (which are particularly common in omnichannel journeys), and then take action to optimize the experience. Insights and ownership are critical elements that are often overlooked. Any insights that emerge from journey mapping should be explicitly listed. If politically possible, also assign ownership for different parts of the journey map, so that it’s clear who’s in charge of what aspect of the customer journey. Without ownership, no one has responsibility or empowerment to change anything.

Even with all the above critical elements included, two journey maps could look completely different, yet both be perfectly suitable for the context in which they were designed.Tradeoffs in scope, focus, and breadth vs. depth are required when deciding on what elements to include. To make informed decisions on those tradeoffs, consider the following:

• What level of detail is needed in order to tell the complete story?
• What elements (such as device, channel, encountered content) are also necessary in order to provide the most truthful narrative?
• Is the purpose of this journey map to diagnose issues with a current experience or to design a new experience?
• What’s the balance between external actions (on the customer side) and internal actions (on the organization side)?
• Who will be using this journey map?

Successful journey maps require more than just the inclusion of the “right” elements. Journey mapping should be a collaborative process informed by well-defined goals, and built from research. It requires hard work to keep the process on the right track and to build the buy-in needed to evangelize the insights it provides. Below are some tips for making sure that the process starts and stays in the right direction:

Establish the “why" and the “what.”  First, identify the business goal that the journey map will support. Make sure there are clear answers to these basic key questions before you begin the process:

• What business goal does this journey map support?
• Who will use it?
• Who is it about and what experience does it address?
• How will it be shared?

Base it on truth. Journey maps should result in truthful narratives, not fairy tales. Start with gathering any existing research, but additional journey-based research is also needed to fill in the gaps that the existing research won’t cover. This is a qualitative-research process. While quantitative data can help support or validate (or aid in convincing stakeholders who may view qualitative data as “fuzzy”), quantitative data alone cannot build a story .

Collaborate with others. The activity of journey mapping (not the output itself) is often the most valuable part of the process, so involve others. Pull back the curtain and invite stakeholders from various groups to be a part of compiling the data and building the map.

Don’t jump to visualization. The temptation to create an aesthetic graphic or jump to design can lead to beautiful yet flawed journey maps. Make sure the synthesis of your data is complete and well-understood before moving to creating the visual.

Engage others with the end product. Don’t expect to get “buy-in” and foster interest in your journey map by simply sending a lovely graphic as an email attachment. Make it a living interactive document that people can be a part of. Bring up your story in meetings and conversations to promote a narrative that others believe in and begin to reference. One idea is to create a journey-mapping showroom where anyone not on the direct team can come experience the process and resulting artifacts.

Free Downloads

Related courses, journey mapping to understand customer needs.

Capture and communicate UX insights across complex interactions

Omnichannel Journeys and Customer Experience

Create a usable and cohesive cross-channel experience by following guidelines to resolve common user pain points in a multi-channel landscape

Interaction

Generating Big Ideas with Design Thinking

Unearthing user pain points to drive breakthrough design concepts

Related Topics

• Customer Journeys Customer Journeys
• Design Process
• Research Methods

Learn More:

Please accept marketing cookies to view the embedded video. https://www.youtube.com/watch?v=2W13ext26kQ

Customer Journey Mapping 101

Interactive UX Maps 101

Megan Brown · 4 min

Journey Mapping: 2 Decisions to Make Before You Begin

Kate Kaplan · 3 min

Scenario Mapping for Design Exploration

Kim Salazar · 3 min

Related Articles:

Journey Mapping 101

Sarah Gibbons · 7 min

Journey Mapping: 9 Frequently Asked Questions

Alita Joyce and Kate Kaplan · 7 min

Luxury Shopping User Groups and Journeys

Kate Moran · 14 min

User Experience vs. Customer Experience: What’s The Difference?

Kim Salazar · 5 min

Seamlessness in the Omnichannel User Experience

Kim Salazar · 12 min

How to Conduct Research for Customer Journey-Mapping

Kate Kaplan · 7 min

User Journey | How it improves Agile process

In the dynamic realm of product development, understanding and meeting user needs are fundamental to success. It’s no longer sufficient to merely offer a functional product; the true essence of innovation lies in crafting an experience that resonates with your target audience. 

In this fast-paced landscape, the user journey emerges as a pivotal concept, offering a path for developers to empathize with their users and view their creations from a user-centric perspective.

Table of Contents

Understanding User Journey Mapping

Enhanced user-centricity, improved product quality, increased customer retention and loyalty, efficient resource allocation, agile evolution, integration of user journey mapping into agile methodologies, influence of user journey on sprint planning and backlog refinement, 1. define clear objectives:, 2. create user personas:, 3. map out the user journey:, 4. integrate user journey into agile practices:, 5. regular iteration and feedback:, 6. foster cross-functional collaboration:, time constraints, keeping maps updated, resistance to change, over-complexity.

A user journey is a user’s path when interacting with your product or service. It encompasses their entire experience, from the moment they become aware of your offering to the point where they achieve their goals or complete specific tasks using your product. Understanding this journey is akin to stepping into your users’ shoes, allowing you to see your product from their perspective.

In the fast-paced world of product development, understanding your users is paramount. It’s not just about creating a functional product; it’s about crafting an experience that resonates with your target audience. This is where the concept of the user journey comes into play.

At the heart of user journey mapping lies a fundamental principle of customer-centered design. User-centered design is an approach that prioritizes the needs and preferences of users in every phase of product development.

Benefits of Incorporating User Journey

Incorporating user journey mapping into Agile processes offers a multitude of benefits that go beyond the confines of traditional development methodologies.

User journey mapping fosters a deep understanding of your customers’ needs, motivations, and pain points. In the Agile context, this means that every development decision is rooted in user-centricity.

This laser focus on customer needs ensures that the product aligns more closely with user expectations, ultimately leading to higher levels of user satisfaction.

When user journey mapping becomes an integral part of Agile processes, it acts as a quality assurance mechanism. By visualizing the entire user experience, teams can identify potential bottlenecks, usability issues, or areas of friction. 

Early detection of these problems allows for swift resolution and refinement before they can affect the end product.

A delightful user experience isn’t just about attracting new customers; it’s also about retaining and nurturing existing ones. User journey mapping in Agile processes provides a clear roadmap for enhancing the user experience over time.

Satisfied customers are not only less likely to churn but also more likely to become advocates, spreading positive word-of-mouth and contributing to customer growth.

Agile development emphasizes flexibility and adaptability. When user journey mapping is integrated into this framework, it becomes easier to allocate resources efficiently. 

This strategic resource allocation leads to a more streamlined development process and optimized use of resources.

Agile methodologies thrive on constant evolution and refinement. User journey mapping fits seamlessly into this iterative approach.

This adaptability ensures that the product remains aligned with evolving user needs and preferences.

How User Journey Enhances Agile

User journey mapping can be seamlessly integrated into Agile methodologies such as Scrum and Kanban, enhancing the overall development process. Here’s how:

• Scrum: In Scrum, user journey maps can be used as a valuable tool during sprint planning and backlog refinement. Teams can create and review user journey maps to gain a holistic understanding of user needs and prioritize user stories accordingly. The user journey can also help Scrum teams define the scope of a sprint and set sprint goals, ensuring that each sprint delivers value aligned with the user experience.
• Kanban: Kanban’s visual nature aligns well with user journey mapping. User journey maps can be represented on the Kanban board to provide a clear overview of the entire user experience. As user stories progress through the workflow, teams can visualize how they contribute to the user journey, helping to ensure that work items remain user-centric and that blockers are addressed promptly.
• Sprint Planning: User journey maps provide a roadmap for sprint planning. Teams can reference the user journey to select user stories that align with the next steps in the journey. By doing so, sprint planning becomes more focused on delivering value that directly contributes to the overarching user experience.
• Backlog Refinement: During backlog refinement sessions, user journey maps help teams assess the relevance of user stories and features. They can identify gaps in the user journey and address them by adding or refining user stories in the backlog. 

Practical Steps to Implement User Journey in Agile

Here are six practical steps to help Agile teams implement user journey mapping into their development process effectively:

Identify Your Goals: Begin by setting clear objectives for integrating user journey mapping into your Agile process. Determine what you want to achieve, whether it’s improving user satisfaction, enhancing product quality, or increasing customer retention.

Develop User Personas : Before diving into user journey mapping, create well-defined user personas. These personas represent different user types and their specific needs and behaviors. Customer personas will serve as the foundation for your user journey maps.

Manage your user persona with ProductGo – Agile User Story Maps, Roadmaps & Persona for Jira

Identify User Touchpoints: Outline the key touchpoints where users interact with your product or service. This includes initial awareness, onboarding, core interactions, and any potential exit points.

Document User Steps and Emotions: For each touchpoint, detail the steps users take and the emotions they may experience. Understanding both the practical and emotional aspects of the journey is crucial.

Visualize the Journey: Create a visual representation of the user journey. You can use software tools, whiteboards, or even pen and paper to sketch out the journey. Include user personas, steps, and emotions to make it comprehensive.

Sprint Planning: During sprint planning, reference the user journey to select user stories that align with the next steps in the journey. Prioritize stories that address critical touchpoints or pain points for your users.

Backlog Refinement: In backlog refinement sessions, assess the relevance of user stories in the context of the user journey. Ensure that stories are aligned with the overarching user experience and identify gaps in the journey.

Iterate Continuously: User journey mapping is not a one-time activity. It should evolve alongside your product and user needs. Regularly revisit and update the maps to reflect changes in the user experience.

Gather User Feedback: Actively seek user feedback to validate and refine your user journey maps. User testing, surveys, and interviews can provide valuable insights into how well your product aligns with the mapped journeys.

Collaborate Actively: Involve cross-functional team members, including designers, developers, product owners, and testers, in the user journey mapping process. Different perspectives will lead to a more comprehensive understanding of the user experience.

Promote Communication: Encourage open communication within the team by using the user journey map as a shared reference point. This ensures that everyone is aligned with the user-centric goals of the project.

Challenges and How to Overcome Them

Agile projects often operate on tight schedules, leaving limited time for comprehensive user journey mapping.

Solution: Prioritize mapping the most critical user journeys first. Start with key touchpoints and gradually expand as time allows. Consider using lightweight mapping techniques to save time initially.

User journeys evolve as products and user needs change, making it challenging to keep maps up to date.

Solution: Schedule regular reviews and updates of user journey maps as part of your Agile process. Use feedback from user testing and customer support to inform updates. Make map maintenance a team responsibility.

Team members or stakeholders may resist adopting user journey mapping, seeing it as an additional overhead.

Solution: Educate the team on the benefits of user journey mapping, emphasizing how it enhances user-centricity and aligns with Agile principles. Start with small, low-risk mapping exercises to build buy-in gradually.

User journey maps can become overly complex, making it challenging to extract actionable insights.

Solution: Focus on simplicity. Keep maps clear and concise, emphasizing the most critical user interactions. Use visualization techniques that make it easy for team members to understand and engage with the maps. Avoid unnecessary details.

Incorporating user journey mapping into Agile processes isn’t just a best practice; it’s a transformative step towards delivering remarkable user experiences. By embracing the user journey, Agile teams anchor themselves in user-centricity, resulting in higher levels of user satisfaction. 

This methodology acts as a quality assurance mechanism, identifying and resolving issues before they tarnish the end product. Furthermore, it paves the way for increased customer retention and loyalty, as satisfied users are not only more likely to stay but also to advocate for your product.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Proto-Persona: Differences and Similarities with Persona

Three C’s of User Stories – Card, Conversion & Confirmation

Manage Multiple Projects in Jira with User Story Map (How To Do It & Benefits)

Understanding Agile Requirements Gathering

Enhancing Product Backlog Management with User Story Mapping

Agile Product Owner’s Role and Responsibilities

What is a sprint backlog? How to create one, with examples

What is Epic in Agile?

What is the difference between product backlog and user story?

What Is Agile Project Management And How To Apply This For Your Project?

Journey Mapping

.css-3n7dj1{box-sizing:border-box;margin:0;min-width:0;display:block;color:var(--theme-ui-colors-heading,#edf2f7);font-weight:bold;-webkit-text-decoration:none;text-decoration:none;margin-bottom:1rem;font-size:1.5rem;position:relative;} Definition of Journey Mapping

Journey Mapping is a visualization technique that illustrates the experience of a user across a product, service, or brand.

Miranda Dulin

Scrum master, table of contents, buy me a coffee, are you gaining value and insights from agile ambition if you love what you're learning and want to see more, here's a simple way to show your support. click the "buy me a coffee" button to make a small donation. each coffee you buy fuels our journey to discover better ways of working by unpuzzling agile, one piece at a time..

Quick Links

Legal Stuff

Social Media

Open Agile Architecture™

• Open Agile Architecture
• Part 1: The O-AA Core
• 10. Building Blocks Overview
• 11. Agile Strategy
• 12. Agile Organization
• 13. Experience Design
• 14. Product Architecture

15.1. Moments of Truth

15.2. the human side, 15.3. the role of automation, 15.4. concluding words.

• 16. Lean Value Stream Mapping
• 17. Operations Architecture
• 18. Data Information and Artificial Intelligence (AI)
• 19. Event Storming
• 20. Domain-Driven Design: Strategic Patterns
• 21. Software Architecture
• 22. Software Defined Infrastructure
• Appendix A: Acronyms

15. Journey Mapping

This document uses the term “journey map” to refer to an alignment diagram , which is any map, diagram, or visualization that reveals both sides of value creation in a single overview [ Kalbach 2016 ]. Alignment diagrams have two parts: a description of an experience and a description of an enterprise product, with the interaction between the two. Journey maps and service blueprints are alignment diagrams.

Some touchpoints, such as a newsletter or an advertisement, do not allow users to interact. Interactions can be automated; for example, interacting with a chatbot in a self-care situation. Human-to-human interactions can be “in person” or conducted remotely using collaboration technology.

Figure 35 is an example of an alignment diagram which represents both sides of value creation.

Specifies the channel(s) that support(s) the interaction

Describes the actual or desired customer experience

Presents the needed features or functionalities

If the existing operations or software are not good enough to support the targeted experience quality, you have to settle for a lesser quality unless the supporting operations or software are improved.

The “Missing Features” line identifies the new functionalities that must be developed to deliver the expected customer experience.

Not all interactions are equal. Some interactions, referred to as “moments of truth”, matter more than others.

McKinsey defines moments of truth as:

Those few interactions (for instance, a lost credit card, a canceled flight, a damaged piece of clothing, or investment advice) when customers invest a high amount of emotional energy in the outcome [ Beaujean 2006 ].

How well or how poorly the enterprise handles moments of truth has a decisive impact on the quality of the customer experience. Moments of truth test the quality of operations because:

They require that at the same time employees respect service standards and show initiative to resolve a client’s problems, even though they may be unexpected

Lessons learned solving unexpected problems should be incorporated into service standards to help prevent similar problems from happening in the first place

Defects in existing processes and software are a frequent cause of poor customer experience

This document recommends using moments of truth to prioritize operational improvements [ Patton 2014 ].

Focusing on specific target outcomes is the secret to prioritizing development work.

The goal should be to maximize outcomes while minimizing costs by minimizing new features development. The focus on moments of truth gives the opportunity for cross-functional teams to develop their level of understanding of what really matters and to explore the space of solutions to discover the best way to deliver an outstanding experience.

This is illustrated with the example of a housing rental enterprise. The first moment of truth for new prospects is to be rapidly informed when available properties that meet their needs become available.

What does it mean to be informed rapidly? Is it to receive a choice of properties immediately? The next business day? How can the enterprise ensure the choice of property meets client needs? Answering these questions requires a deep understanding of client expectations and also the ability to determine which operating model improvements are required.

Generating a short list of available houses or apartments that meet needs most of the time is critical to the moment of truth. If clients rapidly receive a list containing mostly properties that do not match their needs, they will be rapidly disappointed. In order to prevent this, the enterprise needs a very large inventory. This may require the enterprise to develop new sources of rental properties that it can add to its inventory.

In addition to the large inventory requirement, new features are needed:

The enterprise needs access to an inventory of available housing for rent

That inventory must be updated in real time

Smart search algorithms that select properties on criteria such as the number of rooms or the distance to public transportation

Mistakes and errors are inevitable, but dissatisfied customers are not. Paradoxically, when a service defect such as a late delivery or a lost parcel is fixed, frustrated customers can become more loyal than they would if no problem had occurred.

The difficulty is to grant employees the freedom and the responsibility not to follow “standard operating procedures” when solving urgent or important customer problems. The enterprise needs to:

Give meaning and clarity of purpose to front-line employees

Influence the mindset of employees so they develop their emotional intelligence

Adjust the reward system to reinforce the right behavior

Design the work system so it has enough slack for employees to take the time to solve customer problems

Ensure this is considered as part of a broader transformation approach, such as the one described in Chapter 7 .

Digital technologies, in particular AI, dramatically expand the scope of what can be automated. Does this mean the automation potential should be pushed to its limits? Not necessarily; for example:

Automation increases the need for maintenance, which requires skilled workers

The impact of automating one task is felt beyond that one task

When automation is visible to the client it can change customer experience

New risks can emerge when automation fails; for example, when operators have lost essential skills

Automating requires a careful assessment of benefits and drawbacks. Instead of automating in a big bang manner, the Agile enterprise will conduct experiments and automate using an incremental approach when possible.

Automation failures come in two forms: misses and false alarms. For example, the system has failed to detect a harmful situation, or the system acted when it should not have.

A failure to detect can harm the customer; for example, a fraudulent payment not being prevented by an automated fraud detection algorithm. On the other hand, if the fraud detection algorithm disables a credit card when the client is abroad late at night and during a weekend, it becomes a service failure in the case of a false-positive.

Computers and humans have distinct abilities. Therefore, augmenting the human with the power of automation and AI could be a legitimate goal if the man-computer symbiosis is achieved.

When automation is used as an augmentative tool, it leaves decisions to humans. Now that deep learning scores better than humans in the accomplishment of many tasks, should there be a switch to fully-automated decisioning? What happens when an unforeseen event occurs that the machine is not capable of handling?

Journey mapping is a great tool to help align experience mapping with the operating system that is supposed to deliver it. When the mismatch between experience and target operating model cannot be solved locally, it is necessary to look at the operating system as a whole. Improving the human side and automating will often require a holistic approach.

← Previous:  Product Architecture  | ↑ Up:  Part 2: The O-AA Building Blocks  | ⌂ Home:  Open Agile Architecture™  | Next:  Lean Value Stream Mapping  →

Agile story mapping: bridging ideas and execution

Imagine a world where project management isn’t a maze of fixed plans and rigid steps. That’s where Agile shines. It guides teams through a flexible, iterative journey. Instead of a bulky, set-in-stone map, Agile uses frequent updates to navigate projects. It’s about adapting to changes and delivering results in small, manageable chunks. This approach ensures that teams can quickly respond to new information or shifts in priorities.

Now, enter Agile story mapping. Think of it as a powerful tool in the Agile toolkit. It’s essentially a project storyboard.

Story mapping lays out all the steps (or user stories) your project needs to take, but in a visual, easy-to-understand way. It’s not just a list of tasks; it’s a narrative of the user’s journey through your product.

This method helps teams visualize the big picture while keeping track of the tiny yet crucial details. In project management, it’s a game-changer. It bridges the gap between what users need and what teams build. And it ensures that every developed feature aligns with actual user requirements.

Agile story mapping fosters a deeper understanding of the project scope and keeps everyone on the same page. It’s about creating a shared product vision that guides your team through the complexities of development. It also ensures that the end product truly resonates with users. So Agile story mapping is helpful for product management too.

Let’s explore Agile story mapping a bit more – follow along!

Story mapping as a visual technique in Agile

In Agile , story mapping stands out as a visual technique. It brings a project’s narrative to life. It’s like drawing a map instead of just writing directions. This map shows each task as a part of a larger story, visually laying out the path of the project. It turns abstract ideas and goals into a clear, visual layout.

This visual aspect is key in Agile. It helps teams see what they need to do and how everything connects and progresses.

Now, let’s dive deeper into the specifics of story mapping.

The purpose of story mapping: facilitating product discovery and prioritization

Story mapping in Agile is a visual tool that teams use to lay out the entire journey of a product, piece by piece.

Imagine each task or feature as a puzzle piece. Story mapping helps you see how they all fit together. This technique helps a product manager understand what the product needs first and what can wait. It’s all about finding what’s most important for the user and tackling that first. This way, teams can focus on delivering real value, step by step.

Brief history: Jeff Patton’s contribution to story mapping

The story behind story mapping is pretty interesting. Jeff Patton , a big name in the Agile world, played a key role in developing this technique. He realized that while lists of tasks are good, they don’t show the whole picture. So, he introduced story mapping to give a panoramic view of the project. Thanks to Patton, teams now have a tool that combines the simplicity of lists with the clarity of a visual map.

User story mapping versus customer journey mapping

Now, let’s clear up some confusion. User story mapping and customer journey mapping might sound similar, but they’re different.

User story mapping focuses on what the product team needs to do, step by step.

On the other hand, customer journey mapping is about the user’s experience.

User story mapping guides the building process. And customer journey mapping offers insights into how users feel and react to the product.

Creating Agile story maps is not just about organizing tasks. It’s a strategic approach that aligns with core Agile values and principles. Let’s explore why story maps are vital in Agile project management.

Why create Agile story maps?

Have you ever wondered why Agile teams often turn to story mapping? It’s not just another task on their to-do list. 

It’s a tool that transforms the way teams approach, plan, and execute projects. Visually organizing tasks and user stories clarifies and directs the development process.

Let’s delve into the specifics. What really makes Agile story maps indispensable for Agile project management?

The Agile values supported by story mapping

• Customer collaboration . Story maps keep the customer front and center. They help teams understand the user’s journey and needs. It’s like having a constant reminder of who you’re building for. This focus on the customer strengthens collaboration and ensures the final product truly meets user needs.
• Adaptability to change . Agile is all about being flexible, and story maps embody this. They make it easier to see where changes can happen without derailing the whole project. Here are a few more very valuable aspects of Agile story maps.

Keeping the big picture in view

The big picture is crucial in Agile development. Story maps keep this big picture in clear view. And not just for now, but for the future of the project. This helps to keep the project’s goals and vision always in sight.

Facilitating iterative and incremental development

Agile thrives on iteration – building in small, manageable increments. Story maps are perfect for this. They break down the project into smaller stories. This makes it easier to tackle one piece at a time while keeping aligned with the overall plan.

Enhancing prioritization and identifying gaps

Story maps are also great tools for prioritization . They help teams identify what’s crucial and what can wait. They also shine a light on any gaps in the project plan.

When to create Agile story maps

How do you know when you need Agile story maps?

These visual tools aren’t just useful at the start of a project. They have their place throughout the development lifecycle. Let’s get more specific.

MVP development

At the very beginning, you’re likely developing a minimum viable product (MVP) . Story maps are invaluable here. They help you focus on the essentials.

What does your product absolutely need to function? Story maps guide you in stripping down to the bare essentials. This ensures your MVP truly embodies the ‘minimum’ and ‘viable’ aspects.

Imagine you’re creating a new app for booking fitness classes. In MVP development, a story map helps you focus on the most critical features:

• Browsing classes
• Booking a session
• Processing payments

At this point, avoid getting sidetracked by additional features. You can always add them later.

Improving existing versions

Once you have a product out there, story maps aren’t done yet. They play a crucial role in evolving and improving existing versions. You can clearly see where to improve when you map out current features and user feedback. It’s like having a roadmap for continuous improvement .

Speaking of roadmaps – do you want to build one but need help? Check out these free roadmap templates .

Let’s say your fitness app is now live, and you’re gathering user feedback . A story map can help you integrate this feedback effectively. For example, users might request a feature to sync classes with their calendars. Updating your story map will help visualize how this new feature fits with existing ones. Then, you can plan its development in your next iteration.

Managing the backlog

Handling a project backlog can be overwhelming. Story maps come to the rescue here as well. They provide a structured way to view the backlog not as a daunting list, but as part of a larger narrative. It helps prioritize features you should tackle next based on user needs and project goals. This turns a confusing list into a clear action plan.

Suppose you have a list of feature requests (a product backlog ):

• Adding a rating system for classes
• Incorporating a friend referral program
• Enhancing the user profile section

A story map organizes these backlog items into the bigger picture of your software development journey.

How to create Agile story maps

Creating an Agile story map is a step-by-step process that involves the entire team. It’s about more than just writing tasks on a board. It’s a systematic approach to understanding and organizing your project. Here’s how you can create a story map from scratch.

1. Select the teams

First, gather your teams. This includes developers, design, QA, and other relevant teams. A diverse team ensures all aspects of the project are considered from the start.

2. Identify personas

Who are you building for? Identify your user personas . These are fictional characters that represent your typical users. They help the team understand who they are creating the product for and what these users need. A user persona is best when it’s very clearly defined.

3. Identify user goals, problems, and activities

Understand your personas’ goals, problems, and typical activities. For a fitness app, this could look something like this:

• Goal – staying fit
• Problem – finding the right class
• User activity – searching for and booking classes

4. Break down goals into user stories

Turn these goals and activities into user stories. A user story is a simple statement that describes something the user wants to do. For instance:

“As a user, I want to easily find yoga classes near me.”

Learn more about user stories here .

5. Arrange user stories into a logical sequence

Place these stories on your story map in a sequence that makes sense. Think about the user’s journey through your app. What would they do first, second, third, and so on?

Let’s continue with the fitness app example. Imagine the user journey in this app, starting from the moment they open it.

• Initial interaction

The first user story might be:

“As a fitness enthusiast, I want to easily register or log in to access my personal dashboard.”

This story is about the initial interaction with the app.

• Discovering options

Next could be:

“As a user, I want to browse different fitness classes to choose one that fits my interests and schedule.”

This story reflects the discovery phase of the user journey.

• Details and decision-making

Following that:

“As a user, I want to view detailed information about each class, including time and intensity, so I can make an informed decision.”

• Booking process

Then comes:

“As a user, I want to book a class and receive confirmation effortlessly, so I am assured of my participation.”

• Post-booking engagement

“As a user, I want to receive reminders for my upcoming classes. I also want to cancel or reschedule to better control my fitness routine.”

In this sequence, each story represents a step the user takes. This logical arrangement helps in two ways. First, you map out the user’s journey. Second, you identify any potential gaps or improvements.

For instance, after mapping out these stories, you might realize you need a story about user ratings and feedback post-class. This could be vital for improving service quality.

This ordered approach helps in designing a user-friendly app. Each feature logically leads to the next, ensuring a smooth and engaging user experience.

6. Prioritize and categorize stories

Not all stories are created equal. Some are must-haves, while others are nice-to-haves. Prioritize them based on importance and categorize them into groups. For example:

• Essential features
• UX enhancements
• Engagement drivers
• Data and analytics
• Accessibility and inclusivity
• Security and compliance
• Future and expansion
• Feedback and improvement

7. Find gaps, dependencies, technical requirements, and alternatives

Look for any gaps in your stories. Are there steps in the user’s journey that are missing? Also, identify any dependencies or technical requirements for each story. This step ensures that you’re prepared for the challenges ahead.

8. Plan sprints and releases

Based on your story map, plan your sprints and releases. Decide what will be developed in each sprint and how these sprints will lead to your product releases.

9. Regularly update and adapt

Finally, remember that a story map is not set in stone. It should evolve as the project progresses. Regularly update it to reflect changes in your project, market, or user feedback.

User story mapping examples

To illustrate the power and practicality of user story mapping in Agile, let’s look at some examples. These will demonstrate how story mapping helps visualize and plan the development process.

Example 1: ecommerce website development

Imagine you’re developing an ecommerce website. The user story map would begin with user stories around browsing products. Example:

“As a shopper, I want to view a list of products to choose what to buy.”

It would then progress to stories about:

• Product details
• Adding items to a cart
• The checkout process
• Post-purchase support (like tracking deliveries)

This map would show the flow of the shopping experience. It will also highlight areas like user reviews, product recommendations, and secure payment options. All of these enhance the user experience.

Example 2: health and wellness app

For a health and wellness app, the story map might start with user registration and onboarding, like:

“As a new user, I want to easily create an account to access personalized health tips.”

Following this, the map would include stories on:

• Tracking health metrics
• Setting fitness goals
• Receiving diet and exercise recommendations
• Community features for shared experiences and support

This map helps to ensure that the app covers all aspects of the health and wellness journey – from individual goal-setting to community engagement.

Example 3: online learning platform

In the case of an online learning platform, user stories could begin with course discovery, like:

“As a learner, I want to browse various courses to find what interests me.”

The map would evolve to include stories about:

• Enrolling in courses
• Accessing learning materials
• Participating in discussions
• Submitting assignments
• Receiving feedback

The story map for this platform would highlight the educational journey. It would focus on easy access to learning materials, interactive elements, and progress tracking.

These examples show how you can apply story mapping across different projects. They illustrate the flow of user experiences. They also show how different features and functionalities form a cohesive product.

By using story maps, you can maintain a user-centric focus. And you can ensure all necessary aspects of the project are addressed and appropriately prioritized.

Common pitfalls in Agile story mapping and how to avoid them

While user story mapping is a powerful tool in Agile, there are common pitfalls that teams can encounter. Recognizing and avoiding these pitfalls is critical to successful story mapping.

Customer feedback and input

Conclusion: the value of agile story maps.

Agile story mapping is more than just a planning tool. It’s a vital component for successful Agile projects. Its visual nature turns abstract ideas into a tangible roadmap. And that guides teams through the complexities of development with clarity and purpose.

The benefits of story mapping in Agile are undeniable. They:

• Foster customer collaboration
• Adapt seamlessly to changes
• Maintain a focus on the bigger picture while managing the intricate details

The idea is to break down goals into user stories and arrange them logically. This helps teams prioritize effectively, identify gaps, and ensure every action aligns with the project’s objectives.

The true power of story mapping is this: it brings teams and their work closer to the user’s needs. It bridges the gap between what we build and why we build it. And that ensures that every developed feature serves a real purpose for the end user.

So, if you want to enhance clarity, focus, and success in your Agile projects, turn to Agile story mapping. This tool can transform the way you approach project planning and execution. This will ensure that the end product is not just a collection of features, but a solution that truly resonates with users.

Maria Vasserman

Maria loves all things creative – writing, photography, movies and beyond 🎥 When she's not creating content to tell the world about Canny, she's either photographing a wedding, jumping at a rock concert, camping, travelling, snowboarding, or walking her dog 🐕‍🦺

All Posts - Website · Twitter - Facebook - LinkedIn

Related Posts

Last Updated on April 19, 2024

Customer Journey Map

A Customer Journey Map captures the user’s experiences as they interact with a company’s operational value stream, products, and services.

Privacy Overview

Engineering

Home > Blog > Journey Mapping to User Story Mapping

Modern Agile ways of working emphasize the benefits of bringing together business representation (Product owners) with development teams. This means everyone is focused on a shared understanding of “value”: identifying who the product is for, what the user is trying to achieve, and how this benefits the business/organization.

Just as Agile practitioners have matured, business and product practitioners have also evolved, acknowledging the need to observe, to understand, to hypothesize, and to get feedback from customers. Design professionals realize the important truth: we are not our users. User experience professionals are using design thinking methods to glean insights into how to make users awesome! And yet, there is a natural tension between upfront understanding and getting real feedback.

How does a team balance discovery and delivery?

Let’s take an example:

• Imagine an organization who is the leader in the industry but is struggling to modernize in both its design and delivery practice.
• Their product group is trying to evolve from sales-driven, taking a variety of orders, to product-driven, offering innovative solutions that delight customers: not a “faster horse” but a motor car. This organization needs to make discoveries for customers.
• Their technology group needs to embrace technology as a legitimate channel that services customers, not just a platform that supports operations. And how to implement this shift with limited resources: a small technology team surviving on a monolithic architecture. This organization also needs to deliver .

This organization needs both to drive sales through discovery and to easily, gracefully meet the needs of users through delivery. Day-to-day it’s common that product owners have a hard time negotiating with hundreds (almost thousands) of customers. And day-to-day it’s hard for technology professionals to deliver confidently with infinite scenarios.

What would it take to work as one product team focused on wrangling many customers and customizations?

Bridging Design Thinking and Agile Delivery can help solve the challenges for organizations like the one we imagined above, using two techniques: Journey Mapping and User Story Mapping, each of which I’ll highlight more in future posts.

Journey Mapping is a common Design Thinking and User Experience technique that helps product teams understand real and ideal users (through the construction of “personas”).

User Story Mapping is a common Agile Delivery technique by Jeff Patton that drives the big picture view for delivery teams while enabling milestone planning. From User Story Mapping, delivery teams can understand the scope of the product and therefore, plan healthier and safer technology solutions (like domain-driven and service-oriented architectural patterns, or implementing object-oriented patterns day-to-day in code).

Conjointly, Journey Mapping and Story Mapping can help product teams realize user value through the enablement of fast, responsive delivery. Yet, many agile teams struggle to incorporate design thinking into their agile delivery.

How can we integrate Journey Mapping and User Story Mapping in order to bridge Discovery to Delivery?

• Persona or User picture: visualize who this product is for and their point-of-view experience
• Persona or User goals: identify why the actor is trying to achieve, i.e. needs, expectations
• Persona or User scenario: identify what situation the map addresses associated with the actor goals
• Backbone or Journey Phases: these are big activities or high-level stages of actor steps
• Narrative, Activities, or Actions: the behaviors and steps taken by the actor within the phase
• Emotional experience: the “ups” and downs” as the user moves towards their goal
• Thoughts: what the persona or user is thinking during specific steps, helping to provide context to drive empathy
• Details or Tasks: options for the step within the narrative
• Increment: craft viable releases based on target outcomes
• Prioritize: focus on overarching outcomes and what users need to do and see to achieve those outcomes

A future agile approach brings together not just product owners and development teams but also user experience techniques to validate user feedback into delivery as quickly as possible. You can look forward to my future posts on “Bridging Agile Delivery and Design Thinking” where I’ll talk more about how more of these techniques come together.

For further reading:

• Sierra, Kathy. Badass: Making Users Awesome . 2015.
• Royce, Winston. “Managing the Development of Large Software Systems.” August 1970. Managing the Development of Large Software Systems
• Patton, Jeff. User Story Mapping . 2014.
• Gibbons, Sarah. Nielsen Norman Group. “Journey Mapping 101.” December 9, 2018. Journey Mapping 101
• Jeff Patton & Associates. “Dual Track Development.” Dual Track Development

Browse eLearning

Take a Workshop

Read a Blog

Actionable Psychological Safety Workshop

September 9 - October 11

The journey to an agile organization

Agility is catching fire, and there is growing recognition of its transformational benefits. But moving to an agile operating model is tough, especially for established companies. There are several paths to agility and many different starting points, yet successful agile transformations  all share the common elements described in this paper.

Agile organizations are different. Traditional organizations are built around a static, siloed, structural hierarchy, whereas agile organizations are characterized as a network of teams operating in rapid learning and decision-making cycles. Traditional organizations place their governance bodies at their apex, and decision rights flow down the hierarchy; conversely, agile organizations instill a common purpose and use new data to give decision rights to the teams closest to the information. An agile organization can ideally combine velocity and adaptability with stability and efficiency .

Transforming to an agile operating model

Any enterprise-wide agile transformation needs to be both comprehensive and iterative. That is, it should be comprehensive in that it touches strategy, structure, people, process, and technology, and iterative in that not everything can be planned up front (Exhibit 1).

There are many different paths to enterprise agility. Some organizations are born agile—they use an agile operating model from the start. As for others, broadly put, we see three types of journeys to agile: All-in, which entails an organization-wide commitment to go agile and a series of waves of agile transformation; Step-wise, which involves a systematic and more discreet approach; and Emergent, which represents essentially a bottom-up approach.

Born-agile organizations are relatively common in the technology sector (for instance, Spotify or Riot Games 1 Stephen Denning, The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done , New York: AMACOM, 2018. ), with rare examples in other industries (Hilcorp, a North American oil and gas company, is a case in point ). Most organizations must undergo a transformation to embrace enterprise agility. Such transformations vary in pace, scope, and approach, but all contain a set of common elements across two broad stages (Exhibit 2).

First, successful transformations start with an effort to aspire, design, and pilot the new agile operating model. These elements can occur in any order and often happen in parallel. Second, the impetus to scale and improve involves increasing the number of agile cells. However, this involves much more than simply rolling out more pilots. Organizations may iterate among these stages as they roll out agility across more and more of their component parts.

Aspire, design, and pilot

Most transformations start with building the top team’s understanding and aspirations, creating a blueprint to identify how agility will add value, and learning through agile pilots. These three elements inform one another and often overlap.

Top-team aspiration

Successful agile transformations need strong and aligned leadership from the top . A compelling, commonly understood and jointly owned aspiration is critical for success.

The blueprint should, at first, be a minimum viable product developed in a fast-paced, iterative manner that gives enough direction for the organization to start testing the design.

Adopting an agile operating model can alleviate challenges in the current organization (such as unclear accountabilities, problematic interfaces, or slow decision making). Yet a desire to address pain points is not enough; there is a bigger prize. As one CEO observed, “I’d never have launched this agile transformation if I only wanted to remove pain points; we’re doing this because we need to fundamentally transform the company to compete in the future.” This aligns with McKinsey research showing that transformations emphasising both strengths and challenges are three times more likely to succeed.

To build the top team’s understanding and aspiration, nothing beats site visits to companies that have undergone an agile transformation. For example, the entire leadership team at a global telecommunications company contemplating an agile transformation invested a week to visit ING (a Dutch bank), TDC (a Danish telecommunications company), Spotify, Entel (a Chilean communications company), and others prior to launching an agile transformation. 2 Bo Krag Esbensen, Klemens Hjartar, David Pralong, and Olli Salo, “ A tale of two agile paths: How a pair of operators set up their organizational transformations ,” February 2019.

The blueprint for an agile operating model is much more than an organization chart and must provide a clear vision and design of how a new operating model might work (Exhibit 3). An agile transformation fundamentally changes the way work is done and, therefore, blueprinting also needs to identify changes to the people, processes, and technology elements of the operating model. The blueprint should, at first, be a minimum viable product developed in a fast-paced, iterative manner that gives enough direction for the organization to start testing the design.

The first step in blueprinting is to get clear on where the value lies. All operating-model design must be grounded in an understanding of how value is created in the industry and how the individual organization creates value. This fundamentally links to strategy.

Next comes structure. An agile organization doesn’t deliver work according to a classic organization chart; rather, it can be thought of as a series of cells (or “teams,” “squads,” or “pools”) grouped around common missions, often called “tribes.” The blueprinting element should produce a “tribe map” to illustrate how individuals that are grouped get work done, as well as a more recognizable organization chart to show the capability axis along which common skill sets are owned and managed (Exhibit 4).

Individual agile cells are defined by outcomes or missions rather than by input actions or capabilities. Teams performing different types of missions will likely use different agile models. However, three types of agile cells are most common. First, cross-functional teams deliver products, projects, or activities. These have the knowledge and skills within the team and should have a mission representing end-to-end delivery of the associated value stream. The “squads and tribes” model developed by Spotify and used by ING , among others, is one example. Second, self-managing teams deliver baseload activity and are relatively stable over time. These teams define the best way to set goals, prioritize activities, and focus effort. Lean-manufacturing teams or maintenance crews could be examples of this agile approach. Indeed, more broadly, lean-management tools and practices are highly complementary with enterprise agility. Third, flow-to-work pools of individuals are staffed full time to different tasks based on the priority of the need. Functional teams like HR or scarce resources like enterprise architects are often seen as “flow” resources.

One telecommunications company identified five major activities across their business and selected an agile approach for each: channel and delivery units (for example, stores) were organized as self-managing teams to increase local flexibility with joint accountability; segment ownership, product development, and enabling teams were organized in cross-functional squads and tribes; and centers of excellence for all other activities (including subject-matter experts and corporate support activities) combined flow-to-work and temporary cross-functional teams for specific tasks.

Would you like to learn more about our People & Organizational Performance Practice ?

Working in teams may sound familiar, but at scale this requires change across the whole operating model to provide appropriate governance and coordination. The organizational backbone comprises the stable components of an agile operating model that are essential to enable agile teams. Typically, these backbone elements include core processes (for example, talent management, budgeting, planning, performance management, and risk), people elements (including a North Star , 3 To give coherence and focus to their distributed value creation models, agile organizations set a shared purpose and vision—“the North Star”—for the organization that helps people feel personally and emotionally invested. core values, and expected leadership behaviors), and technology components. In trying to scale up, many agile transformations fail by simply launching more agile teams without addressing these backbone elements.

The final step of blueprinting is to outline the implementation road map. This road map should contain, at minimum, a view on the overall scope and pace of the transformation, and the list (or “backlog”) of tasks.

The five steps of the blueprint form a coherent approach. A commercial insurer in North America used an agile blueprint to accelerate innovation of digital and business processes. It defined a chapter-based organization structure and created a new organization of product managers (who played product-owner roles in agile teams) to guide teams toward business outcomes. They defined a team structure mostly aligned to customer and internal user journeys, with dedicated teams to grow selected businesses. They created a stable planning and performance-management backbone, as well as a culture of risk taking, and they used an 18-month road map to create all the new positions, train personnel in the new roles, and implement the change in full.

Nothing convinces skeptical executives like teams of their own employees having verifiable impact through agile working. For example, one oil and gas company launched a series of agile pilots through which cross-functional teams managed to design wells in 50 to 75 percent less time than the historical average.

Agile pilots

The purpose of a pilot is to demonstrate the value of agile ways of working through tangible business outcomes. Early experiments may be limited to individual teams, but most pilots involve multiple teams to test the broader elements of enterprise agility. Nothing convinces skeptical executives like teams of their own employees having verifiable impact through agile working. For example, one oil and gas company launched a series of agile pilots through which cross-functional teams managed to design wells in 50 to 75 percent less time than the historical average.

Initially, the scope of the agile pilot must be defined and the team set up with a practical end in view; this might include deciding on team staffing, structure, workspace, facilities, and resources. Next, the way the agile pilot will run must be outlined with respect to structure, process, and people; this is typically collated in a playbook that forms the basis for communications with those in the pilot.

Scale and improve

Agile transformations acknowledge that not everything can be known and planned for, and that the best way to implement is to adjust as you go.

Scaling beyond a few pilots is no small feat; this is where most agile transformations fail. It requires recognition from leadership that scale-up will require an iterative mind-set: learning is rapidly incorporated in the scale-up plan. In this, enough time is required—a significant portion of key leaders’ time—as well as willingness to role model new mind-sets and behaviors. Agile transformations acknowledge that not everything can be known and planned for, and that the best way to implement is to adjust as you go. For example, a leading European bank first deployed four “frontrunner” tribes to test the blueprint in action and adapted important elements of the blueprint across the delivery enterprise. Such an iterative rollout approach enables continuous refinement based on constant feedback and capability building for key roles across the organization, including agile coaches, product owners, scrum masters, and leadership.

Agile cell deployment and support

Agile scale-up first and foremost requires standing up more agile cells. However, an organization can’t pilot its way to enterprise agility. The transformation should match the organizational cadence, context, and aspiration. But at some point, it is necessary to leap toward the new agile operating model, ways of working, and culture. For large organizations, this need not be a day one for the entirety but will likely progress through a series of waves.

Many chose to start by transforming their headquarters and product-development organizations before touching frontline, customer-facing units (call centers, stores, or manufacturing facilities). It is possible to transform one factory or one end-to-end customer journey at a time, but highly interconnected functions in the headquarters may need an All-in transition approach.

The size and scope of waves depend on the context and aspiration. For example, a large Eastern European bank designed waves of nine months, where the diagnostic, design, and selection for 10 tribes, 150 squads, and 1,500 roles were performed in the first three months and then deployed over a six-month period, launching a new tribe every two weeks. Furthermore, the scale-up effort was a top priority for C-suite executives, which dedicated more than 10 percent of their time to the transformation.

Resources to support new agile cells—for example, availability of agile coaches or appropriate workspace—can often limit the speed of scale-up. Failure to address the support of new agile cells can cause friction and delay in the transformation.

Backbone transformation

Reflecting on its agile experience before scaling up, one executive observed: “Most of our agile pilots are working despite, rather than supported by, our broader organizational ‘wiring’ [processes, systems, and even beliefs and values] that forms what we call the backbone of an organization.” The backbone governs how decisions get made; how people, budgets, and capital get deployed; and how risk gets managed. Taking an organization to an agile operating model requires that this backbone be transformed (Exhibit 5).

Capability accelerator

Successfully scaling an agile operating model requires new skills, behaviors, and mind-sets across the organization. This is vitally important and constitutes an intensive phase of an agile transformation. Most organizations require existing staff to take on these new roles or responsibilities, and as such, need a way to build new skills and capabilities. Specifically, any successful agile transformation will invariably create a capability accelerator to retrain and reorganize staff, make the agile idea common to all, and develop the right skills across the organization.

Agile Organizations

A typical capability journey may well have distinct phases. First, organizations need to identify the number of trainers (agile coaches) required, and then hire and develop them; a failure to do so can cause delay and blockage when the agile transformation extends across the whole organization. Second, as part of building capabilities, the organization must define the new agile roles (agile coaches, product owners, tribe leads, chapter leads, and product owners, for example), along with a clear idea of what success looks like in each role. Third, learning and career paths should be set for all staff, making clear the opportunities that the agile transformation opens up. Fourth, the organization needs to enable continuous learning and improvement across the organization (this will entail a large-scale digital and communications program). Finally, it’s necessary to design and run a whole-organization effort to raise agile skills (often by means of intensive boot camps) and ensure that new staff are onboarded appropriately. Larger organizations often set up an academy to consolidate and formalize these functions.

The importance of investing in culture and change on the journey to agility cannot be overstated. Agile is, above all, a mind-set. Without the right mind-set, all other parts of the agile operating system can be in place, and yet companies will see few benefits.

Focusing on culture and the change team

A culture and change team is an essential coordinating element of an agile transformation. But it is not a traditional project-management office; rather, the emphasis should be on enabling the other transformation elements, helping to remove impediments and catalyzing culture change.

As an example, Roche, a global healthcare company, launched a global leadership initiative as a central component of its transformation to become a more agile enterprise . It designed a four-day program with a combined focus on personal and organizational transformation. More than 4,000 leaders have now been touched by the effort, helping to shift the collective consciousness and capabilities for leaders to deliver the change.

The importance of investing in culture and change on the journey to agility cannot be overstated. Agile is, above all, a mind-set. Without the right mind-set, all other parts of the agile operating system can be in place, and yet companies will see few benefits. In contrast, when leaders and teams have a strong agile mind-set, then a clear aspiration alone is often enough for a successful agile operating model to emerge.

Understanding transformation archetypes

All successful enterprise-wide agile transformations include the elements described above, but there are several different ways in which the elements can be combined and sequenced. As introduced earlier, there are three major transformation archetypes:

• Step-wise. Transforming to an agile organization often feels like a step into the dark for senior leaders. Perhaps understandably, then, the most common transformation archetype shows a clear distinction between the aspire, design, and pilot phase and the scale and improve phase. Many companies will run multiple rounds of pilots and iterate their blueprint several times before fully committing to scaling up across a large part of the organization. It is not uncommon for this process to take one to two years, as leaders and the organization build familiarity with agility and prove to themselves that agile ways of working can bring value in their organization. Organizations may well go through several subsequent rounds of aspire, design, and pilot before scaling up elsewhere.
• All-in. Although less common, an increasing number of organizations gain strong conviction early on and fully commit up front to move the whole organization to an agile model. Leaders from these organizations define a plan to execute all steps of the transformation approach as quickly as possible. Even in these types of transformation it is rare for the whole organization to transform to an agile model in a single “big bang”; rather, it is more common for the transformation to proceed through a number of planned waves.
• Emergent. It is impossible—and not very agile—to plan out an agile transformation in detail from the start. Instead, most agile transformations have emergent elements. Some organizations have chosen to progress their entire agile transformation through an emergent, bottom-up approach. In this archetype, an aspiration from top leaders sets a clear direction, and significant effort is spent building agile mind-sets and capabilities among leaders.

“It’s like this,” one CEO explained. “We are 3,000 people on a giant cruise ship. But what we need to be is 3,000 people in a few hundred yachts. So, how do I get my people safely into those smaller boats?” As is increasingly common, the discussion had moved from if an agile operating model was applicable to how leaders could help their organization transform. Navigating an organization to an agile operating model is not easy. The elements of an agile transformation described in this article provide a guide.

Stay current on your favorite topics

Daniel Brosseau is a partner in McKinsey’s Montreal office, Sherina Ebrahim is a senior partner in the New Jersey office, and Christopher Handscomb is a partner in the London office, where Shail Thaker is a senior partner.

Explore a career with us

Related articles.

What it takes to go agile

The five trademarks of agile organizations

Five Fifty: Agility at the top

More From Forbes

How marketing teams can move beyond traditional attribution models.

• Share to Facebook
• Share to Twitter
• Share to Linkedin

Jeff Pedowitz, President and CEO, The Pedowitz Group . Best-Selling Author.

The buying journey has turned into a complex maze, challenging the old playbook used by traditional marketing models.

As customers zigzag in unpredictable ways, chief marketing officers (CMOs) find themselves at a crossroads, struggling with outdated tactics. The pressure is on from sales teams, CEOs and boards demanding accountability while the quest for precise attribution remains a slippery goal.

Faced with this challenge, CMOs are being pushed toward creative solutions to untangle and harness customer interactions, all in the pursuit of concrete outcomes.

1. The Evolution Of Purchase Journeys

Traditional attribution models, like single-touch and multi-touch, have been used for years to measure marketing effectiveness. Single-touch models credit one point in the customer journey, while multi-touch models spread credit across multiple touchpoints.

These models, however, have limitations. They often oversimplify the customer's path to conversion, failing to capture the complexity of real-world interactions. More sophisticated attribution approaches are needed as customer journeys involve multiple channels and stages.

Best High-Yield Savings Accounts Of 2024

Best 5% interest savings accounts of 2024.

In my 20 years of experience with over 1,500 B2B engagements, I've observed the challenges of understanding modern customer journeys, exacerbated by fragmented data and siloed systems. Clients often struggle with data spread across various platforms, hindering a unified customer journey view.

This fragmentation leads to inaccurate marketing success attribution and misallocation of resources. Addressing data silos and integrating data sources is critical for improving attribution accuracy and making informed marketing decisions.

2. Other Challenges With Marketing Attribution Models

Beyond siloes and fragmentation, marketing teams face a few other challenges with traditional attribution models, such as:

Data Accuracy

Gathering precise data from diverse sources is difficult due to the complexity and variability of data. For instance, discrepancies arise when platforms like Facebook and Shopify track conversions differently, leading to inconsistent traffic numbers from analytics tools.

These inconsistencies are problematic for interpreting customer behavior and campaign performance accurately.

Overemphasis On Short-Term Metrics

Digital marketing's focus on last-touch attribution often overlooks the full customer journey. For example, focusing on last-click data alone misses the impact of strategies like email series that nurture leads over time, which are crucial for understanding conversions.

Channel Overlap

Channel overlap can influence campaign outcomes in unexpected ways. For example, a social media campaign may appear to be underperforming on its own while driving significant search traffic and conversions as users seek more information, highlighting the interconnectedness of channels.

Attribution Windows

Using longer attribution windows has uncovered valuable insights missed by shorter ones. A campaign that showed modest results within a 30-day window may reveal a significant increase in brand searches and conversions over the following months, emphasizing the need to consider the long-term impact of marketing efforts.

3. Technology Challenges

CRM systems often fail to manage B2B's long sales cycles and multiple decision-makers, leading to gaps in tracking complex buying processes. Typically, only the initial contact's details are recorded, skewing the real impact of campaigns on sales success.

Meanwhile, marketing automation platforms focus on individual marketing, missing the broader engagement with multiple contacts at a company, which limits visibility into the entire buying group's journey.

To address these challenges, B2B marketing should shift from focusing on marketing qualified leads (MQLs) to marketing qualified accounts (MQAs), advocating for an integrated approach across channels to engage and nurture potential accounts more effectively throughout their buying cycle.

This shift toward true omnichannel orchestration is crucial but remains a hurdle for many existing systems.

4. Shifting Focus: Alternative Approaches

Journey-based marketing uses customer journey mapping to understand customer behavior and tailor marketing strategies. I have seen how implementing targeted email campaigns based on purchase history and browsing behavior can increase repeat purchases.

With this process, holistic KPIs—such as customer lifetime value, engagement scores and loyalty metrics—are crucial for gauging marketing's broader impact, influencing long-term loyalty and upselling opportunities for smarter budget allocation.

One strategy to consider, in particular, is marketing mix modeling , which evaluates marketing efforts' impact on performance. Reallocating budget based on insights from this method has boosted our client's marketing efficiency immensely.

Likewise, experimentation and incrementality testing, through A/B testing, provide concrete data on marketing strategies' effectiveness. Our A/B testing for social media ads has resulted in large increases in both engagement and rise in conversion rates.

Focusing on overall pipeline and revenue growth for both existing accounts and new clients—while integrating these approaches— can optimize marketing strategies and contribute to significant top-line growth and customer expansion. This holistic, data-driven marketing approach has been key to achieving growth targets.

5. Optimizing Budget Allocation Without Attribution

Another technique to keep in mind is strategic allocation, which focuses on journey mapping and experimentation for smarter budgeting. The goal is to focus on impactful customer journey points to optimize resource allocation.

One important strategy is Agile Budgeting , which can allow teams to adjust budgets based on campaign performance and immediate needs, enabling ongoing optimization of marketing spend.

6. Building Organizational Alignment

Cross-functional collaboration is, likewise, vital to understanding the customer's purchase journey. Marketing, sales and product teams must unite to gain diverse insights and a comprehensive view of customer decision drivers.

It's important to ensure this collaboration adopts a customer-centric point of view, where customer needs lead business strategies, as this is the best way to enhance satisfaction and loyalty.

The changing consumer behavior landscape demands rethinking traditional attribution models. The complexity of modern purchase paths, with their varied touchpoints, calls for a new approach to grasp the intricacies of consumer actions.

Marketing leaders, particularly CMOs, must embrace journey mapping, holistic KPIs and a culture of experimentation to navigate this complexity. This shift towards embracing insights through analytics and testing ensures deeper insights into consumer behavior.

The rise of AI and machine learning offers tools for a deeper analysis of marketing impacts on the consumer journey, promising enhanced resource allocation and strategy. Embracing these technologies is essential for future-proofing marketing efforts and enabling more precise, data-driven decisions.

Forbes Business Council is the foremost growth and networking organization for business owners and leaders. Do I qualify?

• Editorial Standards
• Reprints & Permissions

What would you like to do?

Category Select one Administrative Business Development Clinical Clinical Development College Job Compliance Corporate Services Engineering Finance Government Affairs Health Economics Human Resources Information Systems Law/Legal Maintenance Manufacturing Marketing Medical Affairs Medical Services Operations Postdoctoral Process Development Procurement Project Management Public Relations Quality Regulatory Research Safety Sales Sales & Marketing Operations Scientific Strategy and Innovation Supply Chain Training Value and Access

Job Type Select one Full time Part time

Where would you like to work?

City Select one Aberdeen Albuquerque Anchorage Annapolis Atlanta Austin Bakersfield Baltimore Bangkok Bartlesville Beijing Berkeley Billings Birmingham Bogotá Boise Boston Breda Bridgeport Brisbane Bristol Bucharest Buenos Aires Burlington Burnaby Cairo Cambridge Cambridge Charleston Charlotte Cheyenne Chicago Chico Cleveland Columbia Columbus Copenhagen Dallas Danville Daqing Denver Des Moines Detroit Diegem Dublin Duluth Dún Laoghaire Edinburgh Erie Fargo Folsom Fort Myers Fort Wayne Fort Worth Fresno Greater Manchester Guangzhou Harbin Hartford Hefei Holly Springs Hong Kong Honolulu Houston Huntington Indianapolis Irvine Istanbul Jackson Jacksonville Jiaxing Juncos Kansas City Kuala Lumpur Ladrido Lafayette Lanzhou Las Vegas Lisbon Little Rock London Long Beach Los Angeles Louisville Madison Madrid Manchester Memphis Mexico City Miami Milan Milwaukee Minneapolis-St. Paul-Bloomington Mississauga Modesto Montreal Munich Nantong Napa Naperville New Albany New Albany New Brunswick New Orleans New York Newark Oakland Ocala Oklahoma City Omaha Orlando Paris Parkersburg Peoria Philadelphia Phoenix Pittsburgh Plano Portland Portland Poznan Prague Providence Raleigh Rapid City Redding Remote Riyadh Rochester Rockville Sacramento Saint Paul Salt Lake City San Antonio San Diego San Francisco San Jose Santa Barbara Santa Rosa São Paulo Seattle Seoul Sevilla La Nueva Shanghai Singapore Sioux Falls Søborg Sofia South San Francisco Springfield St Louis Stockton Sydney Tacoma Taichung Taipei Taiyuan Tampa Thousand Oaks Tokyo Toronto Tucson Tulsa Ürümqi Uxbridge Uxbridge Vienna Vilnius Virginia Beach Waco Warsaw Washington D.C. Waterford West Greenwich Wichita Wilmington Wuhan Yangzhou Zagreb

Country Select one Argentina Australia Austria Belgium Brazil Bulgaria Canada China Colombia Croatia Czechia Denmark Egypt Estonia Finland France Germany Hong Kong SAR Ireland Italy Japan Lithuania Malaysia Mexico Netherlands Poland Portugal Puerto Rico Romania Saudi Arabia Singapore South Korea Spain Taiwan Thailand Türkiye United Arab Emirates United Kingdom United States

State Select one Alabama Alaska Anhui Arizona Arkansas Bangkok Bavaria Beijing Municipality Bogota D.C. British Columbia București Buenos Aires F.D. Cairo Governorate California Capital Region Central and Western District City of Zagreb Colorado Connecticut Delaware District of Columbia Dubai England Flanders Florida Galicia Gansu Georgia Greater Poland Guangdong Hawaii Heilongjiang Hlavní město Praha Hubei Idaho Île-de-France Region Illinois Indiana Iowa Istanbul Jiangsu Juncos Kansas Kentucky Kuala Lumpur Leinster Lisbon District Lombardy Louisiana Madrid Maine Maryland Massachusetts Mazovia Mexico City Michigan Minnesota Mississippi Missouri Montana Munster Nebraska Nevada New Hampshire New Jersey New Mexico New South Wales New York North Brabant North Carolina North Dakota Ohio Oklahoma Ontario Oregon Pennsylvania Quebec Queensland Rhode Island Riyadh Region São Paulo Scotland Seoul Shanghai Municipality Shanxi Singapore Sofia-grad South Carolina South Dakota Taiwan Tennessee Texas Tokyo Utah Vermont Vienna Vilnius Virginia Washington West Virginia Wisconsin Wyoming Xinjiang Uyghur Autonomous Region Zhejiang

Digital Transformation Intern: Service Design and Process Mapping

RADIUS Select Miles 5 miles 15 miles 25 miles 35 miles 50 miles

Do more with the knowledge you’re working hard to acquire and the passion you already have. At Amgen, our shared mission—to serve patients—drives all that we do. It is key to becoming one of the world’s leading biotechnology companies, reaching over 10 million patients worldwide. Through this internship opportunity, you will acquire valuable hands-on skills and foundational experience to become the professional you are meant to be in your chosen field.

At Amgen Breda, medicines are labeled, assembled, stored, and eventually shipped to various countries worldwide. Every day more than 1000 people from 38 different nationalities are working on supply chain processes, manufacturing, marketing, and sales of our medicines and clinical research into new medicines.

This could be your everyday.

Amgen’s CPO Digital & Data Strategy department drives digital transformation for Combination Products Operations and the larger Product & Process development organization. As an intern, you’ll study, document, and visualize the Digital team’s service model. This model supports internal business customers by understanding their needs, defining lean business cases, and developing product backlogs. You’ll contribute to building, testing, and rolling out digital capabilities under the scaled agile framework (SAFe).

Responsibilities:

• Study the digital transformation process within a Fortune 500 company.
• Assist the Sr Product Manager and product owners of the Next-gen Product Lifecycle Management (NG-PLM) platform.
• Develop a standardized service design and model for engaging with internal customers during digital transformation initiatives.

Deliverables:

• Document an end-to-end customer engagement model for the CPO digital and data strategy team.
• Present the process to internal stakeholders and upper management for feedback.

What we expect of you

We are looking for students with passion and who are thrilled to help in our mission “to serve patients”.

To be successful as an intern you need the following:

• Be a pre-final or a final year student, with Master’s studies in Service Design, Industrial Design, Product design, or Design for Interaction (UX/UI)
• Have proficiency in English (both verbal and written. Dutch is a plus).
• User-centered design using qualitative research.
• Co-creation with relevant stakeholders.
• Sequencing complex service processes into user journey sections.
• Envisioning tangible service experiences.
• Holistic design for all touchpoints across user interactions.

What we offer

As we develop treatments that take care of others, we work to care for our teammates’ professional and personal growth and well-being. Therefore, Amgen is recognized as the World's Best Workplace 2021 ©.

• Full support and career-development resources to expand your skills, enhance your expertise, and maximize your potential along your career journey.
• Diverse and inclusive community of belonging, where teammates are empowered to bring ideas to the table and act.
• The opportunity to work within a dynamic and international organization, a monthly internship fee, and able to be part of the Amgen internship program with a New Hire Orientation period, monthly Lunch & Learn sessions, and a Final Poster Session.
• Focus on vitality with an on-site gym, a vitality program, and a restaurant with healthy food.
• Flexible work arrangement with days in the office and working from home.
• The opportunity to apply to temporary or permanent positions within Amgen!

Please take note of the following:

• To be eligible for this internship, you should currently be enrolled at a (Dutch) University.

SHARE THIS JOB

Sign up for job alerts.

Stay up to date on Amgen news and opportunities. Sign up to receive alerts about positions that suit your skills and career interests.

Category* Select one Administrative Business Development Clinical Clinical Development College Job Compliance Corporate Services Engineering Finance Government Affairs Health Economics Human Resources Information Systems Law/Legal Maintenance Manufacturing Marketing Medical Affairs Medical Services Operations Postdoctoral Process Development Procurement Project Management Public Relations Quality Regulatory Research Safety Sales Sales & Marketing Operations Scientific Strategy and Innovation Supply Chain Training Value and Access

• Information Systems, Breda, North Brabant, Netherlands Remove

Confirm Email

By submitting your information, you acknowledge that you have read our privacy policy (this content opens in new window)and consent to receive email communication from.

Related Content

Mission, Vision and Values

Diversity, Inclusion and Belonging

Amgen Stories