These are elements that do not nest; they are parts that are not well composed. It’s not a “society of rooms” as much as a “jumble of objectives.” They reflect silos in which specific sets of requirements were met, but then thrust into the pile of “brand” like one might jam a juicer into an overstuffed attic.
What I hope is, after the preceding chapters, this no longer seems a hopeless mish-mash, but a sort of X-ray film with which you can begin to diagnose the structural problems of labels, relationships, and rules. It’s the first step toward considering how it might be improved with a clear ontology, a well-formed taxonomy, and a resilient choreography across the service life cycle. Information architecture can address the contextual dissonance here by identifying the joints in the Starbucks semantic universe and prescribing how they should be mended and reshaped.
The card, the physical store, the smartphone app, and the website all seem to have different perspectives on how the entire ecosystem should operate. The language facing the user is part of the problem, but the deeper problems come from how the organization uses language to define what it’s putting into the world in the first place.
Semantic information behaves as organizational infrastructure, as depicted in Figure 21-5, explicitly and tacitly, in at least two dimensions—in a vertical stack from the user-facing language of interfaces all the way to the entities in a data architecture, and in a horizontal dimension across all the channels the organization uses for interfacing with customers and partners.[417]
Layers like these are what make manifest the organizational narrative. The stories it tells itself are etched into its infrastructure, its departmental org charts, and its communication channels. Understanding the organization is an essential part of information architecture. No matter what user research discovers, it is often overshadowed by the hidden narratives and maps that such research could bring into visibility when used on the organization itself.
Figure 21-5. Semantic layers of an organization, across a sampling of channels
If the organization is trying to develop its own product and service spectrum but is also acquiring products and services by purchasing third-party platforms and companies, these two narratives will clash without careful architectural attention. Or, if the organization is driven by silo-generated narratives, even its internally created structures will scrape against one another and distort coherence by the time they reach the user.
Recall the Google Groups example: acquired or newly developed layers of the Google ecosystem, all created to be some kind of “group” capability, but without really defining what “group” means in the context of all the others. Or, consider Apple’s iTunes, which has long ago lost any coherent sense of being a music application, contorting itself over the years into a surreal goulash of ingredients: a multimedia purchase channel, a media file-management platform, a software app purchase store (but only for some kinds of software), customer-account management portal, and driver of core operating system components.
In all these cases, ambitious new platforms were added to existing ones, rich feature-sets were integrated into the environment, and teams shipped working software that technically delivered on each project’s requirements. And yet, it ended up rendering confusing, frustrating experiences.
More often than not, if we pay adequate attention to how language is acting as infrastructure, we have more success when we make new things. The answer to the question “What are we making” should attend to more than the roster of features on a wish list, whether the list comes from an executive or voice-of-the-customer data. It is fundamentally an ontological discussion that uses language to determine what the organization is doing to the existing environment, and why, before jumping to how features will be acquired or added.
Narratives and situations all contribute to the way context is composed through the ongoing engagement between agent and environment. The compositional elements aren’t limited to what happens in a project room. When devising the information architectures for these omni-channel environments, we need to consider multiple points of view, based on real-life understanding of people, systems, and organizations.
Situations over Goals
Organizations have a vested interest in their stories. Regardless of what challenges they face in their current dysfunctions, their aspirations tend to be toward efficiency, linearity, and planned outcomes. The received wisdom of user experience can often be just as vested in those assumptions. For example, a sacred tenet is that we should understand the goals of users and design for those goals. That principle sounds fine on its face, but the truth is more complicated. Remember: our preconscious, tacitly comprehended encounters with the environment are what drive most of our actions in a typical day. And, the way we experience something is based more on our peak-and-end heightened recollection than the actual facts of the activity.
It turns out, there’s no straightforward way to always know someone’s goal. The goal is often a reification—part of a story that didn’t exist before the activity. When watching how people actually think and behave outside of a usability lab—starting before they’ve engaged a product or service, and seeing how they behave all the way through—we find many of these goals emerge and take form during that engagement, rather than being fully formed plans ahead of time. And, they can be very different afterward than they were up until moments before the experience was completed.
People “confabulate” their experience to the point at which, according to neuroscientist Michael Gazzaniga, “listening to people’s explanations is interesting...but often a waste of time.”[418] For neuroscience research, it might be a “waste,” but I still believe hearing people’s stories is important work for designers, because we’re not scientists trying to understand the brain; we’re designers interested in how people understand their experience, even if the story is distorted in retrospect. We should definitely learn how users formulate and think about their goals. We just need to get underneath those stories and figure out what’s contributing to them.
In one of my projects some years ago, a financial services company wanted to provide investors or their trusted partners with the capability to change power of attorney for their assets on the website rather than having to use a paper form. When we talked to users about how they had done this in the past, their recollections were about “getting a form, filling it out, and mailing it in.” The main issues they remembered having were more about understanding the form, and the annoyances of printing, completing, and sending it.
So, what was missed in these interviews? Most of what was really important, it turns out. Because they knew we were working on a website, these users often unconsciously tried meeting us halfway by framing their answers in terms that they assumed we needed. Especially if we asked them, “What were your goals?”—they of course answered in the terms the questions established: framed as goals. Besides, who wants to believe they do anything without first having a goal? It would be embarrassing to tell your banker, “I didn’t really have a plan; I was just feeling my way through.”
But if we asked without priming the users with that context, their storytelling would be closer to the raw situation they were in—for example, “I just got remarried, and I want to be sure this time my spouse and I have ownership sorted out responsibly,” and not “I guess I’d look for the right form to fill out.”
When we studied click-path logs of people who eventually found and used the proper form, we found their paths wandered—like the information-scent berry-pickers we humans are—working through what they could find about their current contextual needs. Many of these visits reached a point at which they stopped for a while, only to return and mysteriously type a specific string of characters into the search field, leading them straight to the forms they needed to choose from. When we investigated further, we discovered customers were actually trying to use the site, then calling customer service in frustration, and learning how to search for the form directly. This full-servi
ce journey had to be analyzed to understand what users were doing—it couldn’t be captured by looking at site analytics alone. The actions with the PDF form were nested within a longer arc of seeking, finding, learning, and conversing.
Meanwhile, the engineers in the company’s IT department wanted to determine the task and create a linear progression to it. But, we could tell that few people would recognize that linear path to the task, because the goals that engineering assumed people had already decided on were, in most cases, yet to be discovered.[419]
The environment was missing the semantic functions needed to build the contextual bridges between the organization’s systems and the real-life situations of customers. The choreography had huge gaps, if it could be called choreography at all. The rules started and stopped very close to the bureaucratic process—which the technology was merely going to replicate in digital form—rather than reaching outward to provide conditional frameworks for people to discover their next steps.
The site was missing environmental scaffolding that could catch users from whatever angle they entered. For example, two customers might be trying to change ownership for spouses, but one just got married, and another just got divorced. Those are vastly different situations that entail different considerations and advice, some of which should address needs beyond this specific task.
Yet the site had no content or structure that addressed these life situations. Why not create these structures and explanations as a mediating layer in the environment? Then, search results could display information-scent for topics such as “divorce” or “marriage” or “death in the family.” That became the strategy: creating the contextual middle layer that connected the user’s current story with the form-based task—something that should’ve been there all along, even before converting the PDF form into a web application.
This was a complex problem to solve, even though it didn’t involve advanced gadgetry or ambient digital agents. However, the principle in this project is the same for any environment: how does the environment meet people where they are? How does it couple with people’s cognitive apparatus and give the right stepping-stones for discovering their needs? How is the arrangement of parts composed so that people have the right structures for learning and understanding?
* * *
[409] Hughes, Virginia. “How Monkeys Watch Movies and People Tell Stories,” National Geographic November 7, 2013 (http://bit.ly/1rpQC33).
[410] Gazzaniga, Michael S. “The Storyteller In Your Head,” Discover. Spring, 2012 (http://bit.ly/125yRBa).
[411] Gottschall, Jonathan. The Storytelling Animal: How Stories Make Us Human. Boston: Houghton Mifflin Harcourt, 2012:11.
[412] Dev Sci. September, 2011;14(5):944–8. doi: 10.1111/j.1467-7687.2011.01043.x. Epub 2011 Apr 28 (http://www.ncbi.nlm.nih.gov/pubmed/21884310).
[413] Kahneman, Daniel, and Amos Tversky. Choices, Values, and Frames. First edition. Cambridge, England: Cambridge University Press, 2000:769.
[414] Kemp, Simon, Christopher D. B. Burt, Laura Furneaux. “A test of the peak-end rule with extended autobiographical events.” Memory & Cognition January, 2008;36(1):132–8.
[415] Hayasaki, Erika. “How Many of Your Memories Are Fake?” The Atlantic, November 18, 2013 (http://theatln.tc/1wmrcrg).
[416] Hat tip to Dan Klyn for making me aware of this example.
[417] You can find a related concept involving two axes in Pervasive Information Architecture: Designing Cross-Channel User Experiences, p. 183.
[418] Gazzaniga, Michael S. “The ‘Interpreter’ in Your Head Spins Stories to Make Sense of the World,” Discover Magazine, August 1, 2012 (http://bit.ly/10jfDHF).
[419] There are rich resources on situation-based design, from HCI research done by people such as Lucy Suchman, Jean Lave, and Bonnie Nardi, who have adapted concepts from Situated Action Theory and Activity Theory. One place to start is Nardi’s edited volume, Context and Consciousness: Activity Theory and Human-Computer Interaction.
Chapter 22. Models and Making
I always prefer making frames: making context rather than content.
—BRIAN ENO
A Fresh Look at Our Methods
THE METHODS WE USE for information architecture—and for design practice generally—are mostly sound and valuable. Attending to context doesn’t mean we throw everything out and start over. In fact, most of our tools and processes are suitable for figuring out context anyway, even if we haven’t been thinking of it that way until now.
Personas, Scenarios, Site Maps, Card Sorts, Journeys, Service Maps, Content Inventories—most of these tend to be focused on the elements they represent—the objects and events—but not as much on the relationships between those elements. We might mention them, but they’re often treated as the negative space between touch-points and interactions, not explicitly analyzed in the foreground.
Additionally, there are assumptions baked into a lot of our methods, models, and documentation. For example:
The typical approach to mental-model task analysis—extracting tasks from interview transcripts—not only leaves a lot of the really important context in the transcript, but also doesn’t account for ethnographic observational data and the distortions of user self-reporting.
Card Sorts, if considered from an embodied perspective, are really about how people sort words on cards, not how they will find their way through an environment using those labels as infrastructure.
Personas tend to identify goals, but as we’ve seen, goals are largely fictional—even if the people the personas represent tell us “these are my goals”—because they’re actually not very good judges of what motivates them in the immediacy of perception-action.
Journey Maps, although often impressive artifacts great for collaborative understanding, can often be linear happy-path descriptions that lull us into a comforting story.
These issues don’t mean these techniques aren’t useful. We just need to analyze them and be sure we aren’t treating them like wizard spells, which, when we say the words and do the right motions, compel the right design solution to magically appear. Understanding and shaping context requires deeper and broader attention beyond the immediate face of a problem or project. Most design teams have little appetite for the rigor necessary to get it right. Still, as the world becomes more complex, our approach has to meet that complexity on its own terms.
Observing Context
In my own work, I’ve come to realize that understanding context requires immersing myself to some degree in the full context for which I am designing. Trying to understand that context through surveys, testing, or analytics is like trying to understand the Grand Canyon through postcards and satellite data. You don’t really get it until you walk along its edge and experience its depths in person. As bebop inventor Charlie Parker once said, “If you don’t live it, it won’t come out of your horn.”
There are many great research methods for doing design work, all of which have their particular strengths. However, for a rich understanding of user context, the gold standard is applied ethnography. Ethnography, generally speaking, is a method used in social sciences, wherein a researcher will immerse herself in the world of the subjects being studied, usually over long periods of time. That’s a great approach for scientific purposes, but design projects don’t have years or even months for research. So, we have to use techniques in a more specific, applied manner. It doesn’t render the deep understanding that academic-grade ethnography gathers, but—if done well—it gets us much closer to understanding user context than any other approach.
A methodology called contextual design marries some of the best in human-computer-interaction science with applied-ethnography approaches.[420] Developed by Karen Holtzblatt and Hugh Beyer in the 1990s, it leads cross-disciplinary teams through stages of Inquiry, Interpretation, Consolidation, Visioning, Storyboarding, User Environment Design, and Prototyping. As you might guess from the method’s name, it is obsessed with context; and it keeps the integrit
y of the contextual “chain of evidence” from beginning to end. The method is comprehensive (and even exhaustive), but it is flexible enough to be adapted to nearly any scope or design challenge, as long the work follows the method’s principles.[421]
One of my favorite aspects of contextual design is how it requires collaborative analysis and ideation with designers, potential users, and other stakeholders. Different perspectives introduce differing opinions, but that “noise”—which might be considered merely inefficient and inaccurate in traditional process modeling—is actually a huge benefit. Just as we can’t really “see an object” in a two-dimensional picture in a lab, but need to be able to move around it from different angles in the flesh, various team-member perspectives give us a richer perception and understanding of how people live and work in their real-life environments.
Contextual design is well suited to understanding multiple perspectives—creating the collage of maps and journeys we need—because it can generate multiple models for each user-session interpretation. These models can illustrate cultural context, workplace layout, and off-screen habits, as well as the traditionally recorded workflows and task sequences. By doing this for each person observed and then combining them into a wide-angle view during the consolidation phase, you get a more three-dimensional understanding of the current state.
Understanding Context Page 39
