The bugs in the travel websites test we did this week, produced some nice screenshot examples of how not to treat your users.
As we always do when setting up website monitoring for a an ecommerce travel website, we set up a few User Journeys, some 7 or 8 page long, to reproduce the process of finding a holiday.Various flows including searching, and choosing at random from the packages offered; as well as some that went straight to the special offers with a minimum of searching.
What we spotted within 24 hours of running these user journeys:
Here is the view the user sometimes gets when adding extras to their package (I’ve anonymised the text in the page, to hide the brand) – it was happening for about 1 time in 40, so 2 or 3 % of users would have experienced it: see the Total payable:
Any user is going to wonder how they pay for those 3 micro, micro pence!
That looks like the software developers when testing their travel website, had over looked the use of floating point calculations happening somewhere behind the scenes in the travel technology backend; and ended up scaring their users with the precision of the pricing! That’s really site confidence undermining.
The benefit of doing true dynamic User Journeys and not just simplistic webmetrics monitoring is clear. Because the problem above only shows up for certain combinations of holiday extras – only when certain price numbers are put together at the back end; not for all extras. So the current monitoring the client had in place, of what they thought were the keynote and sufficient monitoring, was missing the boat entirely: because it always picked the same extras … which didn’t have the maths problem.
Later in the week, for a different travel website testing project, we see these errors:
This time, pricing errors that not only confuse the user, but also upset the page layout too.
In conclusion, our testing travel websites this week shows that even simple maths can go wrong in software somewhere – dynamic user journey monitoring like ours here at thinkTribe will help to identify it quickly, before your users do: and help steer your tech team most rapidly to the keynote root cause, by testing the when and how of it’s occuring in the browser: the right information at the right time to the right people.