Boxes and Arrows: Stories by Adam Greenfield

How to Architect Sites Across Cultures Without Losing Your Mind

Adam Greenfield — Mon, 11 Mar 2002 12:00:08 GMT

Ever since I started working formally as an information architect, somewhere back there in the antediluvian mists of 1999, I’ve clung to the belief that there’s a universal set of conditions that we’re trying to achieve in our work. These would be things like simplicity of structure and clarity in labeling: attributes that not only tend to further a user’s understanding of a given website, but also serve to enhance the web experience in general. But what I’ve slowly begun to believe over my time working here in Japan—and this verges on heresy for me—is that there is simply no such thing as a universal good.

What does “usability” or “clarity” mean in a culture like Japan? Have you ever ridden a Tokyo subway? If you have, I’m sure you’ll remember those ads, stuffed to the nonexistent margins with bright yellow copy against black backgrounds, sporting celebrity headshots, bikini girls, cute mascots and entire forests of exclamation points.

I know, I know. I was supposed to have absorbed “cultural relativism” and all that, along with the bad haircuts and ill-considered flings of college. Well, I’m here to tell you, it’s one thing to accept the truth of this in a dry, graduate anthropology seminar sort of way, and quite another to see it played out in real time, in the thrusts and parries of everyday client work. I got my first clue that I might be headed for a comeuppance on my very first project in Japan. The client, a book site much along the lines of Amazon.com, insisted on providing what they called a “hon no sommelier” function, or “book sommelier.” This was a tool that was supposed to solicit a few lifestyle preferences from site visitors, after which it would recommend a book they might like. Any conceptual problems with this idea aside, I pointed out that—in the States, anyway—only wine connoisseurs, foodies and restaurateurs were likely to be particularly familiar with the term “sommelier,” leading to a situation in which an unacceptable percentage of the user base quite simply would have no clue what that button up on the navigation bar was supposed to mean to them. Further, and again based on my American experience, my guess was that a healthy segment of those that were familiar with “sommelier” would regard it as a thoroughly pretentious way to describe what, after all, was a simple recommendation tool. I explained all this to the client’s representative, as patiently and objectively as I knew how, begging them to dispense with the idea. No dice. It was explained to me on more than one occasion, and with a fair amount of passion, that ever since the orgy of wine consumption the Japanese enjoyed in the Dionysian depths of the Bubble Economy, “everyone” knew what a sommelier was. Not only that, but that it would lend a “classy air” to the site. From that point on we agreed to disagree, sort of. I provided schematics that called out an “o-susume,” or recommendation, function; the client continued to refer to it as the “hon no sommelier.” There were other, far deeper problems with this site (some of which I’ve detailed in an article), and for a variety of reasons—only some of which had to do with matters of IA—my firm never completed the project. Eventually, it was subcontracted out to a production house that worked, apparently, without any IA input; the result is predictably turgid. In the end, I believe nobody won. By inflexibly holding the line on “best practices” regarding a label, and a few other similar disagreements, I contributed to a situation in which a site was built that shafts the hapless user far more thoroughly than any we might have created. The lesson here is really not a difficult one; it’s merely hard for a headstrong person like me to accept. And that is to slowly back out of the picture and do what I claim I’ve been all about from the beginning: listening to what the user wants. It so happens that, in the States, this is easy for me because “what the user wants” may mesh quite well with all those High Modernist values I hold dear. That is, there’s a happenstance overlap between the crisp grids and clearly articulated navigational schemas I personally like, and defensibly good usability practice for an American audience. But what does “usability” or “clarity” mean in a culture like Japan? Have you ever ridden a Tokyo subway? If you have, I’m sure you’ll remember those ads, stuffed to the nonexistent margins with bright yellow copy against black backgrounds, sporting celebrity headshots, bikini girls, cute mascots and entire forests of exclamation points (the one I’m thinking of is an ad for a news weekly). How about all the consumer goods, including more than a few otherwise high-end efforts, overprinted with nonsensical Japlish slogans and cartoon characters? Is it possible that in such an environment this is what your user expects, this is what your user is comfortable with—ultimately, this is what your user demands? Does it follow that, claiming as we do to be user-centric in our practice, this is what we should deliver to them? Well, yes and no. In some cases, it may well be that the claims I found so ludicrous—“It will lend an air of classiness to the site”—are actually better approximations to the real user’s mindset than any I am capable of offering. Maybe, in context, “sommelier” isn’t such a hard thing to swallow. In fact, this is what my Japanese superiors urged me to accept, in a slow and steady campaign aimed at securing my acquiescence. There may even have been one or two mornings, after absorbing this discourse, when I’d wake in a hungover daze of temporary agreement with them. Or not precisely with them, but with one of the few provocative, intellectually-coherent critiques of the practice of usability: that it encourages an incuriosity, a laziness, a bovine insistence on having everything placed within easy reach. And in fact, I would be surprised if the incredibly dense, saturated, wildly overcoded Japanese media environment hadn’t somehow conditioned the average citizen to exhibit improved pattern recognition skills, finer knowledge-seeking reflexes. But then I’d consult with Setsuko-san, and I’d see that all of this is beside the point. She’s a persona I developed for Japanese consumer sites: a 48-year-old housewife in Niigata Prefecture, thoroughly preoccupied with the debts incurred by her idiot son while away at college, and her very significant doubts about the wisdom of her only daughter dating an American Marine. Setsuko-san is my benchmark in these situations, and while she does not in any strict sense actually exist, I still take her feelings quite seriously. (You know those really annoying, sort of offensive born-again bumperstickers, the ones that say "My boss is a Jewish carpenter"? Well, same thing. My boss is a forty-eight-year-old housewife from Niigata.) Setsuko-san, like most of the Japanese people I know, has a busy life, one all but defined by its dense and complicated web of mutual obligations and responsibilities. She’s trying to hold a family together, trying to put some money away, trying not to worry too much about what happens during those long hours her husband is away. Are you going to tell me she has the time or patience to wrestle with the vagaries of a bloated car insurance site trickling down a dialup connection? I didn’t think so. So what did I learn from all this? What can we draw out of all of this and apply to our experiences architecting informational spaces for non-Western cultures? I learned about the limits of my own insight, and to be a little more careful about what I consider to be universals. As it turns out, there is a grain of truth in the idea that every audience is different and that this difference demands a variant construction of usability. You really can’t get too far out ahead of your users, not if you want them to accept, understand, and feel comfortable using what you’ve built. So, for example, if someone on your team has specified pseudo-technical labels like “i-Appli” and “L-Mode,” and the user base doesn’t seem to have a problem parsing them, let it go—even if you strain against it with most of the fibers of your being. But I also learned to respect my instincts: to trust the understanding I had built up through years of listening to the actual human beings who, for better or worse, use the things we build. This gave me the strength to press ahead when I was told “you can’t hit a home run every time”—meaning, don’t ask too much of us, both us-the-client, and, almost as frequently, us-the-account-management-team. Between these two lessons I’ve come to believe that you can safely let go of 90 percent of everything you think you know about IA, as long as you never once lose sight of your user. As long as your dedication to this person and their needs remains unswerving, as long as you’re truly organizing information to maximize their understanding, their ease of use, you will not go wrong, whether you’re working in SoMa, Sydney or Shibuya.

