Welcome to the user journey — a critical part of getting your Product and your Project right.

What is a User Journey

In its simplest form, a User Journey can describe the process, tools, and steps a User makes to complete a task.  


Better User Journey's do more. They look at how the user feels during the process: irritated, confused, or satisfied. They look at how the 'user' experiences the journey: do they need to adjust a process to make it work for them? Did they find it more difficult than needed?

Understanding how people use the product, service, or outcome your project creates, is the job of your successful project.  

This will be discussed more in a future blog focused on the User Journey. But for now, I want to share why I think User Journeys make Projects themselves better.

Why User Journeys make your project better?

What is key to a Project? A good team, a clear goal, engaged stakeholders? Maybe the right tools and processes? Yes, to all of the above. But equally important is a project's ability to learn and take corrective action to its way-of-working. 

Types of User Journey work for Project Teams includes:  

1. Empathy training of the project team to understand what it was like to be a country on the receiving end of the implementation, and

2. Integration training between the project teams to ensure we understood how the processes worked and that everyone could give input to any area that might be sub-optimum.

3. Interactive discussions with the countries with implementations planned for the coming year (hosted by a country manager who had been involved in the prior year to ensure specific needs or requirements were understood in advance.

This training included a day set aside for mock experience based run through from beginning to end. We, the management, would “inject” a problem half way through the day to see how people and processes managed the issue. During these days of training, we created and refined the User Journeys. Journeys that documented how the global and the local country teams would work through the implementation.  

In watching a program about the project failure in the design and training for the Virgin Galactica SpaceShipTwo. I learned a few things:

1. The feather wing design is an amazing breakthrough - -real genius at work.

2. The failure was in large part due to pilot error. However, it was clear that minimal training was given about the impact of certain procedures.

3. The designers of the cockpit controls never considered that pilots might make a procedural error.

4. The investigation team and TV program did not reveal if the Galactica engineering team had a process for checking their own internal user experience for design.

5. Interestingly, while Virgin Atlantic has a highly developed User Experience for their passenger experience, I could not find a similar User Experience Journey for their Space program. (Granted, it may have been classified).

I am hopeful that one of the lessons learned was the User Journeys and User Experience is not just for the outcome of projects. But for Project input, operations, and usability testing as well.

How to use a journey for your project?

On another blog, we have discussed Belbin Roles, and the next blog will be focused on User Journeys in detail.  

For this discussion, I create an example. 

This Project has already had a team kick-off where the team discussed:

• The Project goal and product

• The key stakeholders and users of the final product

• The Project Timeline

• The Project Team Roles

• The high-level project Plan including phases

• The Project project approached to be used

• the related internal project processes for documentation and sign-off

The project team has also worked through each team member's preferred behavioral way of working and aligned to ensure good communication and effective management of tasks.

Next, the step might be to create a walkthrough storyboard. Of how the team will move through each phase within each subteam to build the end product. How they will keep the functional and technical specifications in mind. And how, through user interaction, they will gain an optimum understanding of the use case. 

This may be a complex diagram, but it may be worth building and doing a walkthrough to check that all aspects of success have been considered. The team and user diversity should be leveraged to consider all of the key aspects of the project.  

Of course, the plan should account for the time and effort to create this document. Done well, it should not be more than a great test of the project planning phase of work. It also is the ultimate ice breaker to set the scene for the team's work ahead.  

Did I convince you that projects need User Journeys? Do you have a User Journey story to share? Please let me know in the comments below!