 |
Home > Detail: Quality Still Counts on the Web
Viewing Item 1 of 511
| A StickyMinds.com Original |
|  | |
Quality Still Counts on the Web
By Karl E. Wiegers
   
Summary: Internet time. Sometimes you feel like a mouse running ever faster through the maze, toward elusive cheese that frustratingly moves from place to place. “Naturally,” says the head mouse, “we have to take some shortcuts to get to the cheese on time.” So maybe you don’t have time to talk to users, or have a human-factors specialist design the user interface, or execute a rigorous test suite. But that’s okay, you’ll beat the competition to the marketplace and that’s all that counts, right? No. Quality still counts, too. | | |
|
|
 |
Internet time. Sometimes you feel like a mouse running ever faster through the maze, toward elusive cheese that frustratingly moves from place to place. “Naturally,” says the head mouse, “we have to take some shortcuts to get to the cheese on time.” So maybe you don’t have time to talk to users, or have a human-factors specialist design the user interface, or execute a rigorous test suite. But that’s okay, you’ll beat the competition to the marketplace and that’s all that counts, right?
No. Quality still counts, too. With a few exceptions, it really doesn’t matter how quickly you get your product in front of the consumer if it doesn’t work right. I’m dismayed by how many Web sites show significant quality problems, ranging from neglected exceptions to missing requirements and user-hostile interfaces. Some organizations don’t seem to understand that “good enough quality” means the quality has to be good enough for the consumer to use your product more than once.
A few months ago, I noticed I was almost out of blank checks for my checkbook. We’d simply forgotten to reorder them. But, not to worry: a slip of paper in the box of checks said I could now order them on the Web. With relief, I went to the Web site and entered the requested information: account number, bank routing number, and so on. The system told me my order was accepted and that I would receive my checks in about ten business days. In the meantime, I could check the status of my order on the Web.
A week later, I returned to the Web site and asked about the status of my order. To my surprise, the response was, “We have no order for you.” Naturally, no phone number was provided, so I emailed the Webmaster, who also replied, “We have no order for you.” So despite the fact that my order was apparently accepted, it wasn’t really and I never got my checks. Do you think I will ever use that Web site again for anything? No, I won’t. It wasted my time and inconvenienced me. I have no idea what went wrong, but my guess is that there was some internal exception condition that was not handled correctly. As a consumer, I don’t care what the problem is: I simply want the application to do what it is advertised to do. If it doesn’t, no one is served by making the Web site available anyway.
You get one chance, or maybe two if the customer is either very patient or slow on the uptake, to get people to use your Web site or other commercial product, unless they are forced to use it by their employer or because no alternatives exist. If it doesn’t meet their quality and serviceability needs, they won’t be back and they’ll tell their friends.
One of my interests is military history. I just read a review of a new flight simulation game in which the reviewer said, “The software is sadly unfinished, however, and terrible bugs, documentation discrepancies, and disrupted functionality plague this title.” Do you think I’ll buy it? Do you think it would have been better for the developing company to release the product a bit later but in an improved condition that avoided such negative reviews? Release timing and quality levels are business decisions, but being first to market with an unripe product isn’t always a prudent business decision. How many of you own Palm Pilots? How about Apple Newtons?
A software colleague recently told me an Internet horror story. He was entering credit card information into a Web-based service that brokers payments with other e-commerce sites. Faced with a confusing UI design, he tried several times to enter his card information, but the system kept rejecting it for unstated reasons (if an application knows enough to reject user entries, it should tell the user why). Finally he gave up. Soon he got a call from the credit card issuer, reporting a suspicious pattern of eight one-dollar charges.
It looked like a thief might have been gearing up for a big scam, so the issuer suspended his card. Next, my colleague’s wife called to report that a store had rejected her credit card. Apparently, the Web site he was using tested user-entered credit card information by making a one-dollar purchase and then issuing a one-dollar credit. This was the strange pattern the card issuer had detected. The combination of a confusing UI design and this particular card testing method resulted in considerable inconvenience for my colleague and his family. Do you think he’ll use that online service again? Do you think I will, now that he told me his story?
In the rush to get your novel application out the door or your slick Web site in front of the world, don’t forget all we’ve already learned about software engineering, human-computer interaction, and quality management. It could make the difference between enjoying a lucrative IPO and becoming a former employee of a defunct dot-com that had clever commercials, but crummy products.
About the Author
Karl Wiegers, Ph.D., is the Principal Consultant at Process Impact in Portland, Oregon, and the author of Software Requirements (Microsoft Press, 1999) and Creating a Software Engineering Culture (Dorset House, 1996). You can reach him at www.processimpact.com. You can find more than 35 of Karl's articles at www.processimpact.com/pubs.shtml
Back to Top
StickyMinds.com Weekly Column From 01/01/01
|
