Understanding Context

by Andrew Hinton

  This constructivist approach to allowing people to figure out the world in their own way is precisely how we can accommodate so many different people, with so many different needs and personal contexts.

  Setting up structures for people to choose from based on their own path isn’t a radical concept; it’s something we use a lot, even if we haven’t thought of it in this way. In one example (see Figure 22-10), financial services company Vanguard breaks down several possible ways to browse, understand, and choose investment funds.

  The landing page offers a crossroads with signage explaining the environmental constraints to which each path will lead. Some people will want more constraints than others.

  Figure 22-10. Vanguard’s “hubs” for catching the users in several contexts of fund shopping

  Google, which connects millions of people across nearly every digital context you can think of, has been sharing research on user behavior across channels and places. In one report, it explains that the multiplicity of information resources now available means that customers aren’t following as much of a linear path as they once did. For example, in marketing there is a well-worn metaphor of the sales funnel: customers start out in the broad “mouth” of the funnel as being just aware of a product or brand, then show explicit, more-focused interest, then active consideration, and so on, until finally purchasing. This metaphor has been an implicitly accepted “map” of marketing and sales for many years. But in Google’s research, it finds the metaphor isn’t as relevant now:

  The sales funnel isn’t really a funnel anymore....Today’s shoppers bounce back and forth at their own speed in a multi-channel marketplace. They switch devices to suit their needs at any given moment. They search; go off to look at reviews, ratings, styles, and prices; and then search again. They see ads on TV and in newspapers and online. They walk into local stores to look at products. They talk to friends, over the back fence and on social media. Then it’s back to ZMOT for more information. In short, the shopper’s journey looks less like a funnel and more like a flight map.[428]

  Now that there are so many more information sources online, the digital environment becomes the “home base” for considering and triangulating what customers learn from the traditional information hubs. The brick-and-mortar stores become just another information source rather than the necessary end-point for final decision-making.

  In essence, people use the environment as youngsters use a Montessori classroom, finding their own “flight path” between contexts. The most successful marketing approaches, therefore, are putting environmental structure into the world that enables rather than short-circuits this behavior. Rather than relying on broadcast information, brands are instead using broadcast as a supplement to the online conversations, then (when they behave themselves) politely and helpfully engaging in those conversations.

  You might look at things like this and ask: but where’s the context? Precisely. The structures aren’t forcing context so much as accommodating its unique emergence in each agent’s experience. Finding the right hubs and stations for people to satisfice through, calibrate within, and narrate to themselves means that we don’t have to plan out every possible use case—after all, it’s impossible at today’s levels of complexity anyway. Instead, we provide environments that are resilient, accommodating, similar to what game designer Will Wright, in reference to digital games, calls “possibility space”:

  Players navigate this possibility space by their choices and actions; every player’s path is unique. Games cultivate—and exploit—possibility space better than any other medium. In linear storytelling, we can only imagine the possibility space that surrounds the narrative: What if Luke had joined the Dark Side? What if Neo isn’t the One? In interactive media, we can explore it.[429]

  There is much that conventional digital design can learn from game design, especially in terms of structure that encourages and supports unstructured action and learning.

  Blueprints, Floor Plans, Bubbles, and Blobs

  We can do the research, do the analysis, and understand the many perspectives and paths involved in people’s contextual narratives. But how do we go about making the plans for such indeterminate structures?

  From early in my own experience as an information architect, I have understood the “architecture” part of the name to be not just a metaphor, but about a new form of actual architecture. So, it didn’t take me long to lose patience with conventional site-map tree hierarchy diagrams. They treat a website’s information environment like the directory structure of a file server. In fact, websites broke away from “one page per level” information structures long ago. Now that the Web is just one layer in a multidimensional environment of many channels, modes, and states, tree hierarchies are more unrealistic than ever; we’re increasingly likely to work on projects that have no obvious web interface at all. As a result, I rarely make a tree hierarchy diagram as a deliverable anymore.

  Whether using an application such as Visio or OmniGraffle, or a drawing on a whiteboard or paper, exploring the possible structures of information environments needs to allow for flexibility. We need to be careful to avoid locking ourselves out of contextual possibilities.

  Knowing what we do now about embodiment, it’s no surprise that the medium and technique we use for our working artifacts has a direct effect on our cognition. If we start in a medium that’s time-consuming or tedious to change, we’re more likely to settle for whatever expression we already have. Our first try at an intricately drawn and connected schematic starts to look pretty good when we consider the work it will take to reorient shapes and reconnect magnets. This isn’t even to mention the paralysis that detailed interface wireframes can cause—the inertia against making changes convinces us they aren’t necessary and tempts stakeholders to just run with what is pictured.

  The more our first effort uses polished, squared-off, and perfectly aligned objects, the more their “order” can easily masquerade as understanding. Context controls conduct, and the contexts we manufacture with our design artifacts can have unexpected, limiting effects on our solutions.

  Interestingly, Tim Berners-Lee, in his original proposal describing the World Wide Web, explains that, “When describing a complex system, many people resort to diagrams with circles and arrows. Circles and arrows leave one free to describe the interrelationships between things in a way that tables, for example, do not. The system we need is like a diagram of circles and arrows, where circles and arrows can stand for anything.”[430] Expressing “web-natured” environments as societies of circle-shaped contexts has roots in the nature of the medium.

  When I read Sir Berners-Lee’s statement, I was relieved, because I’ve been working with circles and blobs for years but feeling a bit ashamed when I compared my work with my more graphically disciplined colleagues. That’s because I tend to begin by throwing everything I can think of onto a page (digitally or otherwise), letting it scatter like mercury. Then, I wallow in it until patterns begin to emerge, and I begin stitching together relationships and functions, and nested overlaps. Usually this works much better if I’ve done some contextual observation and other research to get the problem space under my skin a bit.

  On purpose, these circles and blobs, like those in Figure 22-11, involve the least possible intrinsic structure. The shape of the object can constrain us to seeing it only one way. A brick says, “I’m a brick; put me in a wall.” But a smooth, circular river stone says, “I’m a circle—I could be anything.”

  Figure 22-11. A typical bottom-up starting point when I’m working on an information architecture problem (blurred to protect confidentiality)

  Imagine my delight when I learned that serious, built-environment architects do something similar. They call them bubble diagrams (see Figure 22-12).[431] There’s a marvelous variety of them out there, which I find encouraging. Architects have to follow stringent guidelines for their official, deliverable documentation. But when working through the early stages of structure,
