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.

8 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.

  7. Kristen says:

    Wow what a great article…I am very green to how systems and computer/ Internet “stuff” work, so I appreciate the common words and the articulation of processes in a way that I can comprehend. That being said: you and the commenter above, kbiel, seem very knowledgeable and perhaps you can help me with a situation I just discovered.

    I am an independent contractor for a company who is using leadgenerator as the program they trained us on to enter leads we gather for them. Once I enter the info in the required fields and click “submit” the page processes, and turns into the user message such as “Thank you. Your lead has been processed.” And then there is no option on screen to go back so if I did not hit the back button, I would need to close out of the screen and reopen the link in a new tab in order to enter my next lead.

    Here is my problem: I have been waiting for the thank you message before hitting the back arrow on my browser, however, even though it tells me the lead processed, I am learning that it did not. Is this something I should have just known, like is this common knowledge that I shouldn’t do that? I get why it wouldn’t be good to do it while the page loads or anytime between the submit and final message, but I would think once it hits that page, I should be ok.

    Michael replies: I don’t think you should be worried about whether you should have known something, or whether something is common knowledge. If you are a testing something (or even simply using something as a non-tester), your question should be “is there a problem here?” By “problem”, I mean “a situation that is undesirable to someone, and that can probably be fixed by someone, although probably not without some effort”. Are you confused or annoyed by what you see? Might other people also be confused or annoyed? Might you lose time or data? Is the value of the product diminished in some way for you? If so, you have a problem; something worth reporting.

    The client never said not to do this or even addressed that this is an issue in training so I am trying to understand so when I inform them of this issue, I sound intelligent lol….Thank you and I apologize for the length.

    To sound intelligent, tell them you’re having a problem, and offer an oracle; that is, tell them that you’re observing a situation that’s inconsistent with something desirable. Here’s a list of desirable things that might help with that.

Leave a Reply

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