Taxonomies follow some physical, ecological principles, even though they’re semantic. In an insight that echoes J. J. Gibson, Lambe explains how people usually start with “basic-level categories” that are not “the most granular, atomistic elements in our world. They tend to be whole objects we can identify and act upon in a direct way. Linguistically, we have shorter and simpler names for them compared to other objects, and they tend to be accessible things that populate our everyday world.”[400]
We begin with things such as “apple” and “clock.” We then work our way out and up to larger, broader categories (fruit, orchard, harvest, timepiece, engineering) or inward and down to smaller bits (tyrosinase enzyme, fructose, molecule, pinion, spring, atomic structure of brass). This pattern we have with language correlates with the way we perceive physical information: at the body-relevant level first, and then working our way beyond that level to the broadest canopy around us and down to tiny objects—attention that we augment with telescopes and microscopes.
When we navigate an environment, we pay attention first to the objects that are most relevant to our needs as well as our bodies, even when considering semantic information. When I visit a hospital or other building with medical offices, I need to figure out which office has the doctor I want to see. Hopefully, I find a directory of some sort in the lobby, where I can find my doctor’s name and office number. I’m not interested in learning the entire building, and I’m not interested in how my doctor is related to all the others. Likewise, I don’t care just yet what rooms are inside my doctor’s suite—I won’t worry about that until I’m in the waiting room. We treat all sorts of environments this way, from websites and cable TV guides to subways and cities.
Taxonomies can help us translate between different perspectives—serving as a Rosetta stone between cultural umwelts. For example, in an effort to help scientists better explain climate change, some have been creating guides to improving the way scientists translate the language of theory to the language of laypeople, as shown in Figure 20-6.
Figure 20-6. A table of terms and their public meanings, with recommendations for more accurate communication of the intended meanings[401]
This table reminds us that there is often no one way to label something that has the same information scent or explicit definition to everyone—it can even mean opposite things in different contexts.
When we design environments in which different perspectives are in play, we can use taxonomies to create thesauri to do these translations. We can also use faceted classification, an especially powerful taxonomical form. Developed in 1932 by Indian librarian S.R. Ranganathan, this “colon classification” approach gives us a technique to create highly scalable, adaptive classes based on combinations of mutually exclusive category lists. For example, we could use three simple categories to string together the classes for an online document repository: Author :: Date/Time :: File Type. There is no superordinal or subordinal structure; there is only a string of attributes, in unique combinations (ensured here by the fact that no one author will have created more than one file at exactly the same time). If more metadata were needed, we could add more facets.
Faceted classification is an excellent invention for accommodating the nested, nonlinear ways we experience context. It can expand and recombine to take on new perspectives and permutations, and provides us with the means to come at the world from multiple angles of entry. It’s essentially categorization as collage rather than a single lens.
But be prepared: it can be surprising how resistant business and technology partners can be to a non-single-hierarchy worldview. The Cartesian habits that make us want a single hierarchy are deeply ingrained.
Rules and Choreography
By rules, I mean prescribed principles, guidelines, or conditional procedures for action. Like relationships, rules themselves are not perceived directly. We instead perceive the information we use to make them, or we perceive their effects, but the logic that makes a rule work is abstract. The etymology of the word “rule” tells us that it’s always been about language: pronouncements, directives, orders, stipulations, and so on.
Although rules are language-based, they can be embodied in the environment. The simple wall in the field shown in Chapter 1 instantiates a rule about what can move from one side to the other, or perhaps the ownership of the land. A complex rule, with conditional logic, can determine that cars can cross a drawbridge until a boat needs to be let through. The bridge’s action makes the rule manifest, but the semantic expression of the rule came first.
We also use semantic information to put rules into our environment all the time. The line painted down the middle of the road is a semantic expression that we treat as if it were physical. Likewise, the law stating we should not cross over that line is another semantically expressed rule. When we make a contractual agreement, we are agreeing to abide by semantic environmental structures—many of which are signified by defined labels, or “terms” of the agreement.[402] And, as we’ve seen, software is made of rules, and its conditional logic works as a sort of legislation for software-dependent environments.
It is important that we expand the concept of information architecture as sharing responsibility for rule definition. The early focus on the arrangement of content for browsing, searching, and retrieving is only a microcosm of the larger concern: planning and structuring environments for habitation.
One way of thinking about the rules is as a set of instructions for how environments should behave—a sort of choreography for the coupled dance between agents, the elements we design, and the elements of the environment that are already there.
We can think of choreography as a predefined set of instructions, as in traditional ballet. But, we can also think of it as a set of patterns to be recombined and improvised, as in tap and swing dancing. As Klyn puts it, “The essence of choreography is the placement of meaning and structure into a flow with a specific context.”[403] The flow is the continual action of the agent’s embodied engagement with the elements of the environment; the context is ultimately how the agent understands those elements and how they relate.
Consider a quintessential, traditional information architecture project such as designing the taxonomy and search for a retailer. Even though this sort of design problem has had known solutions for many years now, we’re still evolving the way websites handle the nonlinear, idiosyncratic actions of “shoppers.” For one thing, retailers must learn that not everyone is actually a shopper. Site visitors are often using products as proxies for learning, dreaming, or solving a problem. And they come at the task of looking at products from many different situational contexts.
People satisfice when they browse and search—they engage whatever most immediately triggers the “scent” related to their present situation. In fact, “browse” and “search” are reified ideas that have more to do with the way the system constrains choice of action than the sorts of actions a user might take without such constraints. Everything a user does boils down to taking action in the environment, seeing what happens, and calibrating further action based on that feedback loop. Putting words in a search field or tapping on a label are both just different forms of tossing language at the world and seeing what the world gives you back. We can’t choreograph those activities in a linear, predefined manner. All we can do is have the right patterns to gracefully dance along with whatever moves the user might make.
Information architecture must accommodate the way people actually find and create their own meaning. So, for example, if we define “navigation” as the reified menus of lists found in sites and apps, we miss the point entirely. As Resmini and Rosati memorably say, “We say navigate, but really mean understand.”[404] Navigation isn’t really about the “chrome”—the fly-outs, mega-menus, and sidebar lists. It’s about taking action in the whole environment toward discovering the next needed action and the next after that. People look for the right “scent” of semantic function, and resort to the mach
inery of navigation menus mainly when other actions aren’t improving the scent.
So, architectures can’t always engineer people’s actions; they have to accommodate and assist them, instead. Resmini and Rosati refer to this capability as resilience, an information architecture heuristic they define as “the capability of a pervasive information architecture model to shape and adapt itself to specific users, needs, and seeking strategies.”[405] It doesn’t require space-age intelligent systems. Often, resilience is just a matter of creating simple structures that have facets and options that catch users where they are, from their particular points of view. A website might not need some advanced algorithm to get a user to the right input form if the site’s structure simply uses better information scent and instructional content. Likewise, a cross-channel service can accommodate great complexity just by providing the right hubs of service interaction, clearly orchestrated, to allow customers to move among them in their own idiosyncratic ways. Resilient conditional frameworks can make the difference between a dead, static museum of information and a living, breathing environment that the user experiences as an embodied conversation through action.
Sometimes, a linear path is necessary—for trained workers doing rote data entry, perhaps. But most software isn’t being made for those situations anymore. Some amount of wandering is often the most valuable part of the experience. Information architectures are constructs that help people understand their own actions, situations, and needs; good information architecture helps people discover their ultimate narrative along their own, uniquely wandering path.
We’ve mainly learned these lessons on websites for the last 20-odd years. Now we need to use these lessons in how we use information to ground, inform, scaffold, and nudge people’s understanding beyond the confines of individual computer screens, or within just one piece of software.
IFTTT (If This Then That) is accessed by users through a website or an app, but it’s actually a cross-channel service framework that has the potential to let users create architectures of their own for any networked device. For users to understand how to use IFTTT (see Figure 20-7), the service has to articulate itself in a way that provides clear instruction. Consequently, it crafted a clear taxonomy for the building blocks and functions available: Channels, Triggers, Actions, and so on. A “channel” is one of the cloud-based services; a “trigger” is the “this” object in “if this then that.” “On/Off” is binary mode setting for whether the recipe is active or inactive. These work almost like facets do—mutually exclusive sorts of elements that, like noun, verb, and adjective, perform specific roles in a grammar of digital-agent assembly.
The choreography here is twofold: the rules packaged into a kit of digital objects, and the dance the user can create by playing with the parts to make new, soft machines.
Service design brings a comprehensive approach to choreography, where designers consider every context in a service ecosystem. Service designs don’t necessarily involve digital information, but it is telling that the discipline has grown so much in the post-Internet age, when services can involve so many channels and information layers not previously available. With smartphones and ambient devices, services can be choreographed intimately with individual user action, on the fly.
Figure 20-7. Taxonomy of functions on IFTTT, from the service’s website at IFTTT.com
The Uber car service is a recent favorite example of service design. Uber uses a smartphone app as a customer’s interface to a service that helps find a ride from a group of Uber cab drivers near the customer’s location, as shown in Figure 20-8, left.
Figure 20-8. After requesting a car, I can watch my driver (identity obscured here) on the way to pick me up, live on a New York City map
Even though I’m standing in the midst of the unplanned, open environment of a busy cityscape, as soon as I engage the Uber service, I’m gently lifted into a service experience in which nearly everything is automated and requires very little of my effort. The driver arrives where I am—I don’t have to chase and hail cabs. I have contextual information about the driver’s identity, vehicle, and arrival. And when I get to my destination, I don’t have to fuss with a tip—the service is set up to pay its drivers without bothering the customer. The “tip” comes in the form of a quick one- to five-star review I can choose to complete in the app.
Speaking of context, when I finish my New York trip and arrive in Atlanta, the Uber app is ready with a helpful instructional message (Figure 20-8, right) specifically designed for the Atlanta airport context—complete with which level of the airport I should use for pickup.
Although any service has opportunities for improvement, there is much to appreciate in the Uber experience, at least based on my interactions as a customer. It turns a regular car into a digital object, along with the driver and the passenger, but without making the customer feel like an object. It doesn’t hide seams that users need to see but does hide the ones they don’t.
There are well-considered interactions at the level of interface here, and a great deal of technical prowess enabling the service. But there’s an architecture at work, as well: the labels, relationships, and rules that choreograph the coordination between physical location, semantic sensemaking, and digital systems. Whether anyone on Uber’s design team calls these aspects information architecture or not, this is information in the service of environmental structure and understanding. It requires an architecturally coherent system for placemaking and sensemaking, through and through.
The Organization as Medium
The level of choreography we see with services such as Uber is very difficult to achieve, even for a start-up that has no “legacy” baggage to corrupt its mission. But, like it or not, most of our work tends to be with existing companies that have longer histories—full of barnacles, cluttered basements, and skeletons in the closet.
Because organizations are essentially made of information—they are what they are because they’re “organized” after all—there’s no reason why they can’t be used as raw material for creating great contextual experiences, contextually aware capabilities, and clear, beautifully “seamful” architectures. However, doing it requires facing some truths about the nature of organizations.
There’s an adage called Conway’s law, named after Melvin Conway, who introduced the idea in 1968. It states that organizations that design systems “are constrained to produce designs which are copies of the communication structures of these organizations.”[406] The nested structures of the organizational environment become a collectively binding map of the way that organization sees the world, nudging it into creating all environments in its image.
The organizational map is often bound up with its existing machinery—the dysfunctional plumbing of its infrastructure. The map is in turn further etched into the organization by those stubbornly influential systems. Kohls can’t magically make a single, consolidated place where a customer can manage both the credit card account and the web-shopping account, because they’re fundamentally separate businesses—a bank and a retailer—merely portraying themselves under one brand. Delta has millions of customers and deep legacy data structures that already understand “Silver, Gold, Platinum”; it’s beyond nontrivial to blow it all up and start over with a more scalable loyalty structure, so they resort to bolting on new dimensions that don’t nest coherently.
Google can’t easily change what it means by “groups,” partly because some of the features are acquired systems that had to be grafted onto decade-old infrastructure. Apple, as disciplined as it might be in its design aesthetic, is only mortal, and struggles to create a coherent layout between its many deep silos and existing services infrastructures. Organizations are organisms of a sort, with their own perceptions, learned habits, and joints that bend only one way or another.
Technology departments tend not to concern themselves with how everything relates to everything else, but to focus mainly on the mechanics of engineering for defined requirement
s. Rather than composition, computer science—and IT engineering—is often more focused on what it calls decomposition, whereby a complex system is broken down into parts in order to better organize its work and maintain it. This is certainly a necessary effort, but it often becomes an end in itself, losing the original holistic context of the system. As Paul Dourish notes, “The typical conception of context in technical systems is of information of a middling relevance.”[407] When the environment is “decomposed” into tiny objects, they become the most relevant elements in the work, losing the composed context for why the parts should exist.
In built-environment architecture, this effort of establishing the full purpose and context of a building before designing it is called programming. (Alas, this word has other uses in IT departments.) Different from something like a project charter—which is normally used only until resources are assigned and a project has kicked off—an architectural program (or “brief”) is a constant touchstone throughout the process. It’s the first articulation of why a building is to exist and what its functional value should be, and it’s the continually updated standard by which the specifics of design are evaluated.
The way we document and articulate our work shapes the way the work is done. No matter how much more advanced our technology becomes, our failure to grasp the importance of “language as infrastructure” will undermine our ability to solve contextual problems.
Understanding Context Page 37