Adam Greenfield is currently Senior IA at Razorfish in Tokyo. By contrast, his v-2 Organisation is where he gets his groove on. That's where he talks about user-centered interface design, well-thought-out products, whatever remains of "digital culture," and the frantic ravings of dead French intellectuals.

What's in a Name? Or, What Exactly Do We Call Ourselves?

George Olsen, Adam Greenfield — Mon, 18 Mar 2002 12:00:16 GMT

Get us together for a cocktail hour, a conference or on a mailing list and the question inevitably arises: So what exactly do we call ourselves? And for every dozen people, there are probably two dozen opinions. Boxes and Arrows was no different. Defining our audience involved some discussion, and like the community-at-large, deciding what to call this audience sparked the most heated discussions.

Information Architecture is what we say it is
by Adam Greenfield

What is information architecture? We intend to sidestep, if not quash, this controversy by simply adopting the rubric “information architecture” for all the various activities we pursue. Or, put another way: IA is what we say it is.

Names are for tombstones, baby
by George Olsen

We keep arguing because “information architect” is a poor fit for what people are really doing. So I doubt we’ll see agreement on what to call ourselves any time soon. And that’s okay, as long as we realize we’re part of a community of distinct-but-related disciplines.

Information Architecture is what we say it is By Adam Greenfield Sometime toward the end of 2001, I was asked, along with the other members of the Boxes and Arrows marketing team, to craft a tagline that would simultaneously explain and promote this thing we were all building. Now, this is not a simple task. The labeling of things is always a difficult proposition, as you will surely and intimately understand if you work even briefly in the profession of information architecture. How do you tag something in such a way that people encountering the description will rapidly and intuitively understand the contents behind it? Succeeding in this is a matter of no small effort: the larger the disproportion between the size of the idea and the amount of words you are given to contain it in, the greater the subtlety required of the writer. And if labels are inherently problematic, still more so are their cousins: mottos and bywords and slogans. Human beings believe, whether consciously or not, in the incantatory power of these words, as if simply adopting a slogan like “order and progress” could magic the wilderness of an unruly frontier state into the wards and sectors of a republic. As if exhorting consumers to “fly the friendly skies” could mask the fact of being crammed like cattle into an aluminum tube six-and-a-half miles into the freezing air, to be spoon-fed microwaved pap by surly wardens. Well, none of that for me. The tagline of this publication should be “the journal of information architecture,” very simply because that is what it is. It is a journal—a written chronicle of the changes in a given field. And it’s devoted to the field we understand as information architecture. It’s not the perfect description, but it is the best. Oh, sure, there were other options mooted—alternatives that may have been catchier or sexier. In the end, though, there was a compelling logic in being exactly as crystalline in our self-description as in the practices we advocate. If we stand for anything as a community (and the point is infinitely debatable, but work with me here), it is clarity in the service of making the complex appropriately simple. It’s always a good thing to practice what one preaches, right? All well and good, but it still leaves one problem not addressed. This is an issue that will be familiar to anyone who's ever attended a gathering of people working in the field, whether a cocktail hour or a brownbag lunch or a roundtable discussion at one of the increasing number of professional conferences devoted to our practice. We call it (generally with a groan and a resigned, Charlie-Brownish smile) the “What is IA?” discussion. No matter what the stated agenda, it seems, some well-intentioned newcomer—and occasionally a knowing provocateur—invariably raises the question of the field's provenance. Is it traditional library science retrofitted and renamed for a digital age? Is it a subset of interaction design? Isn’t it just something that all good web designers do anyway, unconsciously? What's the difference between it and usability? How does it relate to “architecture architecture”? And what's an “XMOD,” anyway? What is information architecture? We intend to sidestep, if not quash, this controversy by simply adopting the rubric “information architecture” for all the various activities we pursue. Or, put another way: IA is what we say it is. This may strike some as arrogant, but it has an appealing logic and (again) simplicity: If, as we hope and intend, Boxes and Arrows becomes the voice and the forum of the community’s foremost practitioners, how can it be otherwise? The practice evolves along with the understanding of those who define it through their work. (People in this community being more than usually attuned to nuances in naming, however, there will be differences in opinion. Believe me, we’ll hear about this.) My own guess is that the definition, as it evolves, will tend towards the inclusive. The practice of sound information architecture has always asked of us that we remain attuned to ideas from the worlds of software engineering and anthropology, ergonomics and, yes, marketing. And I hope this will continue to be the case. So it's a little tautological maybe: but if it’s IA, you’ll find it in Boxes and Arrows. We hope that you find this journal of information architecture useful—that it will turn out to be engaging, inspiring, provocative, strongly supportive of your efforts. Who knows, maybe you'll even enjoy it. Now wouldn't that be something? Names are for tombstones, baby by George Olsen Why do we keep arguing over the definition of “information architecture,” broad, narrow, big, little, West Coast, Polar Bear, or other? Maybe it’s because we’re a profession that, among other things, focuses on classification and categorization. But, arguably, it means “information architect” is a poor fit for what people are really doing. When you look at the working world, you find that people go by many titles—information architect is just one—and those titles get defined in completely different ways. This confusion over titles and industry jargon is nothing new. During the CD-ROM-based “new media” era of the early 1990s, one industry pundit seriously purposed writing a translator’s phrase book between the various new media camps that evolved from the fields of software development, book/magazine publishing and the entertainment industry. Among the questions was what to call the person leading the “creative” effort: project manager, creative director, producer, etc. Sound familiar? Likewise, the term “information architect,” came of life during the creation of another new industry that involved the convergence of several older fields. This was largely as a result of a meme appearing at the right place at the right time—namely Louis Rosenfeld and Peter Morville’s landmark “Information Architecture for the World Wide Web” (widely known as the “Polar Bear book” for its cover). Rosenfeld has since acknowledged he and Morville adopted the term “because few, if any, would hire librarians to consult on the design of their sites.” And in practice, the term became stretched into a useful, strategically-vague umbrella for people doing a variety of multi-disciplinary things. So it’s time to look beyond job titles and see what ties together our community in terms of common goals, methods, issues and approaches. Because there is a common community “somewhere between the wide open spaces of experience design (everything from sniffomatics to amusement parks) and the narrow land of thesauri,” as Christina Wodtke puts it. The common thread I’ve taken to calling this community of practices “I4” and “I-stuff,” as a working title that’s admittedly jargon, but free of historical and political baggage, and describes a community of practice with four disciplines as its center of gravity:

