Building a new application is exciting. You have an awesome idea and some great thoughts about what frameworks could fit, what cool new tech stuff you can implement and what programming language would be most performant to do so. So, you start reading into the latest technologies, find some totally performant solutions and some really great features that help you build faster and better.
You create a new repo and start building the first proof of concept with your newly discovered technologies. Well done! You start rolling out your user models, implementing authorisation, authentication with some great safe webtokens and so on. And then some new ideas for extra functionality arrive, one after another and “byte by byte” your awesome idea unnoticedly morphs into a somewhat, what I like to call “Frankenstein”-alike application.
It’s like assembling an IKEA closet without a manual. Before you know some pieces don’t fit into place anymore and the shelves are facing the wrong way. In my UX work I’ve seen it happen a lot. Usually that’s when a team calls me with the message “Eve, we have a problem”. Recognizable? Then let’s solve this problem, together!
It may sound cumbersome but building a product or application is not so different from assembling an IKEA closet - you need a manual, a map. Preferably before you write a single line of code. Why? Because it’s the only way you and your team members can be sure you are on the right track creating your product, solving the right problem for your users, while figuring out the details. Keeping the focus on the right place. Is that agile?! Yes it is! You can validate and improve your map incrementally along the way. The map can even function as the backbone of your product backlog, if you wish.
More often than not, the precise moment I speak out the words “user journey map”1 in a room with fellow developers, the concentration level drops to a point of “Not my piece of the pie” . But trust me, dear fellow developers, it is totally worth your time. It will help you putting the screws in the right place and the shelves in the right order. In my experience that saves a lot of discussion time and rework later on as well. And no worries, you don’t need to sketch any happy paintings, if you don’t want to, I promise. Just some sticky notes will do.
An important piece of the user journey map process is to first create a “frame of focus”. The frame of focus reduces your product to its essence, core goal and main actors. It actually follows the classic journalistic approach and answers the 5 W-Questions:
In my experience answering these questions is often not just really hard, but also a crucial part for new software projects. The frame of focus forces prioritization, while defining a key concept at the same time. It also reveals differences in understanding of the product within the team itself. Without one clear goal, no journey can end up well. And I need to emphasize the one clear goal here, not two or three ;). Especially for new projects that haven’t been launched yet - follow the KISS principle here - my fellow developers, you know what I am talking about: Keep It Simple and Straightforward.
That also counts when choosing the main actor. If your product is SaaS or in a B2B environment that means your main actors are companies. In any doubt the main actor is also easy to identify as “the people that (will) pay for your product”.
The where and when questions will help you identify details about the environment, special circumstances, “state” of your main actors in order to be motivated to use your product. It also gives information about your product’s positioning geographically, or physically in order to be “visible”.
I must confess the why question really is a little stinky trick question here. Its function is to reveal the additional value of your product. Without additional value it will be really hard to sell your product. So, let’s write it down: Why should your defined main actor use your product (instead of your competitor’s) to solve the problem you are solving? Why is it better, or different, or cheaper maybe?
Write down all answers on a board or paper on your wall. It’s important to have them in plain sight on a daily basis. If you work with a larger team which gives a lot of feedback, I can recommend writing down all answers. Don’t start discussions, instead use Dot-voting to find the most important goal or main actor.
So now you are all set to map the journey. This theme I will cover in the next part which will be coming soon!
Definition of a journey map: A journey map is a visualization of the process that a person goes through in order to accomplish a goal. Source: Nielsen Norman Group ↩