Recently I had a discussion about my favorite tool user journeys with a client. We were talking through a planned workshop design and he couldn’t understand if we do a user journey of an as is process how we could come up with the requirements for a future product. I found that an interesting question because I had never asked it myself. I actually had trouble explaining it as I have never in my experience seen that as a problem. Whenever I have done a user journey in the past for whatever process, problems emerged almost by itself. Using it has always proven a very valuable tool to create common understanding and then build upon it.
I’d like to take this experience to revisit user journeys and give a little overview over what I use them for.
There might be other stricter definitions but for me a user journey is any process description I am making from a user’s point of view where I describe step by step what he does when, with whom and how.
Classically used to describe user interactions with a product or service I nowadays use it frequently for processes within teams or organizations.
Bringing all people involved at one table and have them individually describe the apparently same process and then comparing results often reveals surprising differences.
These differences can then be used to open meta communication about them. For the people involved it is often an ‚aha’ moment when they realize that there are different understandings of the same thing in the room or can finally put their finger on an issue they before kind of anticipated but couldn’t pinpoint.
One situation I have used this methodology successfully is within the inspect and adapt cycle of agile teams. For example we came together as a team to look at how we use user stories within our development cycle. Everybody would describe when she interacts with a user story and what she does with it and together with whom. We had Developers, Testers, Business Analysts, Experience Designers and Product Owners in the room which made for a lot of perspectives. The first thing that became visible that the point in time where people put estimation sessions differed wildly. Some people even put up several stickies with estimation 1, estimation 2, estimation 3 or estimation and reestimation. Other people immediately doubted that those reestimations ever took place. We had a discussion about it right away.
No need to search for a problem. We simply couldn’t put these stickies into our timeline properly and clusters became visible. A colleague tends to say the human brain is darn good at pattern recognition. All that user journeys do is make patterns visible and then it is up to us to react. If you build a user journey and put it up on the wall these patterns can be different things. One item that only comes up once? Something everybody in the room writes a lot of stickies for? A process step described very differently from one person to the next? A step not having a previous step and kind of hanging there lonely? Put it up there and look at it from afar. Everywhere where it is especially empty or crowded is where you want to take a closer look. And from my experience you hardly every really need to look that closely as these pattern basically jump at you or you have a discussion in the room before you manage to turn back around from putting up a sticky.
Digging into the estimation issue it became pretty clear that nobody really missed not being involved in estimation or wanted more of them. People rather missed different bits of information at different points in time. Knowing the big picture and early on hearing about upcoming stuff was one need. Another need centered around being sure a story is actually ready for development and all necessary questions have been asked. We are now trying a backlog grooming approach to be able to more regularly talk about stories in different states of maturity.
Interestingly the session was originally triggered by us being unhappy with the amount of detail within the stories. We had the feeling no matter what we did we couldn’t get it right. Does „but that wasn’t in the story…“ or “that is so much text I won’t read that…“ sound familiar? We would get one for a month, change something and hear the other one for the next months and so on. After our user journey session it became very apparent that we would have never been able to solve that issue within our stories as the root cause lay somewhere else.
Curious to hear what you use user journeys for and what your most surprising findings were?