(content) information architecture (also known as the Polar Bear IAs)
interaction design
information design (in the broad sense of information-focused publication design, in addition to its narrower definition of creating maps, charts and diagrams)
(user) interface design

Why those four? For starters, if you look at attempted definitions based on what we do (taken from AIGA Experience Design’s attempt to describe some of the roles we see in the field), you’ll see substantial overlap between “broad” IAs and interaction designers. And there are other similarities. To oversimplify drastically, one of the common threads is a focus on structure:

Information architects are concerned about the structure of content. Information designers are concerned about structuring visual presentation of the content.
Interaction designers are concerned about the structure of the behavior. Interface designers are concerned about structuring visual presentation of the behavior.

In some ways, information architecture and interaction design are the “hidden skeleton,” complemented by information design and interface as the “visible skin.” Just as in the human body, both skeleton and skin are necessary, otherwise you end up with unpleasant results… But going deeper, these four disciplines share common outlooks and common approaches—for example, a card sorting exercise can be used to help inform information architecture, interface design, and interaction design (and probably information design, but I’ve never explored that). Intersecting and informing Slightly further out from this core are content strategists/writers (remember them?) and graphic designers (although it would be better to talk about them as sensory designers to capture the full range of still graphics, motion graphics, audio and video that can be used). While writers and designers may be concerned about structure (and this is an area where our disciplines have traditionally underestimated graphic design), both also are concerned with the style and tone of the content itself and of its presentation. As Mark Twain said, the difference between the right word and the almost right word is the difference between lightning and the lightning bug—and good writers and graphic designers are acutely aware of this. Both writers and designers may sometimes (rightfully) accuse all four “I” disciplines of paying insufficient attention to form—and dare I say it—style. Style counts, and even if gurus of utilitarian usability are blind to it, the general public isn’t. This was strikingly illustrated in some recent usability testing with which I was involved when users spontaneously commented that the site’s design (what graphic designers would call an extremely “clean” design) made them think the site was easy to use—even if they actually had trouble finding things. So writers and designers, drawing from their own established disciplines, have much to offer I4 in finding the appropriate balance between content, behavior and form that’s needed for success. Ideally, all six of these disciplines share a user-focused approach—but “user-centered design” is a viewpoint, not a discipline. And, in fact, all six fields have countercurrents of a “vision-based” approach—no one asked for the Sony Walkman, Napster, or the internet itself, yet each has done extremely well, so presumably they fulfilled a need. (These countercurrents tend to be stronger in the case of graphic design and writing, since their concern with form can edge into style.) It is entirely possible to do information architecture, interaction design, information design or interface design without considering users—just look around at the numerous bad sites and products that exist. Likewise, it's also possible to do all of these without testing your design. But, in the best of worlds:

