Building the perfect user journey

Building the perfect user journey

You want to empower your teammates and help them be independent and efficient in their work. 

The way to achieve this is by having a shared, single language, one that everybody understands.

In our case, this language is the visual language, as that's the one language that breaks the barriers of cultures, locations, and disciplines. 

The power of the visual language is in its ability to both share a vision and provide a rich context for every individual, based on what they are looking for.

Imagine we are a banking-as-a-service startup called Bankify.. or Banksy.. Something to do with “Bank” and a cool startup-y suffix.

We are building the loan application user journey.

Before we begin, let’s outline the main aspects that every user journey and plan should include;

  1. A happy flow, from start to finish - end to end. I’ll repeat the ‘end to end’ for emphasis, because quite often companies focus purely on the frontend journey, and completely forget about the backend one, which, to be frank, is where the majority of the financial logic takes place.
  2. Failure considerations - we are interested both in what the user will experience in case of failures, and in the technical behaviour of the platform in such cases (i.e error reporting, or Slack notifications).
  3. UI designs / mockups - which are crucial for the frontend work, regardless of whether it’s a mobile native app or a web app written in React / Angular / Vue / Svelte / …
  4. Technical documentation - in the form of API requests / responses, which are mandatory for the backend work to integrate with the frontend work
  5. Analytics events should be defined for every step necessary
  6. Additional thoughts / notes / ideas about edge cases & implementation details

Following this list when creating a user journey will not only help team members to understand what needs to be done but also empower them to work better together as well as individually, on this specific journey. In addition, such a clear and well-documented structure will assist with building the test strategy, compiling a list of test cases, and will save you hours and hours of debugging later on.
Finally, having an extensive yet simple & visual documentation like this one will incentivise people to come and keep it up-to-date, so you can be certain that it will not be forgotten after the planning session is complete.

Let’s start by looking at a complete example, and work from there in order to see how each and every step from the list above is fulfilled:

  • We’ve invited our team members, and structured this end-to-end flow together. The frontend and backend parts are clearly identified.

    This is crucial because we need to make sure that our backend team members will know which UI action triggers a certain backend action, and thus be able to plan accordingly all aspects of the technical implementation, including performance & monitoring. It also helps everyone understand the mindset of the end user when they reach a certain stage, and that helps us make the right decisions from a product perspective, and avoid overloading the user with waiting times, processing, or form-filling.

  • You will notice that as soon as you start mapping out flows as journey diagrams, a magical thing will happen. All the edge cases and failure scenarios will reveal themselves before you, without you having to do any additional effort. The only thing left is to add these permutations and edge cases to the plan, while marking them accordingly.
We’ve identified a potential timeout edge case, and marked it accordingly.

  • Adding the right mockups and designs should be straightforward, you can do that by just dragging & dropping image files to the whiteboard. Alternatively, you can also link out to external sources, such as Figma or Sketch pages:
An example design dropped on the diagram

Designs and Figma links, added to a particular item on the diagram, as attachments.

  • Technical documentation can be added to every single step, with the most crucial ones being API requests / responses, schemas and examples. Most likely, these would be most relevant when different components communicate with each other, such as frontend with the backend, or when any of them communicate with some third party or external service.

  • Analytics events are crucial in measuring the success of marketing campaigns, understanding feature adoption, and analysing user behaviour patterns.
    Although STATEWIZE provides tracking out-of-the-box for every single step that every single user makes, it makes sense to integrate with other tools such as Google Analytics.
    Instead of defining these events in an excel sheet or an airtable somewhere, it would be best to just add them to the same place where the whole journey is defined. The better your data is centralised and organised, the easier it will be to keep it up-to-date and use it on a daily basis.
    For example:
We have listed all the analytics events that should be reported, as well as the exact scenario when they should be reported, i.e upon success or failure of a certain step.
In STATEWIZE, defining these events will be sufficient for the integration in general, as STATEWIZE will send those events to the right places when you report them via the SDK, so you will not have to implement them manually in your codebase.

  • Finally, notes and ideas can be just added to the diagram as code snippets, or as links to external resources such as Jira, Trello, YouTrack, or any other tool you use on your day-to-day

This is how you can create the ultimate, always-breathing & always-living documentation, which helps your whole team to work independently, while also empowering real-time collaboration during all phases of the software development lifecycle (SDLC), starting from planning and ending in production analytics and production monitoring.