CHAPTER 10
Designing the Moment
The Prototype Value Proposition
A vision and plans are critical to aligning stakeholders to work toward the same end-to-end experiences. Your frameworks will provide each execution team with good context for their work. These artifacts define and communicate the moments that you want to bring to life, as well as the role of different touchpoints and channels. Your experience principles provide a common set of criteria to inspire and critique your work.
However, these orchestration efforts will be for naught without action. It’s now time to make the future. But what does it mean to make something in an orchestrated process? Does each functional group follow its business-as-usual approach to create requirements, define features, and make content, user interfaces, printed materials, and so on based on the relevant medium? No! It’s now everyone’s responsibility to design and execute toward the same customer moments.
MACROINTERACTIONS AND MICROINTERACTIONS
In this sense, a moment is a macrointeraction—a collection of interactions that collectively shape a key part of an experience. For example, going through the checkout line to make a purchase at a store is a macrointeraction, while using the POS payment device for your credit card is an interaction. The beep that tells you to pull your chip-enabled card out of the slot is an even more granular level of interaction (a microinteraction, as coined by Dan Saffer).1 This hierarchy of interactions is good to keep in mind when defining how each touchpoint and associated interactions support the larger moment.
Designing moments well requires multiple iterations. Through trial and error, each touchpoint, should be refined to work well on its own and in concert with other touchpoints that make the moment possible. This chapter provides guidance on how to use different forms of prototyping to explore different design approaches for moments that make up an orchestrated experience. Chapter 11, “Taking Up the Baton,” shares techniques for orchestrating the people that design and develop these moments.
Prototyping Options
Due to the breadth of end-to-end experiences, it’s rare that one prototype will do the job of exploring and validating design solutions. Some prototypes will help you design how multiple touchpoints connect to create a customer pathway, while others will go more deeply into the interactions within one moment. Prototypes can focus exclusively on the customer’s experience, or on how people, processes, and technology behind the scenes make those experiences possible. What follows are the various options that you can pull from to test various dimensions of your product or service iteratively. These dimensions are not mutually exclusive. Use them to inform the direction that you take your prototyping.
Horizontal vs. Vertical
Horizontal prototypes broadly reflect the narrative flow of a product or service experience, while not going deeply into any one moment or interaction (see Figure 10.1). Horizontal prototypes help you assess how well different moments (touchpoints) and features meet the customer needs and deliver your overall value proposition. Validating these prototypes with stakeholders, customers, and front-line employees then informs individual concepts as well as how they work together as a system.
FIGURE 10.1
Horizontal prototypes will test a broad collection of capabilities while vertical prototypes go deeper in a narrow scenario, but are detailed in testing interactions and functionality.
Horizontal prototypes can take on many forms based on your needs and context. Paper mock-ups, interactive digital artifacts, storyboards, and other approaches can be used to express features and touchpoints that make moments possible. For example, prototyping new experiences for checking into a hotel may involve making a storyboard of key moments across multiple journey stages and contexts, or perhaps paper mock-ups and digital simulations of specific touchpoints in the order they would be experienced. For more complex experiences, your prototype may need to zoom out to show a bird’s-eye view of the entire service (or product). This is called service modeling, with business origami (see Chapter 3, “Exploring Ecosystems”) being one distinct form. As Figure 10.2 shows, service modeling helps you lay out the broader experience landscape and constantly reference, explore, and incorporate new ideas as stakeholders and customers provide feedback.
FIGURE 10.2
Service modeling used for design and connecting moments.
SERVICE MODELING
Service modeling may seem best suited for experiences for prototyping physical environments, but it’s also great for prototyping use cases of digital services in context. Digital channels—such as kiosks or dedicated software terminals—that live exclusively in retail stores, warehouses, bank branches, medical facilities, car dealerships, and so on can benefit from having a physical model to identify opportunities to inform the digital touchpoint.
Regardless of the form you choose, remember to focus your horizontal prototyping on the flow of the end-to-end experience. This form of prototyping aids cross-functional teams in designing together. At this stage of experience design, the details of interactions and content are less important than how various channels and touchpoints may work in coordination to support customers over time. Horizontal prototypes help you express to customers how they may experience these future journeys.
When you want to go deeper into a specific moment, channel, or touchpoint, vertical prototypes provide the right lens to make, test, and refine important details. As with horizontal prototypes but even more so, their form depends upon the channels and context of interaction. For example, mobile touchpoints that help customers find and book rooms from anywhere would likely be simulated in an interactive prototype. A series of conversations at the front desk, on the other hand, may be validated using role-playing with customers and employees. In either case, the goal is to bring to life specific interactions with high levels of fidelity and interactivity.
Vertical prototypes are also useful for exploring how different touchpoints come together to create moments in a specific context. In a health clinic, for example, you may envision a new flow of moments that connect your arrival to meeting with your doctors. To iron out the details of interactions, language, and hand-offs, you might build a physical prototype of the environment (kiosks, check-in areas, seating, and so on) along with a digital simulation of the kiosk touchpoints and role-playing of person-to-person interactions. These types of prototypes trade depth for breadth, enabling you to refine more granular details within and across touchpoints (see Figure 10.3).
COURTESY OF ADAPTIVE PATH
FIGURE 10.3
Concept evolution for an immersive physical experience for a store-within-a-store concept.
In Context (or Not)
Many people think of prototypes as things—products or communications in various media—to be tested in a controlled environment, such as a lab. Based on this conventional wisdom, organizations tend to gravitate toward usability studies and focus. However, lab studies may be convenient for researchers, but customers don’t live in rooms with people watching them through a two-way glass. Our advice: test each prototype within the context for which it is designed.
You can make a prototype to test in any environment, but contextual prototyping intentionally focuses on validating designs in the context in which they will be experienced. For instance, a team may be responsible for designing the digital aspects of an in-store kiosk, but testing in the hectic environment of the store (rather than the lab) pressure-tests the validity of the design better. A good example of this approach was Nordstrom Innovation Lab’s sunglass iPad prototype. In their study, captured in a compelling process video, a prototype was conceived, created, and iterated in the eyewear department in collaboration with customers and employees.2 This approach not only benefited from designing in context, but also led to strong results in only one week.
A contextual prototype can be of any fidelity, as long as it helps you understand and incorporate how you can tune your design better to fit a specific context. And, of course, you can combine multiple contextual prototypes of different touchpoints to validate how these new design interventions serve customers individually and collectively.
Technical vs. Experiential
Technical prototypes provide the means to ensure that a product or service can do what it promises. Traditionally, a technical prototype might be about whether the technology worked. At Fitbit, this could mean testing whether the sensors needed to track data fit on a wrist. For Google, a technical prototype may validate that predicative search is indeed predicative. Technical prototypes take critical jobs that the product or service needs to do—track or predict—and prove it’s possible before going too far with other aspects of the design. This makes sense because you don’t want to center your value proposition on something that can’t be done!
In product design, technologists typically own these types of prototypes. But increasingly, as experience design points to connected devices, embedded technologies, and new ways of interacting (such as voice interfaces), designers must concern themselves with what’s possible. This is one reason why cross-functional collaboration is critical to both designing well and efficiently. But this isn’t limited to technology. Designing to support experiences across digital and physical touchpoints is more broadly about feasibility, of which technology is one facet.
In experiences that are based on personal information or data from consumers—such as healthcare or financial services—testing an experience through a prototype where the information isn’t the consumer’s data presents a challenge. People have a hard time responding to an experience where the information isn’t their actual information. In this context, a technical prototype might mean hacking together an Excel sheet to test an experience of a financial application or in an estimating flow. The experience is limited, but a person can use his or her real data—showing the feasibility of having that data be relevant to the consumer.
In a service experience, a technical prototype might be about operational testing. You may create an immersive physical experience (vertical prototype), where you want to test out not only the front stage experience, but also work out how backstage elements could support that experience. You are testing if the backstage operations feasibly work to support the frontstage experience.
An experiential prototype (also, experience prototype) lets you test how a product or service is experienced, in which case that prototype may not work from a technical perspective. In product design, this is often called a Wizard of Oz prototype. To the user, it should feel like a high-fidelity experience, while the behind-the-scenes system is simulated. In other words, your prototype does not technically work, but your test participants can respond to an experience as it would work. This approach can be used to simulate a single technology (e.g., a database or integration point) to what will eventually be a coordinated system of people, processes, and technologies.
PALM PILOT AND THE EXPERIENTIAL PROTOTYPE
The founder of Palm Pilot famously walked around with a block of wood covered with printouts that represented screens, along with a wood “stylus.”3 He would go so far as to pull this block of wood with static printed screens out in meetings and mimic writing on the “device” to capture a meeting in his calendar or adding a contact. This is an experiential prototype. Separately, Palm Pilot made many technical prototypes to test if they could easily (enough) sync data between the device and a PC, or if the resistive screen and stylus could support accurate data entry (see Figure 10.4).
PHOTO (LEFT) BY ERIK PITTI, HTTPS://WWW.FLICKR.COM/PHOTOS/EPITTI/2371839286/. LICENSE AT HTTPS://CREATIVECOMMONS.ORG/LICENSES/BY/4.0/. PHOTO (RIGHT) © MARK RICHARDS. COURTESY OF THE COMPUTER HISTORY MUSEUM
FIGURE 10.4
Examples of Palm’s technical and experiential prototypes.
Interactive vs. Narrative
Perhaps when you hear the word prototype, you think of things that can be put in front of people to test interactions—interfaces with features and functions. For example, it might be a physical object with buttons, levers, and other controls. But remember all those stories, blueprints, and models that you created during ideation and North Star visioning? Those are also prototypes. They’re something you’ve made to answer a question—“How might we . . . ?”—that can be validated to inform even better solutions. Framed as a prototype, these mostly serve for internal use, getting buy-in across stakeholders. But you can also walk customers or users through storyboards and other static artifacts to prompt a dialogue around what will best meet their needs.
The Prototype Value Proposition
How will you know that what you design connects to what you realize you need to design? Through your orchestration, you’ve created traceability that links your design decisions to your original insights. Your vision work framed each moment and the value it should create for customers, employees, and your organization. Your vision was informed by principles, which were applied to characterize opportunities, which were based on insights from journey-based research.
As you make and test your prototypes, don’t lose sight of this critical throughline. Each touchpoint should have a raison dêtre—a clear why, what, and how that supports the value proposition of one or more moments. As you share and validate your prototypes, anyone, particularly stakeholders who aren’t always involved in the process, should be able to easily see why this solution is appropriate. Figure 10.5 shows one approach—a prototype value proposition worksheet—for making this throughline more tangible and measurable.
Keep these earlier concepts in mind:
• Touchpoint type: Working with your touchpoints, you’ll start to see that you can categorize them into common types based on the role they play. When you are making something that tests one or multiple touchpoints, make sure that you define that role these touchpoints play. If your prototype is required for the user or customer to interact with, then usability is paramount since people will see it as something they have to do. For example, entering billing and shipping information at checkout is a necessity. If the touchpoint is about enhancing the experience, then you know that it may be about delighting or overdelivering value (a cherry on top).
• Experience principles: Experience principles, at this stage, will help teams judge or measure their designs. Unlike heuristics (which can help guide design decisions), these principles are contextually specific to the opportunity that your prototype is addressing. As you identify what to make and how to craft your prototype, you should know specifically what subset of your experience principles (usually one to three) are most relevant to that moment and its supporting touchpoints.
• Touchpoint heuristics: As covered in Chapter 2, there are some intrinsic characteristics that can define any given touchpoint. When you identify your touchpoint type, you can identify what heuristics are most important for that touchpoint. For example, in an enhancing touchpoint, being delightful may be the overarching heuristic. If the touchpoint is identified as critical, then being valuable and relevant may be the sentiment you want to engender.
FIGURE 10.5
Prototype Value Proposition worksheet (stage, opportunity, type, experience principles—throughline).
Putting It Together
Chapter 2 used the analogy of touchpoints as a coordinated system of featured and supporting players on the stage of experience. That chapter highlighted some examples from the travel experience through an airport. Let’s unpack another airport moment to explore how prototyping can help answer the overarching question: “Is everyone playing their part, and well?”
Increasingly, Automated Passport Control (APC) kiosks are replacing human agents and the tasks they perform when international travelers pass through customs (see Figure 10.6). These tasks include scanning your passport, asking questions, entering data, checking a database, and stamping you through (or, if you’re unlucky, being held for more questioning). Most of what these agents do is data entry, so a kiosk may make the process seem more efficient and convenient. However, there are things that only an agent could do, up to this point, such as match the face of the person with the face on the passport.
Passport control is one moment in a journey that may have started many miles and days earlier, and won’t end after this moment passes. The identified opportunities for this moment include: make passport control easier for select travelers; faster, which benefits travelers and the airport; and cheaper for the border protection agency through staff reduction.
PHOTO FROM THE U.S. CUSTOMS AND BORDER PROTECTION, HTTPS://WWW.CBP.GOV/NEWSROOM/PHOTO-GALLERY/APC-AND-GLOBAL-ENTRY-KIOSKS
FIGURE 10.6
A bank of APC kiosks.
Imagine that your team is designing the interface for this new kiosk, and there are various touchpoints you would like to test. Even though you are testing digital flows, accounting for the physical environment is critical. There is the arrangement and location of the kiosks in contrast to the traditional agent-supported passport lines; information that helps people know what to do; as well as the physical kiosk, which has a camera, a sensor to read passports and documents, a sensor for fingerprints, and a receipt printer. Given the rich environment, you don’t want to limit yourself to a controlled lab environment testing your screens.
What prototyping approach should you take?
• Access to the security environment is limited, so you might first refine your narrative storyboards and build smaller-than-scale models to create a horizontal prototype. This approach allows you to explore how your new touchpoints may fit within the larger journey and the environmental context of border control. Where are the kiosks located? How many are there? How are they arranged? How would people know to queue up to use them?
• Your team would then want to work more vertically to see how all the touchpoints work together with the onscreen flow. Here, an immersive experience prototype at scale would help test how the screens complement the scanners and vice versa.
• Technical prototypes could be used to validate that the facial recognition software works.
• You may create a contextual prototype that’s placed at the border control area to ensure that you get real feedback about how the kiosk is used in context. When distracted by signage, agents, and roped lines, do people still know what to do? You may see travelers doing a lot of looking at travelers at other kiosks to try to reassure themselves that they are doing things correctly. At what points do they do that?
These different prototypes collectively help test both the flow among touchpoints and interactions with discrete touchpoints. Answering questions, scanning fingerprints and documents, taking a picture, and retrieving a receipt must all work individually and as a system to ensure the best experience. Taking your picture using a camera and the screen is a required touchpoint, and it is also a sequential touchpoint, where there are multiple actions that need to take place (see Figure 10.7). Can this required activity be designed to minimize any sense of burden? Can the sequence of actions feel seamless and intuitive? How do you minimize a sense of intrusion or “big brother” suspicion?
FIGURE 10.7
Having your photo taken through Automated Passport Control.
You also have experience principles, such as “treat people humanely” and “familiar as shopping online,” to guide and test your design decisions. A kiosk may feel like a great alternative to being in front of a person looking at you suspiciously. But you’re also asking people to do more on their own. When testing, there will be some finer usability issues you may identify, but as a new moment, it’s important to judge your prototypes based on how well they meet your principles and deliver on the intended value proposition. If you introduce this new moment, in what way does your testing help you validate its value? Quicker process or less uncomfortable human interactions? Thinking in these terms helps to ensure that what you make has a strong focus on what’s important for the customer and business.