User researchers, inform all these disciplines, but are a bit further from the core for the reasons just described.
Usability testing reality-checks all of these disciplines, but likewise is also a bit further from the core.

(Note: I want to make it clear that I’m referring just to usability-as-critique, since the term “usability professional” is also having problems with multiple meanings—it can mean someone who’s strictly a usability tester, be used as a synonym for user-centered design approaches, or used in the sense of usability engineering, which bears a strong resemble to broad IA.) User research without implementation by one or more of the four “I” disciplines remains just a pile of interesting observations. Usability testing without the vision provided by one or more of the four "I" disciplines will keep plaintively asking, “Does it work?” So we end up with four “core” disciplines—(content) information architecture, information design, interaction design and interface design, ringed by four disciplines that are somewhat further from the core—graphic/sensory design, content strategy/writing, user research, and usability, which interact with and inform I4. Stepping back further from the core, there are a number of surrounding disciplines—including brand strategy, business strategy, software engineering, industrial design and architecture, library sciences—that are separate, but share some of the same concerns or have an effect on the “core” disciplines. A shared milieu Put together, I4 plus the four closely-related disciplines are among the key disciplines involved in “user experience”—whatever you want to call someone’s experience with the “front end” of a website or software. And realistically, websites and to lesser extent software, PDAs and wireless—are what the vast majority of us are working on. For lack of a better term, call it the “digital milieu,” and it’s another center of gravity. It’s an important difference, since we don’t design theme park rides or airplane cockpits. It’s not an absolute difference, since our skills and viewpoints blur into print and industrial design (to name just two fields). And some of the most interesting work right now involves integrating experiences in digital space and physical space. But the people having discussions over “user experience” aren’t industrial designers, building architects or perfume designers. They’re us. So what do we call ourselves? Currently, I’m not sure we can come up with a single title that encompasses all of I4. I’ve argued elsewhere the need for a “user experience architect/designer” who takes a holistic approach to crafting all aspects of the experience people have when they interact with what we build. But that’s a larger role, similar to a creative director in graphic design, than that of I4. If your focus is narrow, it’s pretty easy to match a title to a role—you’re an interaction designer or an information designer. But for those who typically do two or more of the I4, it makes for some unwieldy job titles. Depending on what industry you come from, there are often titles that get stretched to fill these new roles. So I doubt we’ll see agreement on what to call ourselves any time soon. And that’s okay, as long as we realize we’re we share a set of distinct-but-related disciplines—which I’d argue are part of the larger field of “user experience.” After all, other broad-based fields tie together related disciplines. The “programming” field encompasses systems analysts, database administrators and network architects even though they do very different things. The “graphic design” profession includes those ranging from corporate identity designers, to packaging designers, to typographers. But what ties them together is that practitioners in each of these fields share some common outlooks and education (“computer science” or “graphic design,” respectively). Likewise, we’re a community of practice with similarities in outlook and approach that far outweigh our differences. Maybe we’ll find a term for I4 that everyone is happy with, maybe we won’t. But the things we do will still tie us together.

