Thanks to networked time servers, I only change one clock when daylight savings rolls around: the one in the car. Changing car stereo clocks usually works one of two ways; each one presents the human interactor with a different kind of challenge.
The “Find a Pushpin” model (FP, for short) requires the human to locate a pushpin or other narrow object with which to depress small, recessed buttons marked “H” and “M” (for reasons unrelated to my favorite place to buy clothes). We might think of the problem the FP model presents as requiring a primarily physical solution, insofar as we consider the buttons’ labels instantly intelligible to a human looking to change the displayed time.
The alternative model requires the human to determine a precise combination of holds and presses to apply to readily fingerable buttons. This model, which I’ll call the “Finish Him!” model (FH!), after Mortal Kombat match’s daunting final button-press sequences, presents a problem requiring a primarily cognitive solution, insofar as most humans in the target group come equipped with the requisite physical equipment.
In designing interactions for the Web, we don’t usually have the choice between physical and cognitive solutions. However, we do have the capacity to provide multiple physical mechanisms for accomplishing the same task, allowing for a similar increase in convenience for this or that group of users.
For example, Google Labs has an experiment that allows one to use keyboard shortcuts to move from entry to entry on a Google search results page. The result: Having just typed in a search query, I needn’t move my hands from the keyboard in order to find and open my preferred result. For a certain group of users (the Japanese of the “Google user” set, perhaps), this method—not pointing and clicking—will provide the greatest convenience.
Even limiting ourselves to a single physical mechanism (e.g., the mouse or trackpad), we can often provide multiple points of cognitive interaction with a particular kind of content. Most commonly, we tend to want to provide searchers with a reliable, easy-to-use search function and browsers with a clean, functional navigation.
Other, more complex examples still focus on the human user at the other end of the line. Syndication of a site’s content allows a certain set of users more control over the times and mechanisms of their interaction with that content. Likewise, the prevalence of the API for web services reflects the growing desire of a certain set of users to create their own points of interaction with the service.
Anecdotally, it has seemed to me that American cars favor FP, while Japanese cars favor FH!. (I can’t speak to German or Korean tastes.) This comes as no surprise; Japanese culture’s greater engagement with technological gadgets likely leads designers to think that the most convenient solution will be the one that requires a few moments of cogitation, rather than an open-ended search for a kind of object one isn’t likely to keep in one’s car.
In the States, though, our impatience with two-handed interactions with technology—an impatience that makes the iPhone wildly popular here but a dud in Japan—means that the greatest convenience will lie with a quick search for something small and pointy. Also, as a whole, we probably keep our cars a little messier over here.
These are generalizations of the broadest kind, but that’s how culture works: It makes generalizations true, mostly by seducing or tricking its members. (Maybe this works differently outside free-market capitalism.) And really, the automakers only can address their users on these levels: as humans, first, and, most narrowly, as members of a culture with demonstrable preferences and habits.
We in the Web often have an advantage over the automakers, in this respect. We produce sites and services specialized enough to allow us, through conjecture and research, to identify with some accuracy the salient characteristics and preferences of our user groups.
In the U.S., that is, the set of humans who have cars is impossibly diverse. Not so for set of humans who might visit, say, a regionally successful business school’s website, or the online banking section of a consumer lender. (Not so, also, for the set of humans who have luxury cars, one overlooked reason that so many interface enhancements happen in those vehicles first. [That is, it’s not just about money…])
To make the most of this advantage requires solid research of the kind I’m sure all automakers do. Happily, many of our clients have already hired firms with serious expertise in these areas. However, this is no excuse to treat our armchair speculations about the user base as gospel. Instead, we have to reconcile our intuitions about who these users are and what they want with a serious look at any research we’ve been given or can find or can create ourselves.
With great power (relative to the automakers) for knowledge of our users comes great responsibility. User groups are unruly, surprising things, to which we are, nonetheless, beholden. It’s up to us to respond to them as they exist, not as we’d prefer them to be (at worst, for selfish or idiosyncratic or idealistic reasons).