Failure Mapping of Purchasing a Round Trip Ticket
In his blogpost about 13 design predictions for 2017, product designer Chase Buckley explains that “Failure Mapping” becomes an increasingly important UX practice in a future where we face new untrained users and elderly people joining the online community. While traditional journey maps focus on the behaviour of ideal users, failure maps take non-ideal scenarios and incorrect usage of products and services into account.
Inspired by this blogpost, I developed a journey map that does not only reveal usability issues and pain points, but also shows the flow of a non-ideal user experience. This interpretation of a “Failure Map” is slightly different to Chase’s definition as it concentrates on design and system flaws rather than on errors as a result of lacking experience and familiarity with using digital interfaces.
Nonetheless, both cases lead to failure regarding the job to be done, so “Failure Mapping” seems to be an appropriate term for both perspectives.
The findings that underlie the following journey map are the result of a heuristic evaluation I conducted for the coursera online course Human-centered Design: an Introduction by University of California, San Diego (read here more about my course experience and takeaways).
As transportation was the general topic of the course, the task was to pretend purchasing a round trip ticket starting in my hometown via a website of choice. While going through the buying process, I had to identify at least five violations of Jakob Nielsen’s 10 Usability Heuristics, based on the following list:
The developed journey map therefore can’t be considered a reliable or representative artifact being derived from research and usability testing with a number of real users. That’s why it doesn't contain any emotions or thoughts users might have during the journey.
It should be rather regarded as an exemplary way of demonstrating UX issues I came across as both a normal user and someone investigating a site in the role of a usability expert.
Furthermore, due to the restricted nature of the simulated task, the journey concentrates on the experience of buying train tickets online, not on the whole experience of traveling.
I chose the website of National Rail, the most common supra-regional train service in Great Britain which includes different operators. I’ve never tried buying a ticket from this provider before, so I was pretty unfamiliar with both website and service, hence I was a new user with a need for discovery and a chance to fail.
Based on the given task, I wanted to buy tickets for a round trip from my apartment in London to Brighton and back home on Saturday, 20th February.
But let’s focus on my journey on the website. Which steps did I pass in a non-ideal but real scenario?
As we can see in the map, each step contains at least one issue which interrupted the flow more or less noticeably. To understand what exactly went wrong in each step, we’ll have a closer look at the interfaces, how they support errors and how we can reduce users’ risk of failing.
Search forms: Set default settings with the user in mind
Default options should be always applied with the user’s job and preferences in mind. As both users and jobs are diverse, it can become a difficult challenge to anticipate such preferences. However, setting standard choices as default options is probably a good way to serve average users and jobs.
Traveling first class is not a standard, so there is no need to select it by default in the very first search form. Furthermore, reselecting the first class setting in the search form as well as filtering standard fares from first class fares in the search result is a waste of cognitive energy.
Search results: Design for ability to scan
As Steve Krug points out: "We don’t read pages. We scan them." (from his book: Don’t Make Me Think). Especially in the case of search results where users have a clear idea of what they’re looking for, they focus on words and phrases that seem to match the task at hand – and skip the rest.
But making content scannable doesn’t only mean to keep it short and concise. In the example from National Rail’s website, the content provided is precise and relevant, but the use of colour and positioning makes it hard to get a quick overview.
By using a minimalistic colour palette and highlighting important elements by distinct colours and prominent placing, we can help users find the crucial information more quickly.
How to decide which information is crucial? Ask the user.
Transferring users to other sites: Avoid confusion caused by inconsistence
Due to the fact that National Rail’s website is a platform comprising several ticket providers rather than a vendor itself, users are forwarded to the websites of the actual provider as soon as they’ve selected a train. If the visual appearance on the new website is considerably different, this can have an interruptive effect that slows down the process because users have just started to become familiar with the previous site and now have to find their way around the new one.
National Rail solves this issue pretty well by not only informing users about the transferral, but also requiring them to click the “Continue” button and so making sure that they have noticed what will happen. Furthermore, showing the new site’s design in the background before users enter it helps them to be prepared for the upcoming changes.
Transferring users to other sites: Make their choices visible
The actual challenge of transferring users to a new site, is that the process continues where it ended on the previous page. This also means that all the choices users have made along the process are still available.
In our example, the previously selected tickets are still saved in the shopping basket, but there’s one crucial mistake: The user can’t see them.
Instead the new site makes the user think she has to select tickets again: First, the page shows a list of other train options based on the initial search request and asks to choose an outbound service. Second, the information “Current Journey: £0.00” and the dimmed Continue button on the bottom of the page suggests that no choices have been saved.
The shopping basket containing the previously selected journey is in fact only one click away, but the small icon and type in the top right corner are hardly recognizable.
Why forcing users to make choices they’ve already make? Why forcing them to go back to a stage they’ve already passed?
Directly forwarding users to a page which shows the shopping basket (see screenshot below) would be a simple solution for this problem.
Ticket Collection: Give smart suggestions
When it came to finally getting the tickets, the new website showed different options for collection. of which “Collection from station” was chosen. Unfortunately, I couldn’t collect tickets at the station I will depart from, so the website proposed to select another station and offered a never ending drop down menu, listing all stations in UK.
Long drop down menus are not only an issue for mobile usage. Although we can use shortcuts by typing the first letter of the word to be found on our keyboard, this only helps us if we know which word we’re looking for. In terms of knowing an alternative station where ticket collection is available, you don’t have to be a tourist to need further help to solve this.
For instance, the website could recommend stations which are close to the station the train will depart from. It could do it by either drop down list where nearby stations are placed on the very top or by using a map. A map would be the preferred option here, as it gives the user a feeling of how far the collection station is away from the departure station or any other location (e.g. work, gym etc) the user regularly spends time.
Payment: Make clear which action a button involves
Clicking a button within a buying process generally means moving further to the next step. This should also be emphasized by the button itself, by carrying names like “Continue” or “Next”, or even better by explaining which step will be reached after clicking the button, for example “Proceed to Checkout” or “Confirm and Pay”.
With regard to payment, the action-based naming of buttons becomes especially important.
National rail currently uses “Payment Details” for a button that introduces the payment process. The name neither contains an action-based appeal (e.g. “Add Payment Details”) nor makes it clear that a further step of the buying process is involved.
We find another “button-name-problem” later in the process, directly before paying:
By offering a button called “Pay £13.60”, the website gives very precise information about the payment details by including the price in the button name. What remains uncertain is what will happen after clicking the button: Will the system only charge my credit card or will I confirm my purchase and get my ticket?
From the user’s perspective, paying £13.60 is not the final step of the process. It is buying tickets.
A term like “Buy ticket now” or “Confirm and Pay” would provide more relevant information about the action from the user’s point of view. The price is also shown in the order summary on the right and doesn’t necessarily need to be mentioned again in the button name.
Confirmation: Show user’s status in the buying process
The second button-problem wouldn’t be that dramatic if there was a progress indicator showing the user’s status in the buying process as well as previous and remaining steps. By including “Confirmation” as last step following the payment stage, it would be more obvious that users actually confirm their purchase by clicking the button “Pay £13.60”.
This lets a progress indicator become a powerful tool that informs users about the very end of a multi-step buying process and also gives them the chance to go back and edit their choice.
Besides the overall sense of control users gain from a progress indicator, confirmation as last step also builds confidence by giving users the guarantee that they will receive a message saying that everything worked out.
However, National Rail’s website doesn’t provide any progress and status information throughout the entire buying process. Although there is a back button, not knowing where this back button leads to makes it less effective. Even worse than not seeing the steps already passed is not knowing what’s ahead.
Although these kinds of online buying processes may be learned by most people nowadays, there are still users who are not accustomed to buying things online and need status and progress information as reassurance. Also with regard to “expert” users, missing status information can lead to uncertainty and confusion because they expect this information as knowing it from other shopping experiences.
Failure is human and maps that show us how systems cause user errors reminds us once again that we need to design from a human-centered perspective. And this includes taking all different types of users into account, especially when we build a product with such a broad user group like travellers.