What is the user experience journey? Let’s consider an example: Do you remember the very first time you deposited cash or a check at an ATM at a bank? I’ll bet top dollar that all your senses were on high alert at that moment because you didn’t want to commit a mistake with your cash. But did you also realize that everything went smoothly, and that you were able to deposit your cash or check by following specific but simple steps? And, finally, did you notice that you were done in two shakes of a lamb tail? I bet you did!
This set of interactions involving you, the bank, your magic ATM card, and the ATM machine is called the user experience journey (often abbreviated as the UX journey). The user experience journey is an important component of the bigger picture that is the banking experience in its entirety, and it’s designed entirely to make things as easy and as painless as possible for you, the customer.
Put simply, the idea is to enterprise a business process while keeping the user in the driver’s seat. The goal is to go from point one to point x without any hassles while users (in this case, customers) complete their desired tasks, cross several touchpoints, and generate and process a good volume of useful data. All the while, users do not feel that they’re playing a role in what is in fact a complex technological procedure.
In reality, the process itself takes around two minutes, depending on how familiar the user has become with these machines, but that’s not the complete picture. To gain a holistic understanding, let’s step over to the other side of the mirror.
An interesting mix
With multiple layers of operations consecutively running at the same time, banking is considered to be a very specialized business domain. Banking is also one of those spheres which relies heavily on other networks for support, a framework that consists of, for example, merchants, card networks, aggregators, issuing banks, customers, and terminals—and a lot of APIs in between.
For the software development team, the load of the daily task intake is good enough to make them busy enough to write and fix their code within extremely parameterized requirements. Their testers face the same challenge but in a different form: They must continue writing and updating test cases as these applications are being delivered to several clients.
When things were done “over-the-counter”, the process was simple and just wobbled towards one end of the problem (that is, toward the teller), but since the introduction of mobile and internet banking alongside automated teller machines, the banking experience has evolved to new levels. Along the way, this evolution has introduced more complex user experience challenges.
What to cover with test cases
Now contemplate this: While writing test cases for a cash or check dispenser, testers must divulge how their code is written and what it does, how many APIs are involved, several modules working together—including customer data accounts information, bank transfer, bridge, switch, Credit Card domain, billing networks, check scanning, cash deposits, withdrawals, balancing, notifications, emails, and finally committing to the account.
Consider all of these parts moving in sequence (or around the same time) and in a time-boxed situation of under two minutes, while a customer stands in front of an ATM machine, impatiently waiting for her request to complete, to receive a receipt, and for the machine to return her ATM card, so that she’s can check this task off her list and move on to the next one.
Can you grasp the reality here?
For testers, the challenge is not the developer side cases. For those, the code already reflects half of their efforts and most of these are automated on the go. An efficient regression team can handle that side pretty well with their level 1, 2, 3 of regressions and some upgrade testing.
The real challenge originates when testers start drawing cases for customer interaction with the system. Here most of the test teams put their heads in the ground and decide to address issues as they occur—when customers start interacting with the system. But that is not a good approach towards efficient test coverage. So how should a team go about it?
Here is a solution:
Map it
Map the process. In our banking example, this means mapping out the first time a customer walks into the bank and/or to the teller, to the time she walks out with a receipt in hand. Address all instances and dependencies. For this process, there are several mind-mapping tools available, but at the end of the day the best option is to draw focused and de-focused maps.
This heuristic helps tester explore the process/application in one go, from end-to-end, all while learning what exactly is going on. It’s exactly like when you need to go to a certain address but decide to have a look at the area using Google Maps beforehand.
The behavior of exploring that Google Map preview is exactly what occurs when a tester creates an application/experience mind map. This focused and de-focused approach is what naturally embeds in our behavior. It’s a wonderful technique.
Focus group
The best way to manage user expectations is to start by asking them what they expect. To do this, one would create a focus group consisting of a representative sample or, more simply, a survey for the customer to complete right at the bank branch where the action happens.
You can expect that the data you will gain will be accurate and very helpful, allowing you to make tweaks to the user experience journey. These insights make for valuable data that you’ll never get from discussions with product owners and developers.
Change the context
Testers should learn how to shift their context from one user/business perspective to another. This takes practice and attention to detail. A tip: You cannot draw every conclusion from these scenarios, but you can identify the closest behavioral contexts for customers. Once customers start interacting with the system, you’ll then be able identify the right tuning intakes.
Build a test lab that works
Wise test teams spend a significant amount of their budget on constructing good test labs. These labs can be for the purpose of information security setup, performance testing, or just to address completeness to the system.
For example, a company dealing with the automation of ATM machines should have ATM machines at their disposal, otherwise neither their test team nor their development team can ever reach the desired test coverage.
To reduce the potential of unforeseen issues, a test lab should contain a replica of the actual system where testers can perform user-based cases and ascertain their results.
Walk the talk
Needless to say, smart testers are not satisfied until they can be hands-on with a process. They want to utilize the actual—rather than hypothetical—system.
In our banking example, the best way to do this is to visit the nearest branch and experience what the user does by observing it but—and this is very important—also by doing it. Both activities will draw different but nonetheless solution-oriented results.
Observe what a user does and how they interact with the system. Record any heuristic users may adopt that were not part of the system design, and how the overall domain environment interacts with the user alongside the application.
Conclusions
The user experience journey should never be an afterthought. With the above approaches, you can actually predict a higher accuracy of user experience interactions with any application while also ensuring good test coverage. And remember: Overshooting is better than falling short of your target.
Other than that, the path to achieving 100% test coverage and 100% bug discovery is still controversial. Some claim that automation should be the solution to this problem, yet the inputs for automation cannot come from an automated source. As things stand, we still need to rely on ground intelligence and input from non-technical entities.
User experience and creative testing are both becoming a necessity for test teams to comprehend and utilize as standard practice. Yet the real challenge here is not a matter of grasping complex coding structures and gaining comprehension of how these processes work, but rather understanding how users will use applications, and how and if we can provide a better experience for them. And test teams consisting of smart minds can certainly do this.