Adam Greenfield is currently Senior IA at Razorfish in Tokyo. By contrast, his v-2 Organisation is where he gets his groove on. That’s where he talks about user-centered interface design, well-thought-out products, whatever remains of “digital culture,” and the frantic ravings of dead French intellectuals. George Olsen, is principal of Interaction by Design. He has done award-winning work for a variety of companies, from dotcom start-ups, to Hollywood studios, such as Disney, to Fortune 500 companies, including Nestle and Transamerica. He’s taught at UCLA Extension, and written about and spoken at numerous conferences about user experience design issues.

All watched over by machines of loving grace: Some ethical guidelines for user experience in ubiquitous-computing settings [1]

Adam Greenfield — Wed, 01 Dec 2004 10:51:14 GMT

“If ubicomp applications are rushed to market and allowed to appear as have so many technological artifacts in the last thirty years, then they will present those users with a truly unprecedented level of badness.”

Note: It can be difficult, initially, to consider ubiquitous-computing environments as a special case for user experience work. Before they are knit together, the elements constituting ubiquitous systems may appear to be merely conventional technological devices, with relatively well-documented interfaces and affordances. It is only as they join and fuse that the emergent properties we think of as “ubicomp” come to the fore. It can be equally imprecise to speak of “users,” in a context where a human being encountering ubiquitous information-processing technology may more accurately be considered as a subject. Nevertheless, I have used the term throughout, as it is established and widely understood.

Ubiquitous computing is coming. It is coming because there are too many too powerful institutions vested in its coming; it is coming because it is a “technically sweet” challenge; it is coming because it represents the eventual convergence of devices, tools and services that became inevitable the moment they each began to be expressed in ones and zeroes. It is a future structurally latent in the new schema for Internet Protocol addressing, IPv6, which, with its 128-bit address space, provides some 6.5 x 10²³ addresses for every square meter on the surface of our planet, and therefore quite abundantly enough for every pen and stamp and book and door in the world to talk to each other. And of course it is a future economically latent in the need of manufacturers and marketers for continuous growth, and the identification of vast new markets beyond the desktop, laptop, personal audio player and mobile phone. The slow fusion of our mobile phone and wireless broadband networks, the accelerating miniaturization and vastly reduced cost of RFID chips, the increasing ease with which circuits can be printed or embedded in wearable, even disposable items, improved techniques in ambient information display, the aging of society and corresponding necessity for outboard memory augmentation, even factors like public fear and the ostensible prerogatives of security in the post-September 11th era (“reduce the public sphere, restrict access, and limit unmonitored activity”² ) all imply that ubicomp will play an increasingly prominent role in our lives, technically, socially and psychologically. Despite our best efforts—which is to say, the best efforts of a great many sensitive and intelligent people working in good faith, over the course of a decade and in every country where access to the Internet is commonplace—even ordinary operations in such a comparatively simple regime as the World Wide Web still all too often present users with unacceptable difficulty, confusion and uncertainty. Moments of perplexity and doubt remain, strewn through even the most quotidian tasks like landmines among the fields. The Web works, but rarely as effortlessly or in a manner as free from undue complication as we might wish. By comparison with the World Wide Web, ubiquitous computing is vastly more insinuative. By intention and design, it asserts itself in every moment and through every aperture contemporary life affords it³. It is everyware. The prospect of such moments of disjunction and dismay being allowed to persist in the enormously more powerful, pervasive and intimate milieu of ubicomp, percolating through even to realms of existence not previously considered as subject to operations through an “interface”—and especially in contexts where users' governing mental models are likely to be social and interpersonal⁴ in nature rather than technical—is still more unacceptable. (This is most especially so in the absence of compelling and clearly articulated value propositions for ubiquitous systems from the user's point of view.)