they can play with it more freely—and look at the rich variety in how they make bubbles.

  These diagrams are how architects can play with contextual structure at varying levels of abstraction, cheaply and quickly, without binding their thoughts to the hardwired angles of drafting rulers or CAD software. Even if making them digitally with connectors between, they are easier to rearrange on a whim, rather than strict boxes that have to choose which sides are connected and which are not.

  Figure 22-12. The marvelous variety one finds when querying “bubble diagram” using Google’s Image search

  Likewise, when exploring possible futures for any sort of information environment, such as a website, mobile app, or even a full-service ecosystem, using circles and blobs can be freeing.

  I’ve used them for doing something I call functional modeling (a phrase I borrowed from systems engineering, for which it means something much more formal). Figure 22-13 shows a functional model about the online capabilities needed for a fictional art-supplies retailer.

  Figure 22-13. A functional model coalescing decisions about priorities and capabilities, without crossing into literal structure or interface design

  Usually, I generate a functional model based on lots of raw material generated from contextual inquiry and stakeholder interviews. Sometimes I use that to do an affinity-clustering exercise on my own or with my team, but sometimes I take that raw material into a stakeholder workshop, where we explore affinities together. The exercise is often even more valuable for the discussions it prompts than the artifacts it produces.

  The main point of the modeling, though, is to work through high-level definitions and decisions about what the nature of the environment should be—that is, what categories of function does it bring into the world?—without discussing actual, literal design and structure. This way, we work through some of the big questions without the distraction of “why isn’t my department in the global navigation?” or “why doesn’t the app have our promotions blinking at the top?” Trying as hard as possible to resist leaning into literal design is a useful discipline. It avoids using interface solutions as a poor proxy for making real decisions about business models, strategies, and brand definitions.

  Even after this sort of modeling, it’s still risky to introduce the distractions of interfaces. Architecture still hasn’t found a direction. In Contextual Design: Defining Customer-Centered Systems (Morgan Kaufmann), Holtzblatt and Beyer argue that it is essential to “design the structure” first—getting the architectural framework right before rendering the object-level design of UI. Writing in the early 1990s, they call this User Environment Design, and unabashedly refer to it as architecture of “floor plans” before working through the object-level details of interaction.

  As a floor plan for the system, the User Environment Design shows the parts and how they relate to each other from the user’s point of view. The User Environment Design shows each part of the system, how it supports the user’s work, exactly what function is available in that part, and how it connects with the other parts of the system, without tying this structure to any particular UI. With an explicit User Environment Design, a team can ensure that the structure is right for the user, plan how to roll out new features in a series of releases, and manage the work of the project across engineering teams. Basing these aspects of running a project on a diagram that focuses on keeping the system coherent for the user counterbalances the other forces that would sacrifice coherence for ease of implementation or delivery.[432]

  Even though Contextual Design predates the public-and-commercial Web, and so much else that has emerged in the past 20 years, it offers a way of thinking about environment that still deserves to be more understood and adopted in mainstream software design.

  The floor-plan approach takes the architecture of a system seriously as architecture of places where people take action. It introduces an embodied understanding of the way the system can be inhabited, but it still does so at a level of abstraction that allows change and iteration. In Figure 22-14, you can see how a typical floor plan mainly displays the most important aspects of the arrangement of places, each established to support a particular set of functions for inhabitants. The shapes of rooms and what seem to be decorative details are actually ways of establishing the function of each place: the purpose of an eat-in kitchen is also to accommodate a circular table, with a nice view; the modern family room is about electronic entertainment through a television screen, so it doesn’t need as many windows, and is tucked away in a corner of the structure.

  Figure 22-14. An example of a residential floor plan[433]

  The object-design-level details come later, but the functional structural arrangement must be established first. Information architecture models can also use this level of abstraction to show how one context relates to another, how they cross over and inform one another, and their priorities in relation to the whole.

  An example of a draft version of just such a diagram is shown in the right half of Figure 22-15. In this project, a functional modeling exercise that rendered the egg-shaped model on the left provided the defined priorities that informed an early version of actual site structure, in the map on the right.

  I’ve found that if the diagram becomes too complicated and baroque, it raises a warning about how understandable the environment will be. A retail environment that is about “products” and “learning” and “managing projects” can accommodate a lot of complexity within those essential, high-level functional categories. Then, those categories can help define the essential nature of the outer structures of a nested website or other environment.

  Figure 22-15. A functional model leads naturally to high-level structures in an early version of a basic floor-plan-like structural map

  Note how the map on the right of Figure 22-15 isn’t using interconnecting lines but overlaps to show structure. By using semitransparent shapes, the map can indicate where summary versions or borrowed functions of some areas might overlap within other nested structures.

  This overlap of content and function is something that’s possible in digital places that is less possible in physical ones. Structural definition is still needed to establish nested invariants, but software makes it possible for contexts to be replicated and connected in useful ways across the invariant barriers. The challenge is to ensure that they don’t blend so much that the environment is trying to allow the user to do everything from everywhere. Even if the kitchen can borrow some of the entertainment function of the family room, it shouldn’t be made to be both at once, which would obliterate the essential character of both places. A house with no walls or defining characteristics among rooms is just a big shed with furniture inside.

  Likewise, a retail website’s account section might cross over with the site’s global header; and its authentication state might cross over with features at a store’s kiosk or checkout counter. These are not separate boxes connected by arrows, but nested, overlapped contexts, ambiently intersected.

  The most value I’ve found in this approach is how it seems to intuitively tell a story about places and contexts, and how they relate to one another. One of my first clients as a full-time information architect (a fairly new role and title back in 1999–2000) was a nonprofit organization that brought together research scientists and large technology companies to funnel money to graduate student programs. It did this to cultivate talent and make it possible for companies to share “precompetitive” research. Bringing together so many different players meant the organization existed as a sort of confederation of research scientists, universities, and technology corporations.[434]

  Since its website launched in the mid-1990s, it evolved like so many do: starting as a few linked pages only to later metastasize into a tangle of confused categories, wandering click-paths, and ad hoc features.

  Our research found mixed feelings with the organization and its community: scientists who’d become more entrenched in their own subcommunities, divisions between
appointed managers and regular folk, and enmity between academics and business leads.

  We realized that the site had become a visible instantiation of that discord: a messy tangle of priorities in tension. A new information architecture would mean more than just organizing all their content. It meant making an environment whose places encouraged mutual understanding. It was a chance to create a system of contexts that could help heal a professional community, and in turn be a sort of civic structure to support mutual habitation.

  We tried expressing that strategy using a traditional tree-shaped site hierarchy diagram. The response was less than enthusiastic. The structure came across as a pecking-order pyramid, where the subcommunities were relegated to second-class status. We realized the traditional tree structure wasn’t accurately portraying the strategy, which was actually to be more of a community building where a central atrium of important news and announcements tied everyone together.

  The stakeholders needed something more than a schematic for information organization. So, as is demonstrated in Figure 22-16, we created a kind of floor plan, but one that showed how various contexts would overlap. It showed defined areas based on function, nested within the main container of the parent organization. Then, it showed how the subcommunities would have their own somewhat independent satellite areas—based on a common template but sharing a news-based context with the parent organization. It allowed the subcommunities to have their own places, but it continually reinforced a friendly, overarching presence of the parent organization—the benevolent “house” that sustained the subcommunities’ “rooms.”