Creating Effective User Journeys for Agile Teams

In an Agile environment, the designer needs to quickly sketch out/wireframe ideas, validate them by testing and then reiterate on the findings in order to improve the experience until the desired result is achieved.

So when we follow this type of process, there shouldn’t be much room for the classic UX deliverables we read so much about. But UX professionals still produce a wide variety of design deliverables. This is the Agile reality even if documentation should provide the minimum amount of information necessary to get started on implementation.

If Agile deemphasizes unnecessary documentation, and considers it a form of waste, shouldn’t we focus on just wireframing and prototyping?

Where is the value in personas, scenarios or customer journey maps?

During a presentation, the stakeholders will go through them just to see that the design team is making progress on a project and the developers will just scroll Facebook on their phones until they see a diagram that is system related or a wireframe that they might find useful in development.

They don’t have the time to understand the reason for why these artifacts are created and I don’t blame them. In the end the designer is the one that benefits from them in order to create better final deliverables, deliverables that are based on these artifacts.

Having this said, I still find user journeys very useful, and I use them all the time; but in a different form, a component oriented form that can bring value to both stakeholders as well as development teams.

Before explaining what I mean by component oriented user journeys I’ll quickly go through what the classic definition of a user journey is.

A user journey is the story of the relationship between a customer and an organisation, product or brand, over time and across channels, seen from the customer’s perspective.

Even though the story is told from the customer’s perspective, it also shows the important intersections between his expectations and the business requirements.

Another way of describing them would be that they visually illustrate an individual customer’s needs, the series of interactions that are necessary to fulfil those needs, and the resulting emotional states a customer experiences throughout the process.

As you can see, both descriptions are rather vague and allow for room for a lot of interpretation on how these should be created and how they look like. If you do a bit of research, you’ll never find two user journeys created with a similar approach, either text-based or as a visual representation.

Also, there are a lot of different opinions on where during the course of the design process it should be created. They usually come towards the beginning of a project in the requirements gathering phase, after personas. But they usually come in after the personas and the task models have been created so that they are aligned with each other. But they should also validate the wireframes so they should definitely be created in the user testing phase, after wireframing.

I believe all of the above are valid to a certain extent but this whole concept can be interpreted in so many ways that it loses clarity when explained to a stakeholder that is not familiar to it.

There are numerous articles on what user journeys are and how to create the perfect customer journey map, so I won’t try to add another point of view on this topic.

But I will try to apply some of this knowledge to create a particular type of user journey, a component oriented user journey that I hope will help designers communicate better to development teams and meet their needs.

In a nutshell,

A component oriented user journey details the steps that a user makes through a system in order to complete a task.

A component oriented user journey will show the clear and required paths through a part of the system rather than a desired user behaviour, needs or emotional states throughout the whole application.

One big advantage is that in an Agile environment, where your work is divided in smaller sections, these user journeys are able to detail the user’s steps throughout each individual component.

By showing specific routes that the user takes through these sections, you don’t have to worry about thinking of the overall picture every time. You are able to focus on smaller pieces of functionality, therefore making your work easier to manage in a fast-paced environment.

A component oriented user journey is able to help you figure out how the user will behave throughout a section, and is helpful when discussing the options with the dev team, revealing the pain points that need fixing.

User journeys are an important tool as they highlight the current issues and reveal a typical user’s perspective of the experience early in the design process. But in an Agile process they need to adapt and to a leaner version, in which they focus on individual components rather than the whole application.

As UX professionals adapt to Agile and lean UX processes, processes that value transparency and collaboration, time-consuming deliverables will slowly fade out if they will not be adapted to the current software development needs.

If you liked this, click the ♥ below. Follow me and UX Design Today for more articles on UX Design & Agile practices.