Social engineering/society by engineers

It should be clear that ubicomp represents a substantial raising of stakes over the Web case, the PDA case, the mobile-phone case, or other scenarios we're accustomed to; that its field of operation is by definition total; and that its potential for harm if poorly implemented is such that the user experience is too important to leave to chance, or the discretion of developers. My sense is that the challenge of ubiquitous computing for user-experience professionals resides fundamentally in two places: in the regrettable quality of interaction typically manifested by complex digital products and services designed without some degree of qualified UX intervention, and in the ease with which ubiquitous systems can overwhelm or render meaningless the prerogatives of privacy, self-determination and choice that have traditionally informed our understanding of civil liberty. We can all readily encompass the danger of the first situation. With all due respect, we have seen that products designed by engineers, or whose design is permitted to default to the tastes, preferences and predilections of engineers, almost always fail end users (unless those end users are themselves engineers). This is not an indictment of engineers. They are given a narrow technical brief, and within the envelope available to them they return solutions. It is not in their mandate to consider the social and environmental impact of their work. From our vantage point as user-experience professionals, however, it is clear that there have always been emergent properties of systems that are designed with a given end in mind - and that sometimes, those properties and effects are of much greater consequence than the intended result. If ubicomp applications are rushed to market and allowed to appear as have so many technological artifacts in the last thirty years—i.e., without compassionate attention to the needs and abilities of all sorts of human users, without many painstaking rounds of iterative testing and improvement in realistic settings—then they will present those users with a truly unprecedented level of badness. Imagine the feeling of being stuck in voice-mail limbo, or fighting unwanted auto-formatting in a word processing program, or trying to quickly silence an unexpectedly ringing phone by touch, amid the hissing of fellow moviegoers—except all the time, and everywhere, and in the most intimate circumstances of our lives. Levels of discomfort we accept as routine (even, despite everything we know, inevitable!) in the reasonably delimited scenarios presented by our other artifacts will have redoubled impact in a ubicomp world. Even if for this reason alone, we must ensure that this class of products and services is designed better, with more sensitivity and compassion, than others in the past. It is, however, the impact of ubicomp on civil liberty that I am most concerned with. While the quality of ubiquitous interaction is more squarely within the typical ambit of our professional concerns, it is the civic sphere where our input and perspective is most critical and can be leveraged to secure the most enduring and important gains. Ubiquitous systems lend themselves easily to—indeed, redefine—surveillance. However discrete they may be at their design and inception, their interface with each other implies a domain of action that extends from the very contours of the human body outward to whatever arbitrarily large civic space can be equipped with the necessary sensors and effectors. In short, there is no current technology with greater potential to support authoritarian and totalitarian social engineering, and the limitation otherwise of choice. This will not always be a matter of imposition: it should be pointed out that some of us, perhaps even a majority, will want and strongly prefer such systems when they become available. As I have noted previously, critics tend to react negatively to the prospect of panoptical surveillance, “but what those who do so generally fail to understand is that many, many people like the idea that they’re always being watched, because they equate that watching with always being cared for...if the most accepted model for pervasive devices to date has been the Assistant, we should never forget that a competing model—one that holds strong appeal for a great many people—is the Superintendent.” In the contemplated introduction of any system with so much inherent potential for oppression, it is clearly incumbent upon its designers to provide reasonable assurances for the maintenance or extension of human freedom, agency and autonomy.

Why us, why now?

