We start the week with another tool, so a pattern or heuristic we can use to guide our testing. Let’s kick it off with the rhyme:
“Straight from start to end, that’s a perfect user session But let me now teach you a frightening lesson Cancel, go back, pausing for a video with a cat Your users will probably behave just like that”
So, what does it mean?
This card blends a bit into a few others and, as you will see as we move forward, so will a few others. I will try to explain the (intended) differences between “similar-ich” cards to distinguish them from each other. This card, to me, is about understanding that our users will never* use the system in the ways we intended them to. You may try to guide them, you may opt to (try to) force them to, you may pray to any divinity you like. Someone will find a way around it.
*Disclaimer: Ok, I don’t actually mean never. Of course they will. There is a separate card about never using absolutes like never and always.
Temptress’ trails deals with negative tests, this is not the same. This card deals with the fact that a user might take an unintended route through your system, and still complete the user flow.
Yes, of course, it is important to test that a user can go straight from “I want to buy Agile testing condensed” to “Oh, it will be delivered tomorrow” without passing Go.
It is also a very good idea to try and guide users there and to measure that throughput.
But, believe me, users will behave in so many other ways! And no matter how much you believe “that’s not a bug, that’s a feature”, your users are expecting you to deal with it.
Users will go back, forward, look for something else, go back again, take a break, watch something in another tab, almost check out, be interrupted by someone, decide to look for cheaper shipping. Then, if you are lucky, they will decide to actually go through with the check out. If you are unlucky, they will close the tab, regret the decision, open it again and STILL expect the cart to be there. They might even expect it to be there the next day.
And I am not only talking about back buttons here. I am talking about all the ways a user might take a detour. Back buttons, cancel, clicking on something else, doing something in another browser and/or tab, taking breaks, switching languages in the middle of a user flow. I am sure you can come up with a lot more if you start thinking about it.
How far you take this is not a simple or obvious decision. There are a lot of aspects to consider and every choice means a risk somewhere. But, please, make sure you talk about it, make decisions and test those decisions.
One of my absolute favourites is when a developer gives me multiple options to go back. Oh my. So many delicious ways that can go wrong!
Well, I have had a bunch of argument about these things over the years. I have developed a very bad reaction to “That is not in the requirement” and… I confess, I might have lashed out about it at times.
At one point we built a new user portal and spent a lot of time getting that to work and look pretty. Then, halfway through, someone realized we needed a “mirror” for internal usage. Because, well, we realized that we needed to be able to handle whatever came back to us. That was thrown together a bit too quickly and we took at lot of bad usability decisions. One extra bad one was that all searches (and settings of that search) reset every time the user returned to it. Since that search page turned out to be a very important landing page for a lot of our internal users it caused all manners of frustration. So, people would load the search page which included a list. They would do a bunch of filtering and sorting to find the cases they actually wanted to work with. Say they got… 20 items. Then they would open each, do what needed to be done and return to the list. Which was now reset.
Imagine doing that every day.
It also, if I remember correctly, cause people to start opening multiple tabs to keep the search. Which, in turn, caused issues with sessions and other fun stuff getting messed up. To add insult to injury, it took a (shameful) lot of years to get the fix prioritized since it was for internal users and no one really knew how to fix it. In the end I think it got rewritten from scratch.
Another examples, totally different, to show that this does not have to be only the user interface. I was working with a system that (among many other things) created invoices. There are rules about series of invoice numbers that we needed to follow so there could absolutely not be breaks in that series. Invoices could be cancelled, of course, but there 100% could not be an unexplainable break in the series. Someone had at some point decided to use an index for that, automatically created every time a post in that particular table was created. The problem with the implementation was that if something happened to the transaction, it backed everything quite nicely back to before it started. But just that single transaction, that single post (or posts if multiple tables where involved). This was just a small part of a big batch job that handled lots and lots of invoices and each invoice was a separate transaction, running on multiple threads, so before that transaction was completely undone any number of new invoice numbers could have been generated. The result? You guessed it. A hole in that series that could not have holes.
Quote of the day
“Cancel every action you can, and cancel it many times and under many different circumstances.“