When we previously covered personas, we discussed how personas could be used as the subject of user stories or (more detailed) scenarios. These narratives detail what goals the persona wants to achieve and (in the case of scenarios) the detailed steps they go through in order to accomplish said goal.
While this type of “storytelling” approach is simple and effective, it lacks a visual element. While you can flesh out the details in storyboards, many design professionals prefer to detail out personas and scenarios by using journey maps.
The typical journey map is centered around a single persona and a goal, and contains the following content:
The “Story” – this section contains tasks, needs, actions, and obstacles. What does the persona want to accomplish? What do they need to know or do? What actions take place? And finally, what obstacles are in their way? This is usually presented using boxes and arrows with call-outs with further details.
Tools and Touchpoints – What tools are used? What touchpoints (with customer support representatives) occur?
Emotional Experience – How does the persona respond to each of steps in the experience? Are they thrilled or annoyed?
A template for a journey map.
The creation of journey maps requires a bit of imagination and creativity, and it helps to work from (and understand) any existing processes to inform this effort. Often, if an existing process is being refactored, two journey maps are created – one that details the current state, and the second that envisions an “optimized” experience.
Always remember to use the appropriate persona as the “subject” of the journey map. And be aware that, depending on the level of complexity of the experience, different personas may require different journey maps for the same goal (based on the roles they have in the process).
Journey maps allows stakeholders to see a visual representation of an intended experience, and how users interact with the proposed system and solution. It’s a great communication tool, but is usually not the final deliverable. It is a means to an end – a way of letting people know what the planned design will be and how (optimally) customers will respond to it.
How many journey maps do you need? You’ll need one for each major feature that is being designed and implemented. These journey maps will all be “happy path” representations of what the optimal experience is, though you may want to create “unhappy paths” that detail how exceptions or mistakes are handled.
So, what’s the best tool – user stories, scenarios, or journey maps? It depends on timelines, talents, and stakeholders. If you have an aggressive timeline, you won’t have the time to flesh out full journey maps, and you’ll have to rely on simple user stories. However, if you or your team can quickly visualize things through journey maps, then you can still use journey maps. Finally, if your stakeholders are visually minded, you will need to create journey maps to respond to their needs to “see it.”
As with other deliverables, always keep in mind that these documents are a means to an end – they are documents that inform the final design, and while it is important that these documents be clear and useful, we don’t “ship” design documents – we produce applications and tools that help people get things done in a effective, usable way. Focus on the experience, and let the design documentation support the definition of the best experience possible.