We are so used to linear progression from start to end that we sometimes forget that we can do things working backwards. Designing this way works well in helping the users achieve goals because we focus on the product itself more than on the problem-solution approach. This allows for more optimal workflow in journey mapping and prototyping.

It’s easier to find the best and shortest way to reach a goal if we see the goal clearly before us.

The basic premise of the ‘working backwards’ method is to start with the end result first, clearly define it, and create rules for measuring success in this case. Then test and validate it with users. Afterwards, go backwards step by step by thinking of the least important objectives first. Finally, close the journey with the the most important, non-optional piece of the puzzle — this will become the starting point. We can also add a prologue — in case of digital products we’re going be concerned with weaving our new idea into the fabric of the entire product — we will look for a place for the journey’s starting point in the bigger context.

The backwards method is easy to use, and great in the process of creating user journey maps and prototypes.It encourages us to make a straight line from the goal to the starting point.

It also helps, because we focus first on being able to validate the success criteria and distribute them into groups by importance. If we start our mapping process with the screen that shows a newly added To-Do item, we are able to more clearly see what steps are necessary to get there, what input should we ask from the user, and which parts are optional etc.

It’s also allows to easily see what can go wrong during each step. For example, the user may not be able to move forward because there’s something missing and we can arrange for features that would allow to start moving forward again.

How to use this method?

  • Start with the final screen. What is the goal? What are the success criteria? What is the data structure that is created as a result of taking this journey? Are some items more important than others?

Summary. Go back one step: Should you provide a summary before the user ultimately commits to the action he is trying to perform? Should we allow to go back and change details?

  • Secondary, optional details. Go back one step: Which details are secondary? How do we allow for collecting those details?
  • Primary details. Go back one step: Which details are primary? This is like the required fields in a contact form or survey. The journey makes no sense without them.
  • The most important detail. Go back one step: What is the most important aspect of this journey for the user? In contact form it may be the message itself.
  • Prologue — product context: Where to include this feature in the product?


Customer Journey Maps with Prototyping