Five ways you might not be making the most of your User Journey Maps

User Journey Maps are an effective means of capturing the needs of a user and ideating on how they will use your product to meet those needs, but are you making the most of them? Here’s five practices that you might be doing that lessen the usefulness of your User Journey Maps.

An example user journey map
Reciprocal.dev

Chucking them in the bin after use

User Journey Maps capture a lot of information about the pain points and problems your product is looking to solve but they’re often binned after that information has been distilled into user stories, usually in an issue tracking system without links to the original map.

This removes part of the context from the user stories and if those stories have been incorrectly written up then you no longer have the source document to understand the original intent behind the story.

By keeping your User Journey Maps available to the team this context is available not only for ensuring your user stories are correct but also for helping the team better understand those user stories as they have a document to reference that contains the problems and pain points identified in the original exercise.

Not sharing them with the whole team

User Journey Maps hold a lot of context about the problem being solved and delivery teams can use this context to better build a greater understanding of the work items they interact with in their day to day.

Often though it’s only those in the product or design space that get to see the User Journey Map and team members outside those teams can find themselves unsure of the intent behind the work items they have to work with.

By sharing the User Journey Map with the whole team those in the engineering and support space can use the contextual information captured in the map to ask more probing questions and better align the implementation to the intent captured in the user stories created from the map.

Not capturing snapshots at key points in your User Journey Map’s evolution

As more data about your user’s needs is collected during the User Journey Mapping process the map will evolve and you start to lose some of the original information that may help add context for features in later versions of the User Journey Map.

By taking a snapshot of the User Journey Map at key points that shape the growth of the User Journey Map you can make these older versions available for the team to revisit if they need to understand the original user need at a later point in the process.

If you continue updating the User Journey Map during the delivery and operational stages of the features that are built as a result of the User Journey Map then you can capture data on how the user need evolves after those features are made available to solve their original problem.

Being able to trace a feature’s evolution from the initial pain point to delivered feature and the new pain points that’s created allows you to better understand your product and your user’s needs.

Not bringing technical data into your User Journey Map

If you’re working with an exising product you will have a lot of useful technical data locked up in your delivery and operation team’s backlogs that can help you better understand your user’s problems and the constraints of the system that will impact the solution to those problems.

This technical data can be added to items on the User Journey Map to build up a ‘quality view’ of your product and help you identify risks that may impact a solution that could result in the delivered feature providing less value than envisioned.

Technical Debt

Technical debt accumulates in areas of the product that are complex to work on. This could mean that the delivery team take longer to make changes in these areas or it may mean that the team doesn’t know much about how that part of the product works, which means they cannot accurately say how feasible a proposed solution would be.

Technical debt is often ‘paid off’ by refactoring the complex areas so they’re easier to work with or where the team is uncertain of how an area of the product works they may carry out a timeboxed investigation (often called ‘Spike’s) to understand that area better.

It’s better to carry out the Spike investigations during the discovery stage as there will often be other technical debt created off the back of them and the knowledge gained from the spike can help understand the feasibility of a solution during the ideation process.

Defects

Defects (or bugs as they’re often called) are areas of the product where it does not work as intended, either due to the implementation being wrong because the team building it misunderstood how the product was meant to work, or because of an external factor such as infrastructure or 3rd party services having a negative impact.

Defects will often have a set of instructions on how to reproduce the conditions needed for the issue to happen, notes on any potential work-arounds to avoid the issue and a severity rating that allows you to understand the impact the defect has on the user.

During the discovery phase this information can help you better understand how your solution may be impacted by a defective implementation or external factors, allowing you to better understand the risks of making changes, which could range from extra time taken to fix existing defects during delivery to a solution not being feasible, due to technical constraints of a system out of the team’s control.

Test Coverage

Testing helps to prevent defects by verifying that the product behaves as intended when it’s used in a particular way and a common way to understand how much of a product’s features are tested is via the test coverage metric.

It’s important to not confuse the test coverage metric with a similar metric called code coverage as the former captures the percentage of the product’s functionality covered by one or more tests, whereas the latter captures the percentage of the code written to implement a product’s functionality by one or more tests.

The reason that test coverage instead of code coverage is more relevant to User Journey Mapping is that it captures testing of the entire product, including those outside of any software related operations the user may need to carry out.

Plotting test coverage data against your User Journey Map allows you to highlight areas of your product that have a low level of testing and this highlights risky areas to make change as it will be harder to verify that those areas haven’t been negatively impacted by the proposed changes made to implement a solution.

Operational metrics

Operation teams will often work with the delivery team during the development of a product to implement tools to help them monitor operational metrics, such as the performance of the product after it’s been released in order to spot potential issues before they happen and mitigate them.

Similar to how defects can be useful during discovery to better understand how the current version of the product works, these operational metrics can help understand the constraints of the current system and the risks these pose to your proposed solution.

By plotting the operational metrics against your User Journey Map you can see where the proposed solution may be increasing throughput through areas of the product that historically have struggled with an increased load and can work with technical architects during the discovery phase to understand the impact to the system increasing that the load may have.

Focusing too much on a smaller scope

Narrowing the scope of what you need to deal with makes it easier to make decisions but it’s easy to lose sight of the impact small changes have on the greater product when you work with a User Journey Map that is too focused on a small scope.

Visualising the entire system for the product and being able to hone in on the smaller scoped map allows teams to remain focused on the discussions the User Journey Map creates while being able to see where the changes fit into the greater product.

By switching between the micro and macro views you can hold insightful conversations by discussing the pain points, problems and solutions within the different contexts.

How Reciprocal.dev can help you make the most of your User Journey Maps

Reciprocal.dev was created to help you get the most value from your User Journey Maps and provides features to enable you to adopt the practices detailed in this list:

  • Save your User Journey Maps: Your User Journey Maps are saved to the cloud so you can access them at any time
  • Share your User Journey Maps: You can share your User Journey Maps so that your team members can access them whenever they need them, on any device
  • Create snapshots of your User Journey Maps: You can create and switch between snapshots (we call them versions) of a User Journey Map easily and any visualisations you have active will remain active between versions too
  • Visualise your technical data: By tagging the steps and connections in your User Journey Map with technical data points you can then visualise that data across versions and at the micro and macro scale
  • Work across the micro and macro scale: By tagging the steps and connections in your User Journey Map with one or more user journeys you can focus on that user journey across the product map at different levels of zoom

If you’d like to see how Reciprocal.dev can increase the value you get from your User Journey Maps you can sign up for a free account and read our help articles on how build an interactive User Journey Map using the features mentioned above.

Ready to dive in

Create a free Reciprocal.dev account today