With our orientation toward, and intense dedication to improving, the quality of interaction experienced by users of the World Wide Web (and technical systems of all sorts), we in the user-experience community are uniquely positioned to affect the emergence of this technological milieu for the better. With our advocacy on behalf of a party otherwise under- or unrepresented in the development process—the human being(s) using the product or service at hand—we bring a certain grounding clarity to the proceedings. With our insights concerning the optimal order, sequence, priority, and rate of information presented to the user, we have frequently allowed a successful business case to be asserted where there was none before. We may even, if we are particularly lucky, be able to bring aesthetic sense and discretion to the projects on which we are engaged. It is my sense that the time is apt for us to begin articulating some baseline standards for the ethical and responsible development of user-facing provisions in ubicomp applications, before our lives are blanketed with the poorly-imagined interfaces, infuriating loops of illogic, and insults to our autonomy that have characterized entirely too much human-machine interaction to date. None of the following should be understood to arrogate to ourselves the role of sole guardian of the user's interests, or to overlook the foundational work already done in the human-computer interaction community. These guidelines are intended for working information architects, usability specialists and user-experience designers, and address situations from their perspective.

Principles

The intent of this section is to enunciate some general principles for us to observe, as designers and developers for ubiquitous systems, whereby the ethical and social prerogatives of our “users” can be preserved. The most essential and the hardest to express with any rigor, which we might call principle 0, is, of course, first, do no harm: if we could all be relied upon to take this simple idea to heart, thoughtfully and with compassion, there would be very little need to enunciate any of the following. Given the difficulties of deriving practically useful guidance from such bywords, however, let us enunciate a further five guidelines that should go some way toward illuminating the challenges we face in designing useful, humane instantiations of ubicomp:

Principle 1. Default to harmlessness. Ubiquitous systems must default to a mode that ensures their users' (physical, psychic and financial) safety.
We are familiar with the notion of “graceful degradation,” the ideal that if a system fails, if at all possible it should fail gently in preference to catastrophically, with functionality being lost progressively rather than all at once.
Given the assumption of responsibility for users and their environments implied by the ubicomp rubric, such systems must take measures that go well beyond mere graceful degradation.
Slaved passenger vehicles, dosage settings for pharmaceutical-delivery systems, controls for sealed or denied environments are examples of situations where redundant interlocks must be provided to ensure user safety.
Principle 2. Be self-disclosing. Ubiquitous systems must contain provisions for immediate and transparent querying of their ownership, use, capabilities, etc., such that human beings encountering them are empowered to make informed decisions regarding exposure to same.
Some analogue of broadcast station identification conventions, or perhaps of the Identification Friend or Foe (IFF) standards by which military systems identify themselves to each other, would be necessary.
“Seamlessness” must be an optional mode of presentation, not a mandatory or inescapable one: both the interfaces through which information is passed between adjacent systems, and the actual data that is so communicated, must be equally capable of self-revelation.
Ubiquitous systems, by definition, cannot help but gather information constantly, including arbitrarily granular location of users in four-dimensional spacetime. It would be unreasonable and unrealistic to assert a Web-derived model for user consent to such ongoing information-garnering activities in the ubicomp context: the scenario would be one of constant, exasperating interruption to task flow, as the user was asked to give explicit consent to the transmission of each momentary state. Given this, some provision for at least determining who owns a given system, and what will be done with information so revealed, is necessary.
Principle 3. Be conservative of face. Ubiquitous systems are always already social systems, and must contain provisions such that wherever possible they not unnecessarily embarrass, humiliate, or shame their users.
Consider this brief vignette, from Thomas Disch's legendary 1974 novel 334:
“"Arnold Chapel," a voice over the PA said. "Please return along 'K' corridor to 'K' elevator bank. Arnold Chapel, please return along 'K' corridor to 'K' elevator bank."
“Obediently he reversed the cart and returned to 'K' elevator bank. His identification badge had cued the traffic control system. It had been years since the computer had had to correct him out loud.”
While Disch undoubtedly deserves credit for having so vividly imagined ubicomp avant le lettre, some twenty years ahead even of Mark Weiser, is there any reason why the system's correction need be perceptible to anyone but Chapel himself? Why humiliate, when adjustment is all that is mandated?
This goes beyond formal information-privacy concerns, toward the instinctual recognition that no human society can survive the total evaporation of its protective hypocrisy. Some degree of “plausible deniability,” including above all imprecision of location, is probably necessary to the psychic health of a given community, such that even (natural or machine-assisted) inferences about intention and conduct may be forestalled at the subject's will. Still worse than the prospect of being nakedly accountable to an unseen, omnipresent “network” is being nakedly accountable to each other, at all times and places.
At the absolute minimum, and in accordance with Principle 2, ubiquitous systems with surveillant capacity must announce themselves as such, in such a way that their field of operation may be effectively evaded.
Principle 4. Be conservative of time. Ubiquitous systems must not introduce undue complications into ordinary operations.
If they impact such operations, they must be at least as transparent to users as the pre-existing equivalent: that is, one should be able to sit in a chair, place a book upon a shelf, boil a kettle of water without being asked if one “really” wants to do so, or having fine-grained control wrested away. In the absence of other information, the default assumption must be that an adult, competent user knows and understands what they want to achieve and has accurately expressed that desire in their commands to the system⁵.
By the same token, a universal undo convention similar to the keyboard sequence “Ctrl Z” should be afforded; “save states” or the equivalent must be rolling, continuous and persistently accessible in a graceful and intuitive manner. If a user wants to undo, or return to an earlier stage in an articulated process, they should be able to specify, e.g., how many steps or minutes' progress they would like to efface. (“Make it like it was two or three minutes ago!”)
Principle 5. Be deniable. Ubiquitous systems must offer users the ability to opt out, always and at any point.
As an absolute ethical imperative, users must be afforded the ability to make their own meaningful decisions regarding their exposure to ubiquitous perception, the types and channels of information such exposure will necessary convey, and the agencies receiving and capable of acting on such conveyance.
Critical to this is the ability to simply say “no,” with no penalty other than the inability to make use of whatever benefits the ubiquitous system offers its users. (The “safe word” concept may find an novel and unforeseen application here.)

