User experience design is fundamentally about communicating a centralised canon of knowledge around a design, even if that canon is transient in nature. It’s about formalising otherwise silent assumptions and scrutinising those assumptions to see if they hold water. This results in the effective communication of user needs to the organisation, while also communicating the organisation’s goals to the user in a way that is appealing to the user’s needs.
This communication process starts with the designer making sure all involved, including herself, understand and agrees on the problem the design is supposed to solve. The communication manifests itself in the various artefacts the designer creates to fulfil this purpose: market research, content audits, information architectures, journey mapping, user testing scripts and recordings, and low-fidelity wireframes. All of these things are quite simply a way of exposing, or communicating, an agreed understanding of the design that a company or group of people are working towards.
Have I laboured the communication point sufficiently yet? Well, I hope so, because accepting the fact that UX is fundamentally about communication is why I love the various artefacts that come out of the process before anything “pretty” is created. The many rough sketches (whether they’re done with a pen and paper or using a low-fidelity design tool like Balsamiq Mockups) are beautiful to me even if they’re not traditionally pretty according to graphic design standards.
They’re beautiful because they’re so effective at communicating the design process among people who have different words for things and even different conceptual frameworks. While they may not be shiny, they shine at concretising organisational understanding and providing high-level focus on what it is we’re actually trying to achieve, before getting bogged down in visceral reactions to style and lexical connotations.
In particular, I’ve always really enjoyed user journey mapping, largely because it can be done in so many different ways. These different ways come from the fact that the map needs to specifically cater for the primary problem area at hand. Because this changes from one project or product or product section to the next, the journey map itself is often realised in different ways. Below are some examples of different user journey maps I have created.
The concept-shift journey map
While at a logistics company, I was involved in revisiting the design of an Android paperless app for drivers. The design up to that point had kept running into complexity issues around multiple delivery expectations for every driver journey, especially because an important requirement was to be able to change the order of collections and drop-offs on the fly. I helped solve this issue by moving beyond the concept of “a delivery”, because it is a concept which enforces a rigid understanding of start and end points, making it difficult to update “a delivery” with information from “another delivery” in a way that isn’t confusing within the context of a phone-based app.
The concept of “Delivery #1” versus “Delivery #2” in a single journey meant one had to jump in and out of user flows in a way that was very confusing, especially if the order of things needed to be collected and dropped-off is jumbled across different deliveries, and if that order suddenly changes due to outside factors.
To solve the problem I introduced the idea of “a trip” made up of multiple “trip stops”. The trip stops ultimately come together to fulfil different deliveries but in a way that isn’t overtly exposed to the user flow of the app. The driver simply follows a linear progression of both collections and drop-offs in the order that is most geo-efficient and sensitive to other external factors (traffic, parcel redistribution to different hubs, delays at the restaurant etc).
Now think of all the words I needed to describe this design shift, versus the high-level journey map sketch below, which does the exact same thing with much less words, and probably more effectively at that:
This user flow may seem an obvious solution, but it wasn’t obvious to the company hired to design the app before I got involved, which had up to that point resulted in some very limiting and confusing design flows. I don’t say this to blow my own horn. The point I’m making is had they explored the designs with some rough, high-level journey sketching upfront, they probably would have realised this themselves.
The user group journey map
For an NPO-type agency, I was tasked with doing some high-level and low-fidelity design for a phone-based mentorship web application, aimed at empowering young girls by pairing them up with woman professionals. The app required three user groups: mentors, mentees, and moderators. The moderators are employees of the initiative responsible for making sure mentor and mentee interactions follow certain guidelines.
It was therefore important that the user flows appropriately demonstrated these user demarcations while allowing the flows for each to impact on the other at certain points. The journey map used horizontal demarcations for these groups, allowing for vertically stacked user flows that could jump the demarcation when necessary to illustrate any inter-group interaction, all the while keeping a clean visual overview of the different groups.
Not being able to see specific details of this map aren’t important here, the macro overview it affords is the point.
There’s nothing brilliantly clever about this, but it provides a wonderfully clear overview of what could otherwise be an entangled design of inter-group user flows. Its simplicity in communicating the design is why it is a beautiful deliverable, even if the shapes and fonts used aren’t to everyone’s liking.
The effort journey map
More recently I’ve been working on redesigning a hefty application process for a local fintech startup. There’s information they just can’t get around asking for which means lots of forms. The journey map in this case consequently needed to focus on some kind of effort metric in order to better understand and improve upon the form drudgery imposed on the user. It needed to ask questions aimed at improving conversions with better progressive disclosure and identifying effort danger points to see if we can reduce them.
The resulting maps compare the existing application process to the redesigned process. The comparison was not only an end-result of the design process, but heavily part of the various decisions made during the redesign by providing insight into user effort.
Once again, the specific details included are not important here. The important thing is the way in which this visualisation of the application process helped immensely in being able to reduce a very steep upfront effort, as well as in reducing overall effort, while not sacrificing unavoidable business requirements.
Beauty over pretty
All these examples above have been done in Balsamiq Mockups, a long-standing wireframe tool that has gone out of favour with many designers who deem it ugly. I keep using it because it is brilliantly optimised for fast digital sketching. It means your effort is being focussed on the functional problem solving required rather than whether a shape or font is pretty enough. It allows me to move quickly and progress faster down the UX design communication process.
These types of maps really prove their worth not only in deriving optimal user flows, but when you later get stuck into the minutia of page-to-page designs. They help everyone navigate through the design process, illuminating the larger landscape even while we’re all heading down a specific path.