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.