Conclusion

These recommendations, clearly, are not comprehensive⁶: They are certainly capable of being gamed, of being exploited by individuals determined to gain unfair advantage. They depend vitally for their effectiveness on voluntary compliance. They will necessarily involve compromises, conflicts, tensions and trade-offs. When were things ever otherwise? But if thoughtfully and consistently implemented, it is my strong belief that they will go a long way toward improving the baseline experience for the human users and subjects of ubiquitous systems, and therefore rendering such systems acceptable for widespread implementation. This, above all, is not a place for “service packs”; if ever there were a situation to compel the devotion of our full professional attention and compassionate effort to the individual human subject of technological intervention when it could still make a difference, this is it.⁷

For More Information

Privacy by design: Principles of privacy-aware ubiquitous systems (PDF)
http://www.vs.inf.ethz.ch/publ/papers/privacy-principles.pdf
Information privacy in ubiquitous computing
http://guir.berkeley.edu/groups/privacy/
Ant club trails: Privacy in ubiquitous computer world
http://www.citris-uc.org/projmatrix/project/display.action?project.id=92
Berkeley Institute of Design
http://bid.berkeley.edu/
Equator
http://machen.mrl.nott.ac.uk/home.html
“Always-on panopticon...or cooperation amplifier?” chapter of “Smart Mobs”
http://www.smartmobs.com/book/toc_8.html
Seamful ubiquity
http://www.usabilityviews.com/uv002492.html
The Panopticon
http://cartome.org/panopticon1.htm
http://users.rcn.com/mackey/thesis/panopticon.html

End Notes

The reference is to Richard Brautigan's bad, but perfectly illustrative, 1967 poem of the same name.
T. Riley and G. Nordenson, curatorial notes for the exhibit “Tall Buildings,” Museum of Modern Art (MoMA QNS), 2004
It is worth preserving here the distinction between discrete, situated systems and literally ubiquitous ones. (I'm grateful to Joe McCarthy for underlining this point.) However, my concern is with how such systems will be perceived by those people encountering them, and I have little doubt that users will fail to distinguish between one delimited, voice-accessed system and another, especially if those systems share (e.g.) CRM information.
For a thorough description of the ways in which user mental models for their interactions with machines are heavily patterned on rules governing social interaction, see B. Reeves and C. Nass, “The Media Equation,” CSLI Publications, 1996
The potential conflict with Principle 1 is obvious, and remains to be resolved: should ubiquitous systems permit their users to choose options harmful to themselves? Answering the question to anyone's satisfaction will require both experience with the domain and a sensitivity to the specific context, against the background of an evolving jurisprudence of ubiquitous interaction.
A sense for the degree to which these recommendations only scratch the surface can be gained by reading Roger Clarke's commentary on Isaac Asimov's “Laws of Robotics,” particularly its section on the structuredness of decision making.
I am deeply grateful to Anne Galloway, Howard Rheingold, Nurri Kim, and Joe McCarthy for insights and commentary crucial to my formulation of this article. Any errors in fact, understanding or emphasis are of course my own.

Adam Greenfield is an internationally recognized information architect, user experience consultant, and writer, with extensive experience devising site architectures for clients ranging from Fortune Global 500 enterprises Toyota, Amgen, Sony, and Nippon Express to local nonprofits. His practice is focused on making complex artifacts easy to understand and use, without sacrificing thoroughness or depth.