Everything Has a User Journey

Low-angle picture of an empty road, with autumn trees lining each side.

Some of you clicking on this post might be sitting there, scratching your head baffled thinking “what is he on about, what do you mean everything has a user journey?”. Well, by that I mean within the course of our work there is always someone or a group of people at the centre of it that we’re trying to craft a journey for. In this blog post I want to show you a few of the ways where I like to turn the situation into an opportunity to stretch my UX brain and craft out the journey I want that person (or persons) to go on.

Examples of Hidden User Journeys

Here are four different real examples that I’ve encountered and thought about in a different way with a design hat on, that you might have as well or maybe draw parallels to in your own work or life.

Taking on a New Project

For the majority of businesses you will regularly spend time meeting new clients to see if you can add value to their business and if you want to work together. After a few iterations you’ll have a “way” of doing this that acts a bit like a pipeline; new or existing clients enter your engagement pipeline, you work through a process (strict or loose) with them and either end up accepting it or rejecting it. What you might not realise is that subconsciously you’ve constructed your own user journey and want to evoke certain emotions at certain points in that pipeline.

At the beginning you want to evoke credibility and comfort. If your potential clients don’t believe you’re credible you’ll never get the opportunity, and if they aren’t comfortable then you’ll struggle to get the key insights from them that help determine whether the partnership or project is right for you. In the middle of the pipeline you establish trust and build up rapport, and by the end of your pipeline whether you go ahead and work together or not you want your clients to move forward feeling like they’ve got clarity and a way forward. Either you’re providing that clarity and partnering up, or leave a pleasant taste in the mouth with a polite decline and suggested ways forward or referrals.

Products Themselves

I won’t go into great detail here, as most people grasp the concept that products like a bottle of Coca-Cola or web browsers have a user journey. It gets crafted from everyone involved from Designer and Developers to Stakeholders and Users. From the first time a user encounters a product, whilst they’re using day-to-day all the way towards its end-of-life where you can take into account a product being repaired or replaced. Whilst most focus on the first two stages, first encounter and regular usage, not as many focus on the end-of-life. Apple are a great example where they’ll recycle your old Apple devices responsibly, and provide in-store credit if it still has enough value to be refurbished and resold.

Knowledge Bases or Wikis

This is one that can be easy to forget actually, but one that information architect geeks will (hopefully) kudos me for. Wikis in general exist to help people do two things: add content, or find content. Focusing on the finding of content— since the community are the writers we actively make decisions about how the pages in a Wiki is organised, if pages are linked together and how deep or wide to make the structure. By making these changes to the structure and organisation, we alter the journey that someone takes to find the content they’re looking for (or in some cases, not find it).

If there’s going to be a lot of new people regularly accessing the Wiki for the first time then we may decide to have a Quickstart or FAQ page at the top level of the hierarchy. If the users don’t change too much we may choose to have more frequently accessed things at the parent level and skip some detail. If the majority of the user base is cross functional we may segment the top level hierarchy by role or job type. These decisions can mean the difference between a well thought out journey of what someone may be looking for and placing content where they’re likely to look for it, or a muddled mess where the users go in circles and don’t have information organised the way they regularly use it.

Codebases

This one is personal to me and I imagine plenty of developers are shaking their heads right now, but hear me out. One thing I did a lot of in a past life was ensure that entry points to codebases were easy and obvious to find, and that there was as little friction as possible traversing from file to file or repo to repo. Comments and READMEs can all be tailored to help your fellow developers find what they need when they need it, or provide some extra contextual information in the comments when you solve a difficult or obscure problem. There are countless micro-decisions that a developer has to make as they’re crafting the code, and I believe this extra supporting material can mean the difference between an unmaintainable spaghetti mess and a codebase your new and future hires can hit the ground running with.

Conclusion

These are only a handful of instances where I’m trying to craft a journey and I’m sure there are many more I haven’t mentioned. Whether it’s on boarding new clients, contributing to a codebase or simply writing a Wiki or a blog, you’re more often than not creating that thing for someone to use— even if just for yourself. I’d encourage you to put your Design hat on and reflect on the user journeys you’ve intentionally or unintentionally created and see if the existing users are using it as you intended, using your journeys in unintended ways, or if your journeys need revising.

Read this…