Blog: Do Not Close This Window (Or Click The Back Button)

Here’s a classic case of poor design and user experience. Most of us have seen something like it. It happened to my wife yesterday. It will happen to you again soon, probably.

  • You’re making an online payment for some product or service.

  • You press a button that says something like “Submit Payment”.

  • A web page appears that says something like “Your payment is being submitted. Please do not close this window or click the Back button on your browser.” And that’s all the page says.

  • The page stays on your screen forever—or until you wince and close the browser window despite the specific instructions on the screen.

Here are some questions that a tester could ask when presented with this design, or with this experience:

  • “Or else what?” “Please do not close this window or click the Back button on your browser.” Or else what? What Bad Thing might happen? What Good Thing might fail to happen? This should lead directly to…

  • “What if…?” What if the sequence of actions doesn’t go as planned? What if a conversation between a server and a client is interrupted? (Note: the connections between any two systems are at best somewhat reliable. If you believe otherwise, a travelling testing consultant has two words for you: hotel WiFi.) At what points might interruptions happen (quick answer: all of them.) How is the state of the conversation being managed? Have we considered interruptions in our design? Have we tested for them? How does the system handle and recover from delayed or interrupted transactions?

  • “What should the customer reasonably expect?” It’s not hard to imagine a good deal of variance in the performance of a system, especially when its end nodes might be dozens of network hops apart from each other. Still, how long should a customer reasonably expect the transaction to take? At what point might it make sense for the customer to bail out?

  • “How would the customer know when it’s time to bail out?” If you can put a message on the screen, and if you know how long it would be reasonable to wait before bailing out, should the customer have to look at her watch? Might a countdown timer be helpful?

  • “Is there another way?” Is there another way for the customer to see that the transaction has completed successfully, or has failed? Does your design and the message you display make that option clear?

  • “What emotions might come up?” How might a customer feel uncertain, confused, frustrated, annoyed, mystified, impatient, surprised, helpless—or confident, impressed, reassured, or delighted—by what she sees and experiences? How might we use those potential feelings to help us guide our search for problems?

  • “Who can help?” If the transaction fails, who can help the customer out? How does the customer get in touch with that person? Is there a means of contacting customer support on that “Please wait…” screen?

  • “What meta-information is available?” I’ve worked with companies that have said, “We can’t put a customer support telephone number on that screen; customer support would be swamped!” What does that statement tell you about the system, about people’s impressions of its reliability, and about risk?

  • “How do we raise awareness of problems?” When a transaction on our site fails or is subject to an unreasonable delay, how do we get to find out? Is someone alerted immediately? Are failures aggregated? Buried in a log file somewhere? Who looks for problems, and how often do they look? Who hears about problems? How does that information get relayed to the people who design, maintain, and update the system? How might that information—or parts of it—not get relayed to those people?

This last question is important. Its answer provides part of the explanation for the fact that, after fifteen years of Web commerce, we’re still seeing designs like the one that appears at the top of this post.

Want to know more? Learn about Rapid Software Testing classes here.

7 responses to “Do Not Close This Window (Or Click The Back Button)”

  1. What if I change my mind?

    Most sites payment processes goes through a third party and most of the time you’ll find that your carefully selected shopping cart is cleared if you change your mind once it hits that 3rd party service.

    Michael replies: Yes, sometimes it is cleared—and sometimes it isn’t, too. I went through a similar transaction yesterday, somewhat different from my wife’s experience. For me, there was a default limit on the amount of money I could pay through my bank, so my first attempt to pay didn’t complete successfully. I contacted my bank and raised the default. Then I went through the payment process again. Just in time, I noticed that the shopping cart hadn’t been cleared, and my order and my payment were doubled. If I hadn’t noticed this, I can’t imagine the grief I might have gone through—having to find the department to issue a refund, a non-trivial delay in processing the refund and crediting the account, a possible overdraft for that account…

    So, another item to add to the list:

    What happens if the customer makes an excessive or extra payment? How will that get resolved?

    Most 3rd party API’s don’t cater for this either, hence why I’ve always thought it is essential that testers get involved in the early API design process, so we can spot the “what if” scenarios like this.

    Sadly we don’t play a part in the design of the 3rd party services we choose.

    True… but we might play a part in the choice of those third-party services. Are managers aware of the help that we can offer there?

    Very nice post, thanks for sharing Michael.

    And thank you for your comment.

  2. Good point Michael, there is always other scenarios to be considered.

  3. […] Blog: Do Not Close This Window (Or Click The Back Button) Written by: Michael Bolton […]

  4. […] Usability: “The customer is always right” Usability Testing Summary Template Do Not Close This Window (Or Click The Back Button) […]

  5. […] • Michael Bolton ???????? ??????????, ???????? ???????????? ? ?????: “? ??????? ?? ??? ?????? ? ?????????? ?????” […]

  6. kbiel says:

    I can not ever see a reason why you have to tell a user to not use the back button or close a window. If you must do that, then you are breaking the HTTP contract. I hate it when web sites do that I tend to avoid those companies if I can.

    There is a proper way to handle longish running processes via HTTP. Do not make the browser wait on you. Give your users a status page that they can leave and come back to check as they please. If the process does hit an error, then the status can reflect that and give the user some information about how to recover. And finally, every HTTP call is an atomic transaction. Treat it as such. If your post or put call fails, then fail it all the way and rollback anything that might have occurred.

Leave a Reply

Your email address will not be published. Required fields are marked *