I created this document based on my learnings from the process I used at CloudBees. I've used it and sent it to others for inspiration since then.

"Long term" depends on the release cycle at your company or the type of industry you're in. I work in rapid-release SaaS companies with a lot of access to users or customers, which means the user journeys become irrelevant more quickly. For other companies, they don't need to change as often.

It also really depends on how "high level" you make them. Some companies choose to make very vague user journeys as an easy way to align everyone across the business, but I would warn against doing that. If you make a very high-level path of a user journey, then very little needs to change after producing them. But if you want these to drive actual change, they really should be revisited and updated every 6 months. If you produce one user journey per team, then it can be easily updated every 4 months without needing to redo the entire process.

This guide is intended for the people executing the work. It's not really geared towards a product or company leader, more around the one who will be driving the execution process and for those who would be IC on it.

Sometimes that looks like the PM who is organising the effort to produce this, or sometimes this can be a researcher. I've also sent this to a designer who was a sort of "UX team of one" at their company who was trying to establish some UX and research practices.

This is absolutely a rinse-and-repeat type of activity. It's an artifact produced from research/data that becomes a snapshot in time. As you get new learnings, it becomes outdated.

Once you've established a repository of research or insights and you've established the connections between different parts of the company, doing this process again to update the user journey becomes very easy. Sales understands what questions we might need answered and can work one into their regular calls; support understands the importance of asking about the reasons behind requests and struggles; etc. Once you establish trust, people understand the value, and you have your info all in one place, it's very easy to update a story.

A lot of people encounter the age-old issue of "How much interviewing is enough?" For me, you're done speaking to people when you've reached 10 interviews OR exhausted all the people you can talk to. If you also have access to Intercom, recorded sales calls, or anything like that, then you have a lot to work with already.

Enough never feels like enough, but it's better to use the signals and information you have now than to sit on your heels and wait. This process works if you want to use more time, but I always bias toward action. I want these user journeys to be easy to edit and evolve as we get more info. They don't need the same level of research as a term paper or a high-cost consultant project.

I think designers, researchers and PMs can and should keep this Excel doc updated constantly. I've never suffered from being able to say, "Hey teammate, what do you think about what is in the doc right now?" It's great for helping the contributing team work together and synthesize their notes faster.

I would not share the Excel doc outside of the contributing team though — that's what the Figma template in the next step is for.

Amber Rucker

I created this six-step guide for PMs, researchers, and designers seeking to drive organizational change through user journeys.

How to create user journeys biased toward action

These user journeys are not exactly the traditional journeys you may have used or seen in the past. I’ve found that many user journey documents are used as reference materials, simply mapping the journey and then hung in the office as an idyllic document for guidance or onboarding materials. However, these particular user journeys are meant to be 

 They serve to align the business, as all journeys do, but are meant to set out a group of focus areas that unite the organization in action towards bettering them. This exercise should be followed up with impact into each team's OKRs, aligning the company in these themes.


These user journeys are also something I use to get an organization aligned around the goal of de-siloing customer and user experience. While each team touches a few points within a user journey, the user doesn’t draw such clean and easy lines as our internal organization and reporting structure does. If there is no owner of the experience as a whole then the company needs to tackle the unified experience cross functionally. This can be a great start for that thinking.


In this exercise you should create a user journey

 for each of your products/product offerings or pricing levels. The journeys within those spaces are going to be different and you should try to reflect that reality. These are meant to be 

 as they place emphasis on the points in a user journey when they may need additional support, may be ready to take on more, are able to upgrade, or are forming new habits, thus giving you specific times/stages to target and support self-serve.


I won’t go into how to create personas in this guide but hopefully through this research you can refine those even further. I will say that starting with personas that are geared towards someone’s goals, how they are measured for success and challenges in their roles tends to help and provide more actionable results. Also, starting with use cases can help with marketing/sales functions or product led teams around what an organization or team might require as well as when might be a good time to drop in motivation for upgrading/upsells/etc.


I believe firmly that all learning is relevant. Many of us have spent much of our career bootstrapped, hoping for greater access to customers or a bit under-resourced; I wanted this guide to be as accessible to as many practitioners as possible. I think, even when we are simply taking what we can get, there is a lot of learning to be had. I have another guide around agile research that can go into signals vs findings and those deliveries, that can help more here. However, In most user journey exercises I leverage internal interviews from across the business, as many customers as we can get, survey results, support tickets, as well as interviews with users of competitors, or people within our target personas and their experiences in similar spaces.


 for interviewing users and “potential users” - reminder that interviewing the leaders of these organizations or the sales POC is only helpful if you are mapping the journey of that exact persona, or the buyer journey. A buyer journey is NOT a user journey and the info they can give you is often assumptions as well.


Recorded sessions are always better. Tone and intent are not something that can be gathered through notes.


I prefer to use a tool like dovetail that creates a repository of info that I can tag with custom tags meant for your org. You can track metadata such as persona, company size, pricing level etc as well as tag certain portions of the interview with stages of the user journey, friction/aha/habit etc. From those tags it’s quite quick to sort them into the next document.

I prefer to put things into this excel document first because it’s 

faster, easier to edit, easier to share in-progress work

 and if you get designers in their tool right away, we will (no blame here) be editing down our points to fit the space vs the other way around. 

I've attached the Excel doc with instructions in each area.

You will notice that there are stages, goals, and actions within each one. Each user journey will look different. You don’t need each stage to be present, within stages there can be 4 goals in 1 or 1 goal in another. There isn’t a formula. The template is meant to fit YOUR product, there is no guideline for how it should look. However, if you note that stages are entirely missing or VERY dense then it’s worth taking note.

For example, I’ve done this once where there was nothing for “advocacy” but 5 for onboarding, meaning onboarding was complex and overly long and we provided no easy ways for users to become advocates within their company or externally.


Write down everything that is relevant from your research but edit for impact. Remember that these journeys are meant to be relevant across the company, inciting action. They shouldn't get so into the weeds that we lose the impact.

Once you have that document ready then we can put it into 

 provided. At this point you will also create the “up and down” aspect of a journey. You’ll start to see the trends in the experience and the synthesis, it will also give you a reminder to edit down.

At this point you need to write the overall findings per each map you've created. What have you noticed? What can be done? Where are the gaps, the stresses etc.


These journeys go NOWHERE if you don't present and drive forward your research. In product research vs academic research, you are encouraged, not expected to provide action and suggestions vs simply giving people unbiased information. You work for a company and that company relies on your and your knowledge to get things done. If you aren't comfortable with that then work with a PM or product leader to write a presentation that is impactful.

This presentation should be across all your journey maps, providing clean “buckets” of actionable or improvement areas as well as areas that the company is excelling in. Offer your help with each business unit to provide more insights or raw data. 

How to Create User Journeys Biased Toward Action from Amber Rucker

How to User Journey

How to create user journeys biased toward action

Sign up to see more