Contextual design doesn’t dwell on semantics as a major area of focus, but language plays an important role in the approach. Really watching and listening to users means paying attention to the language they use to learn how it informs, supports, and exerts pressures on how people do their work. For example, on one project in my past, we not only observed how customer service representatives did their jobs with the full environmental resources around them—from both the tools on-screen and the physical material in their cubes, such as folders and cork-boards—we also tracked the way they talked about the work: the keywords they used and the way they meant them. It allowed us to develop a new taxonomy for tagging calls that better matched the cultural map of how the workers understood the task. That taxonomy was the lynchpin connecting the quality of metrics, the clarity of customer communication, and even the information architecture of the call-center software. That’s why I tend to track the language I hear, alongside the other contextual design artifacts; the language is the spine that enables the entire organism to function as a coherent whole.
Regardless of how you learn to do it, taking an ethnographic approach is essential. Everything else is supplemental at best or misleading guesswork at worst. Unfortunately, many clients and employers still do not understand and value this approach. Sometimes, they fear designers will learn the wrong things from regular workers and customers, or they value measurable data over observation-based insight. I’ve found myself resorting to “sneaking in” some bits of ethnographic interaction during usability testing, or asking friends “off the clock” to show me how they go about some related task. By hook or by crook, even a taste of applied ethnography can go a long way toward enlightening a project.
Some years ago, I worked with a nonprofit that provides content and community services for people affected by breast cancer: patients and their families, friends, and caregivers. It had launched a website in the mid-1990s as a place where users could read and learn from medically sound, layperson-friendly content about the disease and its treatment. It published both original content and doctor-approved summaries of breast-cancer research. A few years after its launch, its creators had decided to add a simple discussion forum to see if users would find it helpful. To their surprise, the forum soon grew to be as important a part of the website as the published content. In fact, it turned into the busiest breast-cancer-related community on the Web.
There were two macro-contexts in play: an area providing top-down, officially edited and published content, and another area where users were creating their own, bottom-up, informally written and shared content. The two areas weren’t well-integrated, and didn’t yet officially inform one another. Likewise, the curator-edited area had grown unwieldy in its structure, unable to handle the varieties of content that were now being published as it expanded to cover more topics.
Through contextual interviews, we learned how users’ personal narratives had been violently disrupted by disease, changing the course of their personal stories. As an environment, the site had to provide a variety of paths and places for users to handle different emotional states, life-changing decisions, and mundane-yet-essential practicalities around the many facets of diagnosis and treatment.
One of the things we discovered was that people’s needs shifted considerably from one moment to the next, depending on what phase they were experiencing. A patient who was recently diagnosed with cancer was often in a state of high emotional arousal—a near panic—and unable to comprehend complicated, multifaceted information layouts or technical content. Yet, within a short time, that same person would often become an expert researcher, throwing herself (or himself) into a voracious “flow state” in which volume and complexity were suddenly welcome. The site needed to embrace these shifts of perspective, not resist them with rigid consistency.
Also, when we started, we wondered if the seemingly bifurcated nature of the website was a problem. However, it turned out that having the community side and the officially edited side of the site was a boon. They each addressed different needs. Interestingly, for some users, the forum would become their main home on the site, where they’d often ask their questions first before consulting the edited content. A review of the forum content found that it was surprisingly accurate when the full thread of a conversation was taken into account: its inhabitants did a great job of policing the neighborhood. Most users said they found better answers more quickly by asking a question in the forum than from querying Google.
The forum was also treated as a meaningful, real place. Some users were far-flung and had no access to in-person group support, so they relied on this community for that vital aspect of their care experience. And, when someone would be preparing to go into the hospital for a longer stay, their friends would create “care packages” of thoughts, pictures, prayers, and other virtual objects that were as cherished as any real gift basket could ever be.
Like other websites I had helped design in the past, I approached this one as a system of activity hubs (see Figure 22-1), with contextual connective tissue stitching them together. In this case, though, the information architecture strategy had to avoid the trap of seeing it as a big article repository with a forum attached. We had more success by thinking of the website as a participant in existing narratives—a supplement to personal storymaking.
Figure 22-1. One of the architectural models used to think through the “hub” places users might visit, in whatever order necessary, to find their own way to sensemaking. The labels here were functional descriptors, not the final taxonomy. This was one of several artifacts used to work out the site’s information architecture[422]
There are plenty of sorts of design that don’t require research, and there are plenty of talented, experienced designers who can make an excellent phone app or consumer gadget without resorting to contextual inquiry. But, that’s because more often than not they already have tacit contextual knowledge sufficient for creating that design. I would still argue that getting at least a small taste of observing someone else would provide validation and a reality check, but success can still happen without it.
However, I can’t imagine devising an architecture for this nonprofit organization and its constituents without immersing myself to some degree in their lived experience, and seeing how they work through it.
Perspectives and Journeys
One contextual conundrum we run into is how users often reify their goals and stories when self-reporting their experiences. When we add to that the tendency of organizations to assume that people have nothing else going on in their lives but the specific task put before them, we miss out on a lot of context.
During the financial services Power of Attorney project described in Chapter 21, I developed a Situation-Need-Task (SNT) model (Figure 22-2). I have continued using it because it challenges my own assumptions about what people are doing and why, and it helps to keep my perspective honest.[423] It reminds me that people don’t just drop out of the sky to perform a task. They always begin in some situation that has emerged in their lives. They must then comprehend what they need—tacitly or explicitly or somewhere between—and only then, perhaps, locate and understand how to complete a task.
Figure 22-2. A Situation-Need-Task (SNT) model; situations spawn needs, which lead to tasks
Notice the model doesn’t use the word “goal” anywhere. As in a competitive game, a goal is something that you already know is there, something for which you aim. But, on the financial-site users often had to first discover what game they were playing, and they had no idea at the outset what the goal was. Either they didn’t know they needed to fill out a form, or they didn’t know which form it was, why it needed to be done, or how to do it properly.
Returning to our retail example from Chapter 20, if one person has a broken kitchen faucet, but another is renovating an entire kitchen, they might both enact a “task” of “typing ‘kitchen faucet’ into a search field.” The results of that search need to be shaped so that they
accommodate the different perspectives that these two situations bring to the task, as illustrated in Figure 22-3. For a broken faucet, the customer might need parts or an instruction manual for the faucet bought at that store a year earlier. The renovator, however, might be wanting beautiful scenes of renovated kitchens, with showroom-designer faucets in the spotlight.
Figure 22-3. The same search phrase, generated by two different user needs
A digital system—object, service, site, application, or whatever—needs users to understand its workings in order to complete tasks. This next model (Figure 22-4) shows how, if we shift perspective just a bit, there’s a sort of continuum that must be bridged. Ultimately, this continuum comes back to the question of ontology and what something means to the agent. When the environment can address the organic, analog context of the human agent’s need, there can be adequate support for bridging between system and person.
Figure 22-4. A different angle on situation-need-task
When we consider the cross-channel qualities of service design, or the growing complexity of objects, interfaces, and controls for interaction design, or the omni-platform challenges of content strategy, we have to map out entire systems and the contexts they influence. This includes the digital systems, but also the cultural and physical layers.
It’s important to name and define the key attributes of each of these systems, along with their functions. Yet, it’s also important to understand how they work as an integrated, distributed system, or “ecosystem”—what Resmini and Rosati call “ubiquitous ecologies.”[424] Even if the parts are not intended to be connected, or are created by completely different businesses, the user still experiences them all within the same environmental context. Just such a situation is described in the airport scenario from Chapter 1, and illustrated in Figure 22-5.
TripIt brought contextual information to the calendar; the Delta app brought contextual information to TripIt. The Delta app fed the boarding pass to the iPhone’s Passbook app—which seemed to be alerting a “calendar” event because it varied from the phone’s usual “invariant” event patterns. Plus the physical and semantic wayfinding within the airport itself contributed to the overlapping contextual information. For the person in the airport, it’s all one environment, even if the originators of these different services weren’t thinking that way when they created the software.
Figure 22-5. Contextual nesting, experienced as one ecology
I’ve mentioned collage several times already, but here is where the idea especially takes hold—in the way we accommodate so many contextual angles and perspectives. Real-life environments are collages of many parts, some of which are interconnected on purpose, some which are that way accidentally, and some of which clash when they should be complementary. Each element needs to do its best to be created with awareness and to complement the others.
For example, a typical User Journey map would be created for only one user at a time, normalizing user action across a linear timeline (Figure 22-6). A “journey” is typically a story, after all—but as we’ve seen, narrative can leave out a lot of contextual background.
Figure 22-6. A typical user journey model reifies a linear story
In Figure 22-6, the gray circles represent aspects of the story that might have actually been important to the agent but were ignored in the retelling. Regardless of how many channels and touch-points a typical journey map captures, it creates a sort of fiction that—while an insightful illustration of one path—doesn’t capture the points of view of other services, systems, and agents that are intermingled with the environment. These journey diagrams are useful, but we should always be asking if there are other contextual perspectives that should be added to the mix.
Again, the idea of collage comes into play here. What if we instead map the actual, messy, wandering paths of people, and capture their nested perspectives? It would allow us to see how the elements of a shared environment are understood from key points of view, based on the real behaviors of every agent involved.
In Figure 22-7, the gray circles are fewer, because it turned out people had behaviors that the linear journey overlooked, and some circles that were ignored by one perspective were important to another. It also helps us see which parts of these journeys have high shared importance and how the overall environment’s nested structure is understood by each party. Even though we can never capture every single detail of every possible agent’s perspective, just adding one or two other perspectives can bring valuable multidimensional insight.
Figure 22-7. A collage approach can capture multiple perspectives
As architect and philosopher Christopher Alexander explains in his (essential reading) essay, “A City Is Not a Tree,” each hierarchy or linear structure is just one perspective in a complex latticework of relationships.[425] It’s important to understand those points of view, but just as important to see them in the full fabric of people’s lives.
Now that humans are not the only thinking, acting objects in our environment, we have to include digital agents in our ethnographic work. Ethnography is traditionally about people, but what does it mean for us to also spend some time observing and understanding what digital agents do? Additionally, these agents are often just part of a broader system of technology and culture, much of which is beyond immediate view.
As we learned earlier, complex semantic systems are, in essence, maps, and maps have agendas. They select for some information over other information. They reinforce some assumptions and break others. The more sophisticated and rich the rules behind the environment, and the more digital agents it employs, the more the environment has agency as a whole.
We’ve not delved far into artificial intelligence and “smart systems” here. However, information architecture (like all areas of design) increasingly needs to understand what context is like from the perspective of the system, as presented in Figure 22-8. How does the system “perceive” the world, and the humans in it?
Figure 22-8. What happens when we reverse the players, and consider the situation, need, and task of the System, as it interacts and shapes context for the Person?
A useful exercise in any design involving digital agents is to work through how they see the world, and what situations and needs drive their discrete actions. What does the human agent look like to the digital agent? Try treating the user as an object in the environment that the system needs to find, interact with, keep an eye on, edit, or save, or whatever else we do with data. What is the ontology that describes and defines the human, its actions, and its context to the system?
These questions are ultimately part of defining what the system is to begin with, and how it categorizes the world we expect it to understand. Of course, we can’t interview systems (at least, not yet?), but we can learn a great deal by looking at user research from this angle as well as partnering with the technologists who programmed and configured the systems, or the business analysts who’ve documented them.
Structures for Tacit Satisficing
In our super-rational age, we tend to want to create super-rational structures. And, as we’ve covered, organizations have a strong interest in planned efficiencies. But, as Richard Saul Wurman says pointedly, “Order doesn’t equal understanding.”[426] Our culture tends to fetishize order, even at the expense of meaning. If everything is lined up neatly in a spreadsheet, it seems to have a kind of authority. If information is contorted into a comfortably controlled hierarchy, we’re glad somebody figured it out, and we take it as authoritative.
Western school systems are modeled on these tacit cultural maps, the same ones that ran railroads and factories. Yet, there are alternative options. Consider the Montessori classroom. In Montessori education, students can explore among various stations, or hubs, in the room. As is illustrated in Figure 22-9, typically, in an early-age setup, there are stations for activities such as drawing and painting, working with shapes, musical instruments, language arts, and simple math. Montessori teachers will gi
ve an introductory session with each type of station; the students are then allowed to explore them, mostly at their own pace and in their own order. It affords children the ability to construct their understanding of the objects and activities by interacting with the materials rather than in the abstract. Additionally, it doesn’t prize consistency and efficiency over self-discovery, sensemaking, and personal narrative.
Note that the options in a Montessori class are selected carefully, as are the objects and materials that are on offer. This is intended to nudge students toward particular kinds of learning. It’s a highly controlled environment but with a great deal of freedom compared to the more factory-like education approach in traditional schools. It instantiates decisions about what is important and what the students should be able to do without prescribing their every action or pace of learning.
Figure 22-9. A Montessori classroom layout concept, showing stations for engaging and learning various activities and subject categories[427]
To some, this looks terribly inefficient and chaotic. But in fact, students are learning a great deal—discovering the world for themselves, in their own way. This is an architecture that depends as much on the theories that drive the pedagogy and the categories of learning styles aligned with subject matter as it does on the physical structures themselves. In fact, it’s these language-bound principles that provide the environmental invariants for the design of a successful Montessori classroom, whereas the physical layout varies from one school to the next.
Understanding Context Page 40