Do as I do, not as I say
Editor's note: Steve Ellis and Pamela Ellis are partners at Change Sciences Group, an Irvington, N.Y., consulting firm.
Discovering what online customers want is hard enough. What about finding out about what online customers actually do? What customers want is surely important. Not knowing about what they do and why can break even the strongest business model.
There is no shortage of customer-oriented frameworks available to those considering sharpening their customer focus. We've got traditional market research with surveys and focus groups. There is the emerging field of Web analytics and CRM with a host of new data mining tools for analyzing clickstream data. There is even Web-based software that pretends to test the usability of a Web site by emulating the supposed actions of the site's users - users that, like a well-written piece of software code, will always find the shortest distance between two points.
What marketers frequently lack is an understanding of what real customers are doing and why they do it. We may need look no further for an explanation than the emotions evoked when we encounter the real presence of the unwashed customer actually using our products. Nothing gets more groans from a development team than watching user after user miss the add-to-cart button, or articulate more clearly than anyone dreamed possible exactly why a costly feature has no value.
The subtleties of observation
New technologies tantalize us with the potential for new customer insights. Although the verdict is still out on whether the benefits of Web analytics and CRM systems outweigh their high costs, they show promise for determining ROI on ad dollars, as well as offer some improvement to traditional Web server log file analysis. What is often missed is that these systems provide only an aggregate view of behavior. They say little about why people haven't done what they were expected to do, or what we didn't think to ask. They don't tell us about the subtleties of what did or did not work.
It is the subtleties that should interest us most these days. The Web has no standards for how a user's experience should be structured. Beyond the four most common form elements - the text entry area, the drop down, the checkbox and the radio button - all bets are off. This is part of the charm of the Web, but it also leads to subtle problems that can have big consequences for the customer experience, and the bottom line.
There's no better way to uncover these problems than to sit down and observe customers as they use the Web. To be distinguished from automated "customer tracking," this type of research is about learning from real people, face to face. Learning to listen to customers as they use our products can have a cumulative benefit as well. Assumptions about human behavior begin to break down. Sometimes it startles us just how subtle these assumptions can be.
The myth of the non tech-savvy user
Designers will often simplify an interface in an attempt to reach a wider, "less technical" market. A number of recent Internet appliance products have taken this approach, hoping to reach people who haven't yet adopted PC access to the Web. The tactic can succeed under some circumstances, but it can also backfire. When we went to ask a group of young women how they might use a new Internet appliance, they couldn't see themselves using it. On the other hand they were sure older people might like it. When we spoke with a group of older people, they were cool to the product's approach. They didn't require anything to be "dumbed down" for them! They did suggest that younger people might appreciate the cute aesthetics of the product.
Simplification is not always the way to bring in less sophisticated Web users. Instead, designers might take more time to learn about who the less tech-savvy users are that they are trying to reach. "Less tech-savvy" is not exactly a valid description of a full-fledged human being. Looking deep into the context of a specific "less savvy user" would be a good start.
Fewer clicks are not always better
Minimizing the number of clicks it takes users to get to where they need to go is an accepted principle of Web design, as it should be. But lately it seems to have been taken a little too far. Pages with three, four, and five columns are now the norm. Pages have navigation on the top and navigation on the side. The middle of any given page may have as many as 10 or more links.
Few people react to pages like this as we expect them to. They don't read all of their options from the top, to the left, and to the middle and then down the page, carefully noting the relevance of each as it is presented. They don't have the patience or the inclination. Instead they skip around and miss important pieces because they are distracted by other pieces. In a recent test of a large commercial Web site, person after person displayed an odd blindness to the presence of the left navigation bar when asked to complete a task by choosing an option on it, even though the bar followed most of the conventions of left navigation that many users are used to. They just simply missed it, over and over again. A big contributing factor was that each page had dozens of options, all in an effort to improve usability by reducing the number of clicks.
Whose process is it?
A corollary of the "too many clicks" problem is the problem of process. Whose process is it? Is it the company's, the marketer's, the programmer's, or the customer's process?
For example, a number of Web applications that interface with devices like MP3 players or PDAs require a second application to interact with that device. Since these applications require functionality beyond Internet Explorer or Netscape, programmers will build so-called "helper apps" using the Windows user interface. The problem is that once these helper apps pop up, people often don't know what to do with them. It's not that they don't know how to use Windows. It's that they were on the Web and suddenly they are thrust into the Windows world and expected to make the transition. Often, they don't, and are left to consider what exactly this intruder has just popped up to do.
Another example: problems with company-oriented process go beyond the Web site that's been organized according to the structure of the company's departments or divisions (which is, of course, usually a bad idea as well). Company-oriented process can be far subtler and harder to detect. Take for example the use of the word "beneficiary" on many online banking sites. To many ordinary users of banks, the term connotes "the person who gets your money after you die," not the recipient of a wire transfer. The interface might just simply ask, "Where do you want to transfer money?" instead of introducing confusion by adding the troubling term.
Embracing the familiar
Metaphors are everywhere in information technology. We have the "desktop" and the "Web page." Metaphors are touchstones that orient us, providing a ready-made context where there was none. Web applications use metaphors all the time. Entire applications are wrapped within them. When Web-based e-mail programs began to appear, the inbox and outbox motifs were carried over from software (and from physical office spaces before that), helping to make the new idea of getting e-mail on the Web seem routine.
Metaphors are powerful framing mechanisms, and choosing the wrong metaphor or making seemingly inapt comparisons can foil even the best-laid plans. Many Web applications are designed to make searching easier and provide more relevant results. When speaking with one such company recently we were told again and again by designers that their product was "better than a search engine." Its technology provided far superior indexing of products relevant to the field. And it did. This notion of "better than a search engine" was incorporated into its marketing literature. Salespeople touted its "better than a search engine" qualities to potential customers. The assumption was that people were by now used to using a search engine and getting a flood of irrelevant results.
When we tested a prototype of the product in the field a curious thing happened. And it happened over and over again. No matter how many times we explained that the product used a special indexing technique unavailable anywhere else, people kept adding: "Yes, that's great, but I can still get more information on the Web," the perception being that the Web would always have more (and better) information. The phrase "better than a search engine" just wasn't working. Reframing the product as a search engine for professionals short-circuited the problem. The fact that it produced better results would declare itself by example.
Why we're lucky log files don't talk
Figuring out who users are, what they do, and what metaphors work for them are challenges every Web team faces. Web analytics and CRM are only one element in a comprehensive customer experience strategy. By talking to real customers and watching them interact with products can we begin to form an understanding of why things aren't working (and how they might work better). Logs don't talk. Luckily people do.
Perhaps someday our interface technologies will be so simple and transparent there won't be a need to bring the humble user into the process. Development teams will rest assured that their works are truly works of genius, without getting muddled in the reactions of other humans. Futurists will declare that computers have finally realized their true purpose, to serve us, rather than the other way around.
For now we're stuck with trying to understand the messy subtleties of human-machine communication. At least that's one way to look at it. Here's another: Maybe for the first time it's becoming really necessary to look at, listen, and learn from our fellow humans when we design information systems.