Experience Mapping

The four steps to making an experience map (from Adaptive Path's Guide to Experience Mapping). 

My colleagues and I like to think our firm (Robertson/Sherwood/Architects) is particularly good at helping the clients we serve develop a clear vision for their projects. In our minds this has always meant guiding the course of discovery and design, along which we very much expect our clients to be dedicated participants. Since our firm’s inception, we’ve unquestionably believed in the value of design processes aimed at engaging as many stakeholders as possible, particularly during the earliest stage of each project. We regard our aptitude for architectural programming and attention to the needs of building owners, occupants, and operation & maintenance personnel as a strong suit.

William Pena’s classic programming guide Problem Seeking defined the simple, yet comprehensive, process for developing an effective architectural program. Almost a half-century since it was first published, Problem Seeking remains a touchstone for our firm. Its underlying principles are timeless. Fundamentally, they distinguish between programming—which is problem seeking—and design, which is problem solving. The process outlined by Pena involves an organized method of inquiry consisting of a five-step process (establish goals, collect and analyze facts, uncover and test concepts, determine needs, and state the problem) interacting with four considerations (function, form, economy, and time). This process has served countless architects and their clients very, very well.

As relevant as the methodology propounded by Problem Seeking remains, there’s no doubt a set of emerging issues impacting the discipline of architectural programming. Chief among these is the acceleration of broad cultural and technological changes changing how we work, learn, play, and live. It’s difficult to predict with any certainty what the coming years will bring, and consequently defining the design problem with precision is increasingly difficult. The proliferation and perpetuation of standards and guidelines that may quickly become obsolete work at cross-purposes with the challenge of identifying future needs. The increasing complexity of our world is pushing us toward a threshold whereupon it may become impossible to adequately state in easily understood terms the nature of the problems to be solved.

Is there a “magic bullet” providing an effective solution to the challenges posed by the emerging issues? Probably not; however, learning and borrowing from other disciplines is an essential means for coping with rapid change. One relevant specialty that immediately comes to mind is the marketing industry and particularly consultancies focusing on the development of user experiences (UX). The work of these specialists often parallels what we do as architects in the process of defining design problems related to enhancing user satisfaction with products and services. These professionals are adept at identifying emergent trends in highly competitive markets, generating insights into how their clients operate, supporting new initiatives, and building stronger futures for the organizations they partner with. They understand the necessity of managing a myriad of touchpoints to differentiate customer experiences, in much the same way architects differentiate and particularize the experiences of users in all sorts of physical environments.

Of course, a huge segment of the architectural profession (especially that involved in the design of retail facilities) already understands how the quality of experiences influences peoples’ choices of products and services; however, my guess is many other architects may not be fully aware of the sophisticated tools available for capturing and presenting key insights about the complex interactions that occur across any ecosystem. One such tool developed by UX designers is the experience map.

Adaptive Path is a San Francisco-based design and user experience consultancy that pioneered user experience design strategies during the early years of this century (the firm was acquired in 2014 by the financial firm Capital One but continues to publicly share ideas through its adaptivepath.org site, pro bono engagements, and annual UX events). The firm prepared a useful guide to experience mapping, which I’ll draw from extensively to validate the applicability of the technique as an architectural programming tool. Many of the concepts have direct parallels in the programming and design of buildings. I certainly see experience mapping as a useful adjunct to the process defined by William Pena in Problem Seeking but by no means a replacement.

Experience mapping is a collaborative, iterative process for synthesizing and visualizing the holistic user experience. Experience mapping builds knowledge and consensus. The activity results in an artifact—an experience map. The experience map presents, with richness and depth, key insights into the complete experience of users. Once developed, it becomes a tool that supports charting new courses of action. The quality of an experience map is directly tied to the quality of insights it communicates. That said, as with problem seeking, it is the process that is most important. Experiencing mapping brings teams together, builds empathy for the users (customers), clarifies the big picture, and identifies areas of opportunity. No two maps will be alike because the needs of each client and each project are unique.

The key building blocks of experience mapping are Doing (what actions are users taking to meet their needs), Thinking (how do people frame and evaluate their experiences), and Feeling (what emotions do people have along their journey). Additionally, Place, Time, Devices, Relationships, Touchpoints(1) , and Channels(2) provide a framework for the experience map. The methodology used involves conversations with user groups to gain insights, as well as individual interviews and observations. It often employs a directed story-telling technique to guide conversations and paint vivid pictures.

The anatomy of an experience map includes the following:

The Lens
The lens is an overriding filter through which you view the journey, such as a persona, more general experience principles, or a value proposition.

The User Journey Model
The journey model depicts the range of interactions customers have across channels, touchpoints, time, and space in pursuit of satisfying one or more needs.

The Takeaways
The takeaways summarize key findings from the experience mapping process. Takeaways could include strategic insights, recommendations, and design principles. They’re typically added to the map late in the process, once you have begun to pivot from understanding the current state of needs to envisioning a future state. 

An example of an experience map: An excerpt from the Rail Europe customer journey.

At its core, an experience map is a visual narrative of the users’ “journey.” The goal is to bring the collected data to life through a visually engaging infographic that is easy to comprehend. It should include the key building blocks—Doing, Thinking, and Feeling—but should also emphasize the guiding design principles that emerge upon understanding the journey. The map is organized on the fly over the course of several iterations. Visually, it should convey the essence of a story immediately. The experience map should present a compelling point of view, work on multiple levels (organizing hierarchically is important), and be designed for maximum impact. If it is done well, the map helps stakeholders break free of the nearsightedness of their individual roles to look at the organizational capabilities needed to achieve their goals.

Ultimately, like problem seeking, the experience map is a catalyst, not a conclusion. An experience map is a means to something actionable—ideally something to design around—and not an end in and of itself. It may not be a magic bullet but is a tool architects can master to improve the likelihood their designs for buildings will be as well-adapted, flexible, and responsive to future needs as possible. Because architects are visually oriented, preparing graphically effective experience maps should come naturally.

The applicability of experience mapping to architecture does come as a personal “aha” moment. While Robertson/Sherwood/Architects hasn’t yet developed a true experience map with one of our clients, we intend to do so soon. We’re already employing other elements characteristic of UX design, including mood boards, personas, and user narratives to supplement more conventional architectural programming means. Clearly, there’s much we can learn from other disciplines to help us cope with the increasingly complex and rapidly changing challenge of defining the problems we’re tasked to solve. As user-centered designers, we’re enthusiastic about the potential inherent in broadening our approach to architectural programming.

(1) A touchpoint is a point of interaction between a person and any agent or artifact of an organization. These interactions take place at a certain point in time, in a certain context, and with the intention of meeting specific needs.

(2) A channel is a medium of interaction with users. A channel defines the opportunities or constraints of a touchpoint.