Moments Tell a Story

By deviating from a default explorative interface to a more specific or more constrained set of actions, moments essentially have their own start and end, points of friction, moments of resolution, and consistent thread throughout. While our default interface views may well be sprawling, open, and full of possibilities, the moments within them are where these possibilities come to fruition.

Moments Make Us Money

Whether literally through being a checkout flow or payment process, or figuratively due to their role as a key feature and selling point of our systems, moments often generate revenue. If a flow ends in money in a bank account or the achievement of a feature that you list on your marketing page, it’s probably a key moment.

Moments Constrain Our Interface

Moments will usually limit our interface to a subset of possible actions or contort it temporarily into an entirely new set of possible actions.

Now, this list could describe almost any interaction in any interface. A single button click could easily meet all these requirements and, realistically, micro-interactions are moments—they just might not be the moments you want to prioritize. You’ll have to apply your own scope and granularity to forming this list. Larger teams and limited products will likely have more granular moment lists; smaller teams and more expansive products will likely result in broader, zoomed-out lists.

Once you’ve defined the parameters for what constitutes a moment in your interface, you can list them. Whether you type this list in a notes app, throw it on a digitized Post-it board, or write it in six-foot letters on a wall is totally up to you. The only thing to avoid is projecting linearity into your list.

It’ s very easy to get caught in the trap of assuming certain moments will be performed conveniently in sequence—someone will create their account, then add their profile image, then follow their friends, then view their timeline, and so on. Unfortunately, this happens far less often than we would hope. For this reason alone, I like to write my moments down on Post-its and jumble them up occasionally.

This process should not take too long—I’ve never had it take longer than 30 minutes and most sessions are done within 10—and it’s often a case of documenting what’s already in a design brief or a client’s head. For products that encroach more into service design, where you’ll generally be working with multiple interlinked products and sub-services, it might make more sense to draw up a list of moments for each of these and then consider moments of transition as well.

Your moment list should be a simple reminder of your product’s key set pieces and should complement some of the broader, system-level documentation we’ll amass through our process. Figure 9-1 shows a simple example of a Post-it moment list.

Finally, I’d highly recommend finding criteria against which to prioritize your moments. Again, as every project and process has its own goals and idiosyncrasies, it would be remiss of me to mandate these parameters, but the following questions are good starting points:

• How integral to the core product is this moment? Uploading an image on Instagram, for example, is critical for the product. No images means no product. Adding a bio or a profile picture would be lower on the list.

• How integral to your audience’s motivations is this moment? Creating something new in a creative application and displays of mastery or skill while learning are obvious candidates for key moments. If you understand these desires and motivations through ethnographic research—and they’re not used as a crutch or with malicious intent—then moments that allow for, and celebrate, the realization of these can be extremely powerful.

• How much does this moment contribute to the overall expectations of our product? Through your marketing site, word of mouth, social networking, sales pitches, and any other medium that revolves around selling your product and its features, people will start to build up a whole host of expectations. Moments that might seem somewhat innocuous at first can, in hindsight, be critical moments in realizing these expectations.

• How much does this moment deviate from common convention or your audience’s mental models? Moments that involve high degrees of learnability—or esoterica—are likely to be key moments by virtue of them still existing in your interface. In Chapter 3, we discussed drawing a feature complexity diagram like the one shown in Figure 9-2. Through the process of drawing this diagram, we should already have a solid idea of the unintuitive features of our interfaces that we need to teach.

The purpose of listing our moments is not to provide an exhaustive feature list or a widespread justification for our product—it’s important not to overthink things. Many times I’ve spent too long on such an exercise and the whole point—to produce a succinct list of the most impactful moments—is lost, replaced instead by a tangled mess of smaller features that slowly become impossible to prioritize. When in doubt, think in broad strokes.

Once we’ve gotten our Goldilocks-style list of not-too-vague-not-too-granular moments, we can look to categorizing the items.

If you look back at Figure 9-1, you’ll notice I’ve used the categories “Firsts”, “Repeats” and “One-offs.” “Firsts” represent the moments that we want to use to highlight someone’s first performance—“Firsts” are especially important for features that might need a certain degree of guidance or repeated features that are integral to our core offering that we’d want to celebrate and offer positive reinforcement for. “Repeats” are actions that we’d expect many people to perform many times. In the case of our rough Instagram-style moment list, this category will include actions such as liking other people’s posts, posting to our story, and posting for ourselves. Generally, these recurring actions will often represent the core loop of system usage. Finally, “One-offs” represent actions that will likely only be performed at certain points, or at least very rarely. While many of these actions might well be key moments, they’re simply occurrences that just don’t happen regularly enough to be seen as part of a core loop or common usage. Actions such as adding a profile image, updating payment details, changing your bio, and updating an e-mail address are all candidates for important moments that don’t occur regularly.

Once we’ve got our moment list together, prioritized, and categorized them, we can finally document and design them.

Moments Rely on Intent

Whether we derive intent from the performing of a specific action (clicking a “Pay Now” button should, we’d hope, indicate intent to pay for some items) or through a manifestation of state (which I’ll discuss in detail shortly),we need to be able to somewhat accurately infer intent. It seems almost completely obvious, but ensuring we have sufficient input to suggest intent is an often overlooked task. It’s a surefire way to make sure you question if any of your calls to action or framing scenarios are vague.

Moments Are (Mostly) Stand-alone

Having a moment that relies on a whole host of preceding moments is one of the easiest indicators that we’re attempting to turn an explorative process into an overly linear flow. By documenting our moments in a way that makes them initiable from almost any scenario, we’re able to provide a clear path—or story—through our individual moments without requiring a sequential chain reaction of interactions. There’s absolutely nothing wrong with actions that are only performable given specific conditions, and progressive disclosure is often an integral aspect of our work, but there’s a big difference between saying, “Someone can only add a bio if they’ve set up their username,” and saying, “Someone must add a bio after they’ve set up their username.”

Moments Change State

Once a moment has played out, our system’s underlying state will be changed in some way. By its very nature, interaction design revolves around undulations in state, and our moments often build up climactically to these changes. Take an image upload and edit process as an example. Our starting state might be a timeline with a list of posts. We initiate the “post-new-image” moment by clicking a camera icon. We go through the process of editing, tagging, and describing our image, and the upload succeeds. While it’s possible we’ll be returned to our timeline once the upload succeeds, our system state has changed, we’ve posted an image, and our timeline should update to reflect that. We might also wish to show a success message, or, if it’s someone’s first time uploading, highlight any actions that can be performed on their own image that they can’t on the images of others, such as editing their post, or tagging other people.

Understanding these final changes in state might seem somewhat obvious, but I’m consistently surprised at how often I see designers—including myself—prematurely deem a moment or flow as over without considering the true final impact of the actions performed within.

In essence, moments tell stories. They have a beginning—one that is usually borne out of a need to achieve a goal or solve a problem, often with moments of friction, conflict, adversity, and resolution—and they have an ending—the effects of which ripple through the fabric of our interface. While the cliché of “design is storytelling” has permeated the industry and, frankly, been discussed half to death, it’s hard to escape the structural underpinnings shared by interaction design and storytelling.

To me, interaction design’s core lies somewhere in this parallelism. Conducting not only what someone encounters from the start to the end of a moment, but how the reverberations of its resulting actions permeate through the rest of an interface is the art of interaction design. Done right, even the simplest moment can become an integral plot point as its elements and components shift in tune to action and manipulation.

It’s for these reasons that I believe communicating and documenting our moments in a story-based medium to often be the most enriching part of a design process. This stage is where we take everything from our feature list to our empathy maps and start piecing together how our work might be used in real-world contexts. In communicating how the key moments of our work fit in and around the day-to-day lives of people in a realistic and granular way, we create a bridge between researching, planning, and making.

A Moment’s Beginning

Before a moment really begins, it has to be presented and framed. Framing an interaction involves purposeful representation of the possibilities of your interface at its current permutation of state. This is where the signifiers, cultural conventions, and affordances from Chapter 2 come in to play. Essentially, our interface needs to communicate the possibility of action, whether that’s through a button designed to look clickable; an underlined, differently-colored link in a body of text; or a toggle switch in a form.

When we frame an interaction, we’re looking for intent. As we explored earlier, the more certain we can be that someone wishes for a moment to unfold, the more confident we can be in shifting our interface to accommodate this. Intent comes from framing. While a clear visual language can dramatically help with this, it is often our interfaces’ microcopy that most affects how confident we can be in translating action to intent. A Let’s Go button, for example, does not communicate intent as well as an Upload button. Getting the right balance between the amount of context and the visual or cognitive weighting of a specific action trigger is key to framing interactions.

We’ll discuss framing in more detail a little further into this chapter, but for now, let’s just acknowledge that without solid framing, we limit how confident we can be that someone actually intended to instigate our moments.

Once we’re confident our moment is framed well, we can think about the “real” beginning.

Moments begin as goals. Just as a movie might begin by introducing us to the goals and motivators behind our protagonist’s journey, so too should we be aware of a person’s goals when they begin a moment within our interface. From this point on, the thread we weave throughout our moment is there to serve this goal. In addition to the explicit goals that might be evident for our moments, we’ll also want to consider the motivators that might affect it. We discussed in Chapter 8 the utility for empathy maps to accommodate both overarching goals and the underlying intrinsic motivations. Our moment documentation is no different. Goals are the what (“editing and uploading a photograph” is a goal; motivations are the why)— “feeling validated,” “showing people how much I travel,” “for the sake of artistic expression,” and so on. Our moments, then, represent how we get there.

Just as any good novel presents a protagonist with obstacles and conflicts, so too should the stories of our moments. The “middle” of our moments, insomuch as they can be wedged into a typically linear story flow, represent the progression through and ultimate culmination of the obstacles and problems that stand between someone and their goal.

Points of Friction

As we explored in Chapter 4, tension, resolution, surprise, and familiarity are all key factors that should be balanced throughout any form of progressive media. Interaction design is no different. Interaction design stands out most when we consider that the source of tension—those obstacles, problems, or schematic violations—are usually external forces; they’re the momentary distractions, the duress of cognitive load, and the day-to-day stresses of simply being human in this age of information. Music, movies, and novels get away with manufacturing their points of tension themselves. In the name of entertainment and engrossment, as designers we’re mostly left with how people’s environments, mental models, and emotions find ways to disrupt their moments of flow.

That’s not to say that there will never be points of friction intrinsic to our designs—there will almost always be awkwardly placed requests for account creationor the need to trawl through a relatively dull form to get to where we need to go—but that intentionally designing for tension is something that would require a great deal of thought and consternation.

As well as external sources of friction, technological constraints also present clear examples of unwanted tension. Network speeds largely dictate how long an interaction that relies on communicating with a server or another device will take. Hardware limitations can lead to certain interactions stuttering or generally feeling slow and clunky. Some moments of technology-based friction are simply unavoidable, and the best we can do is ensure that our products function well on older hardware or continue to function to the best of our abilities when a network connection drops. Catering to these unavoidable points of friction with the same dedication to communication we put into our “happy paths” is also key.

A request to a server failing—while often a clear source of drop-offs and poor conversion rates—doesn’t always have to result in the instantaneous end of a moment. Well-formatted and clearly communicated error handling, with clear instructions as to how to resolve a situation, could be seen as a moment unto itself.

While an understanding of intent, goals, and motivations is key to any approach to interaction design, it is the reality that so many points of friction will invariably be encountered that makes story-based documentation so applicable for modern design. By considering these various points, we’re accepting that both our own requirements and the real-world situational, environmental, emotional, and cognitive factors in someone’s life can be sources of tension, friction, and affliction.

The Moment of Truth

While the climactic rise from goal to completion might not be as palpable or as epic in an interface as it is in a movie, video game, comic book, or novel, it still exists. Now, it’s true that very few people would describe their day-to-day interactions with products in the same ways they would describe the sheer exhilaration of the Battle of Helms Deep (or Happy Gilmore’s final showdown with Shooter McGavin if you’re me)—there’s still a genuine point of climax in interface moments.

If we consider the “middle” of our interaction story as the “work” stage of a “signal, work, reflection” cycle, it’s clear that, upon reaching a climactic point of a flow, someone has put effort into getting there. While hardly a trip to Mordor (although I’m sure we’ve all used interfaces that have felt less taxing), this work and effort still culminate in one final plot point.

If we stick with posting on Instagram as an example for this framework, the point of culmination is when we’ve uploaded, edited, and described our photograph. We’ve started with a goal (post a photo) and intrinsic motivators (I want people to see what I’m up to or I want to share a photo because I think it shows my skills as a photographer), we’ve done the work (picked a filter, edited the finer details, given our photo a short description), and we’ve done so through moments of friction (other apps’ notifications begging for our attention, a crying kid who is tired of being neglected for social media, the creative anxiety of sharing your work with the world) along the way. We’re finally able to hit that Share button.

In essence, this point of climax can be seen as a moment unto itself. It represents all the hallmarks of our larger moments in microcosm. The action to complete our moment needs to be framed well, and we need to be confident that it’s what someone intended to do. There are potential points of friction, network issues, server errors, and even just a too-long wait, and there’s an ending that allows for reflection, further action, or both—which brings us nicely to our moments’ endings.

A Reflective Ending

Good endings show the value of the actions someone has just performed. When presented with tasks, work, conflict, or friction, we can quite quickly lose track of why we started this task in the first place. What was the point of it all?

By guiding people through these moments, like a skilled conversationalist telling a story, you’re able to build toward a crescendo point, where the “main action” occurs, that Post button is hit, our glorious photo is uploaded and ready for people to view... but then what?

A moment isn’t over at its crescendo, and abruptly ending a moment at this point can become an insidious habit. All forms of progressive media are heightened by a denouement of some sorts—a narrative structure that involves tying up the loose ends of discrete plot points, releasing the tension of an enthralling crescendo, allowing for moments of respite, and reflection to ease out of the narrative.

Interaction design should be no different. The tiny stories that we weave into our moments—as well as how they contribute to longer, overarching story arcs that we might want to tell through continued interaction with all parts of our system—need good, reflective endings.

This denouement of sorts is an important stage. It’s where we’re able to show value and causality, to present someone with the results of their work and say, “Hey, you did this?” It is here where the reverberations of an action can be felt, a short few moments where someone is able to watch the effect of their work permeate through an interface. And while this short moment of reflection or celebration may seem ostentatious, without it we’re depriving people of satisfactory endings, of being able to see that what they’ve just done—whether it’s sending a form full of data or creating a masterpiece in a digital painting app—has results, an impact, a real ending.

In the world of interaction design, we often talk about “delight”—to the point, frankly, that the word has almost lost all meaning. The closest we get, in my opinion, to instigating this delight is by designing these moments of reflection. Instagram does this by showing us our photograph in our timeline after we’ve completed the posting process. This might seem like a matter-of-fact, obvious thing to do, but that doesn’t detract from the fact that we’re presented with a satisfactory ending. Through browsing Instagram as a “consumer” (a word which will never sit right with me) of its content, we’ve seen other people’s photographs in this format, we understand that our timeline is the stage for these captured moments (and ads for weird clothes that no one wears and detox tea that no one drinks, but we’ll forget about ads in the name of romanticizing interactions), and now we see ourselves on our timeline, knowing that others will see our same post, in the same format, on theirs.

If our timeline was left untouched, or for some reason, Instagram decided not to show us our own posts on our own timelines, we wouldn’t have this moment of reflection . We might have a simple success message, an assurance that, yes, our photo was uploaded successfully, but we don’t get to see that—we’re not allowed to reflect or revel for a short moment at what we’ve achieved (Figure 9-3).

These four steps are a distillation of the entire story behind posting an image. It took me less than a minute to complete, but many millions of people every day enact their own versions of this out.

Posting a photo might seem, initially, to be a trivial and ubiquitous interaction. A simple checklist item on your never-ending task list. You’ve probably used, or designed, something that involves some form of uploading—adding a profile picture on a social network, uploading a screenshot to Slack, attaching documents to a bug tracker or task manager, an so forth. However, if file uploading or image posting represents a core moment in our interface, we’d do well to remember that stories lie behind the seemingly obvious stages of the interaction. Stories that start with goals and motivations encounter points of friction along the way, build up to a climactic moment, and finally ease out allowing moments of reflection and resolution.

Pick a Moment and an Empathy Map

Given that storyboards should take environmental, emotional, and motivational contexts into consideration, empathy maps are a great tool to bring in to a session. Write down the goals and motivations behind the moment that you’re storyboarding. For example, when storyboarding our “new post” moment, we might list “upload and edit a photograph from our vacation” as a goal, and “I want people to appreciate my photography,” and “I want people to see me as a well traveled and cultured” as intrinsic motivators. Illustrate this as your first panel and jot down some context outside the panel’s frame.

Plot Out the Story Flow

It often helps to plot out a simple flow first. Break out the Post-its and try and describe your moment in simple, conversational steps (Figure 9-6).

Tell the Story

Take your rough flow and turn it into a sequential, comic-like storyboard. Pay particular attention to the points of friction and the climax of your story. If a particular feature along the way might represent an obstacle or stumbling block, make sure it gets its own panel. As we explored earlier in this chapter, points where mental models are deviated from, long processing, or upload times and generally demanding tasks are all prime examples of potential moments of friction.

Consider how your character (the persona associated with your empathy map) might respond to these moments of friction based on their goals, motivations, and environmental issues. Again, good ethnographic research and well-rounded, challenging personas and empathy maps are vital here. The more confident we are in these, the more confident we can be in our storyboards representing atomic moments of use.

When telling your story, use speech bubbles and thought bubbles to show what your character might be thinking or saying. We can often lift these directly from our empathy maps. Other times, we’ll have to hypothesize when it comes to more specific, context-dependent dialogue. Again, we’re not trying to be prodigious scrip writers here; simple, condensed thoughts and phrases are totally fine. Consider, too, working in any verbatim quotes you’ve acquired from your research interviews. Any opportunity we find to bring a real human being’s wording or feelings in as a reference point is one that should be snapped up without deliberation.

End the Story Properly

Make sure you consider beyond the climactic point of your moment and have at least one panel reserved for the point of reflection and reverberation discussed earlier in this chapter. Furthermore, try not to lose track of the fact that the true endings of our moments often manifest themselves in the real world.

While our goals might be specific to the app or service with which we hope to accomplish them, our motivations often exist far beyond the borders of our applications and the devices on which they live. It’s extremely easy to fall into the trap of limiting design thinking to purely within the constraints of the product or medium for which we’re designing. While this degree of selective focus is a genuinely essential ability—being able to identify, implement, and manipulate the conventions, common signifiers, and implications of the medium we’re designing for is a core design skill—it can often lead to harmful presuppositions if we adopt it too early in our process.

An ending that shows not only the value of the tasks that have been performed but also the changes caused and the motivations realized in their performance is often key to a satisfactory storyboard. One that takes the time to consider the real-world implications of a particular interaction is paramount.

Figure 9-7 shows a completed storyboard.

While extremely rough, this storyboard communicates the plot points from the previous step and ensures that potential distractions are accounted for. Note that, while nine panels are a good starting point, many stories will span more than one sheet and many more still won’t fill a single page.

Annotate

Moment Mapping

While annotating directly on your storyboard is totally fine, you might find that there’s just not enough room in the margins to fit your notes in. Additionally, while annotating your storyboards, as a solo exercise, is a valuable use of your time, it’s often even better to use this as a chance for collaboration. A diverse group of people contributing to this annotation is—as is the case with any part of our process that involves speculating about emotion, mindset, problems, and distractions—always going to serve us well.

My preferred approach to annotating is—wait for it—whiteboards and Post-its. If you’ve drawn out your storyboards digitally, print each frame off at A4 size and stick them up on a whiteboard. If you’ve drawn them out by hand, stick the page up and number each frame. If you’ve drawn them out by hand on full-size A4 pages because you knew you were going annotate them on a whiteboard—good job!

Once we have our panels arranged on our whiteboard (or canvas—this approach, like every other I’ve mentioned, is just as doable in a digital environment as it is a physical one), we can arrange some rows beneath each one. You might already have experience with this kind of mapping. It’s a common approach to journey mapping that many UX professionals will advocate. Personally, I like to split my map into four rows—one for how someone might be feeling, one for how we want them to feel, one for distractions/interruptions, and one for potential drop-off points (Figure 9-8).

This approach lends itself nicely to a group brainstormer. While I believe that storyboarding itself should be conducted by a limited group (especially for our moment stories), annotating storyboards is a fantastic way of getting larger teams invested in these stories. Start by briefly running through the overall stories you’ll be annotating—remember, we’re thinking key moments here. If you have many stories (multiple key moments and multiple empathy maps can see your story list stack up fast), you might want to pick just a couple that you feel would truly benefit from this workshop-style approach to annotation.

After regaling our colleagues with a brief run-through of our moment story, we can start annotating. Work from the first panel and try to keep a brisk pace while still being casual and not bulldozing through your stories. A minute or two per panel is often enough, but absolutely spend more time on the juicier points if discussion opens up. (A panel that essentially represents a yes/no answer is going to be extremely light in the way of notes compared to, say, a panel where we ask someone for their payment information.)

It might take a while for the room to warm up to this approach, so treat this session like a story itself. Start by stating the goals and always bring your simplest story in first. While you may be chomping at the bit to get everyone annotating your nine-panel epic onboarding story, remember that you’ve spent a great deal of time with your head in these stories and many of your colleagues or clients might be coming in cold. Warming up with a simpler story to get conversation flowing and to allow for mistakes and misinterpretation is often a shrewd move. End by explaining how the work done that day will impact the rest of the project, how you hope everyone involved now has a better understanding of why we’re focusing on the moments we are, and that you’re super excited to get on using these stories to inform your prototypes.

Like any group brainstorming session, you’ll want to go away after the meeting and prune the ideas and suggestions that arose. While nobody wants to see their ideas discarded (and this is why we do it after the meeting, as opposed to looking a developer straight in the eye and tearing their Post-it up in front of them), an integral part of our jobs is ensuring that our work is representative and grounded. If the CEO thinks that someone will feel “delighted and in complete awe” at the “seeing-pricing-for-the-first-time” panel in a story, we’ll need to find a way to ease that out in favor of the more realistic “concerned-about-financial-impact” and “wondering-if-this-product-is-actually-worth-it” suggestions we might have. (In this case, feel free to do the whole staring-while-tearing-a-Post-it-up power play—it’s only the CEO.)

Leave the Post-its on the whiteboard (physical or otherwise) and thank everyone for their time. End the meeting, grab a coffee and a water (please hydrate, meetings are hard), and gather your design and product colleagues for phase two: pruning.

Pruning is something we should do after every brainstorming session, and I recommend doing it straight after. It makes for a pretty draining day, but you’ll be pruning a brainstorm while the context behind everyone’s suggestions is still somewhat fresh in your head. The purpose of pruning is to take any unrealistic suggestions and either get rid of them entirely or turn them into more realistic ones. As the team (or person) with the deepest understanding of your research (and if that doesn’t describe you, try to make sure it does next time!), you’re in the perfect position to make a judgment call on what is signal and what is noise.

The more you prune, the better you’ll get at spotting red flags—small traits that set alarm bells off in your head. An obvious red flag is the kind of unbridled optimism that anyone who might describe a company as “my baby” (founders, CEOs, investors who like to overstep boundaries, etc.) might display. Being overly attached to a product’s success to the point where one believes it to be a flawless solution, devoid of any potential malaise, represents a special kind of myopia. In fact, one of the most important skills you can learn as a designer (that, unfortunately, tends to only come with experience) is the ability to quell this kind of optimism-ad-nauseum without appearing as if you’re a prodigal spoilsport who only exists to ruin dreams and scare children.

Other red flags include opinions from people who have lived a life of sheltered, abundant privilege, who have yet to prove capable of genuine empathy (apologies, but unless you’re working on an app to dodge mansion tax or a croquet-court finder, then coddling the opinions of ever-comfortable people can be one of the fastest ways to sink a product), suggestions that revolve completely around revenue, ideas that rely on manipulation, and proposals that appear completely rooted in “competitor X does this.” (Tread lightly with that last one, though, as competitor research is a hugely valuable insight into convention and mental model consistency.)

The result, post-pruning, of our storyboard and story-mapping exercises should be a set of succinct maps that not only communicate potential scenarios and stories but are also imbued with many of the environmental, emotional, and motivational details we uncovered in our research phase. While a story for each combination of empathy map and key moment might seem daunting at first, it’s important to stress that these activities can be performed surprisingly quickly. It’s also feasible, should you be strapped for time, to replace a number of common UX deliverables—such as journey maps, user scenarios, and flow diagrams—completely with moment-specific, annotated storyboards.

Storyboarding and annotating, while best suited to an early-stage, pre-wireframe phase of our process, can also act as a great means of evaluation. If you have a particular feature that appears to be underperforming—either through high drop off rates from analytics or through poor performance in testing—storyboarding its current incarnation can reveal plot points that would otherwise be difficult to spot or elucidate. Using that to then create a more representative storyboard to lead into a feature redesign can be a surprisingly efficient means of improving existing products—or at least discovering areas where a redesign could be beneficial.

Framing

Just as we discussed earlier in this chapter, a moment, plot point, interaction, or any narrative or conversational tool is nothing without effective framing. To repeat the sentiment, the more confident we are that someone has communicated intent, the more confident we can be throughout the rest of our interaction.

Framing allows someone to preemptively envision what a certain interaction might do. The obvious example here is button text—with one of the key (albeit most-ignored) tenets of interaction design being that button text should describe the action it performs. Poor framing is, in my experience, one of the most avoidable, yet predictable errors in interaction design. However, it’s not always as simple an issue as taking an inventory of your microcopy. After all, plenty of wordless interactions (I’m willing to bet that clicking a camera icon and subsequently a wordless, circular button to take a glorious selfie is one of the most practiced and ingrained interactions modern society has with their devices) are completely satisfactory.

In order to frame interactions well, we must rely on many of the concepts already explored in this book. Gestalt rears its wonderfully practical head again here—perceptual grouping and consistency between elements is incredibly important to communicating action possibility and causality. Signifiers and convention also play hugely important roles in interaction framing. Buttons that are obviously usable, separation of decorative icons and clickable icons (especially common on smaller screen interfaces where space is precious), obvious states for items like check boxes or toggle switches, and myriad other considerations all have a potential impact on how well-framed an action is.

The key phrase here is action possibility . While entire interface states can often be devoted to convincing, pushing, or nudging (or whatever over manipulative verb we’re controversially comfortable using this week) people into performing an action, seeing an interface primarily as an open venue and a communicator of action possibilities offers respite from constant persuasion and illusions of control. Now, I’m not suggesting we shy away from a hierarchy of actions—that is, in fact, often a recipe for disaster—just that if we frame actions well enough (part of which involves communicating their hierarchy based on the current state), we can present an explorative interface when we feel its applicable to do so.

Acknowledgment

During a conversation, when someone provides their input, they usually expect it to be recognized. Even if we have nothing to offer to a particular conversation point or we need to pause and think, we’ll generally at least acknowledge that something has been said. Interaction design is no different. When we do something—whether that’s click a Submit button at the end of a long form or a simple swipe to change an image’s filter—we want to be told that our message has been received.

Now, in my experience, it’s extremely rare to find someone who expects digital interactions to be instant. Most of us are all too familiar with loading spinners, progress bars, and general slow responses and, even as network speeds and average device specifications continue to improve year after year, the very nature of Internet communication means there will almost always be some kind of delay to interactions that rely on network communication. Fast acknowledgement does not have to mean fast server response times (although that invariably helps) or instant app loading.

What many of us do expect to be close to instant, however, is this acknowledgement. Think about a conversation where you’ve been asked something that’s required you to think a little. Maybe you’ve been asked a tough question or you’re trying to remember something that’s relevant to the conversation. In such a situation, we can find ourselves doing all kinds of strange gestures and facial expressions to signify we’ve acknowledged someone’s input. The old trope of people looking “off and to the right” when trying to remember something is a classic example, but everyone is different. Some people will nod along to show (or feign—you know who you are) interest and presence while others will verbally “mm-hmmm.” When we need a moment to think, some of us might pull that strange scrunched-up pouty face or stare up at the sky. The fancy among us might even prod our chin or press a finger to pursed lips to really hammer home our consternation.

In fact, we rely so much on these verbal and visual cues, that we specifically exaggerate them. As someone who personally suffers from social anxiety, my brain constantly looks for rejection and disinterest in the behavior and expression of others. While I struggle to remember plenty of conversations (especially ones about deadlines, sorry), I can vividly remember the few rare occasions where something I’ve said has been met with an emotionless blank stare. As we discussed in Chapter 1, ruminations can often associate themselves with what, at the surface level at least, may seem to be banal experiences. Yet, a propensity to panic in the face of a blank response or lack of acknowledgement is not a trait exclusive to those of us who live with anxiety. Inherently, we all have a need for conversation and, with that, comes a need for acknowledgement.

Interactions should work no differently. If our system has to speak to another (our front end to an API, for example), one of the worst things we can do while that time passes is nothing. Simple loading spinners is ubiquitous in modern applications for this very reason. Perform the digital equivalent of a typical “I’m thinking...” gesture lets someone know, pretty much instantly, that their input has at least been acknowledged.

Lack of acknowledgement is yet another subtle but insidious error that often goes unchecked in design work. The phenomenon of “rage clicking” is inherently tied to this.

Rage clicking, as the phrase might imply, involves clicking (or tapping) on one, more, or all areas of an interface in the hopes that something might happen. Seeing someone rage clicking around your interface is probably as close to a personally heartbreaking moment as design can produce. It’s when you know you’ve screwed up to the point where someone would literally rather apoplectically wear their finger down on a keypad in the hopes that anything will happen rather than think rationally about what is (or isn’t) happening. Rage clicking, essentially, is a total confirmation that we’ve done our job wrong. Yet, while single-handedly justifying the need for emotional support animals in design studios across the country, it does present us with clear evidence that our framing is poor (someone is clicking something that isn’t clickable) or that our acknowledgement is worse (our interface is basically staring blankly into someone’s eyes and hoping the ground swallows it hole).

Acknowledgement also serves a secondary goal in our interface and that is communicating a lack of action possibility in its absence. If we consistently acknowledge someone’s input from their first moments of interaction and if they try to interact with something that is purely decorative or descriptive (e.g., clicking a decorative icon believing it to be an icon button), then the lack of response—within an otherwise responsive system—can provide a last-ditch anti-signifier: “You can’t do anything with this.” This, of course, relies on “any action will be acknowledged” being part of someone’s schema for our application, which means we need to be responsive early and consistently. It does, however, represent an interesting knock-on effect of consistently acknowledging actions as soon as they’re attempted.

How you acknowledge an action is going to depend heavily on context, constraints, and the personality you’re trying to convey. A ubiquitous example of acknowledgement is turning button text into a loading spinner—which works extremely well if you know your wait time will be relatively short (Figure 9-9).

This approach is effective for a number of reasons. First, a loading spinner is an extremely common convention, found in the vast majority of mainstream apps, and it communicates a clear message. Second, by replacing the button text, we’re acknowledging an action in the same context that it occurred—yet another point for perceptual grouping. Finally, by replacing the action’s text, we’re subtly and temporarily removing the action possibility from our interface.

As I mentioned, our approach to designing these in-between states will change drastically. In some cases, we might want to go all-in and have a full-screen overlay with a spinner to be completely sure someone’s action has been acknowledged. Other times, a subtle progress bar at the very top of an interface can do just fine. Probably the most integral factor to this will be the time we expect someone will be kept waiting.

Waiting

Waiting is the undesired inevitability of interaction design. As anyone who has worked in the service industry can attest to, most people have a rather ingrained disdain for being kept waiting—yet, as interaction designers, we do have the somewhat fortunate safety net of expectation in our corner. Indicators show that a specific action is taking its sweet time to process (our good friend the loading spinner, progress bars, etc.). They are some of the most ubiquitous design elements around, and they should tell us how common waits are in digital interfaces.

Yet, these expected waiting periods are also ripe for subversion—an interface that we perceive to be faster than others is one that stands out more often than not. Exclamations of “Wow, that’s fast!” and similar displays of shock and awe that an interface takes less than a perceived age to communicate with a back-end server are still some of the most common forms of praise that people bestow on interfaces. While often outside of our control, maximizing the speed at which various nodes of our systems communicate with one another is an incredibly important task.

However, simply shaving off precious milliseconds of loading time isn’t the only way we can subvert the waiting process. For some categories of interaction (video sharing, uploading high-quality images, processing extremely large files), long waits are an inevitability. By eschewing the sadly common practice of disabling interaction with the wider interface and allowing other areas of our interface to be explored, we’re able to essentially negate the impact of long waits.

Say, for example, we were working on a browser-based, UI design tool. A key feature of this will likely be uploading images. After all, is a marketing site without a full-page header image really a marketing site? Traditionally, image uploading has been a painfully drawn-out interaction in web sites and web applications, often forcing us to simply sit and twiddle our thumbs while waiting for an upload to succeed. However, with the advancements that browsers and operating systems continue to make, this really doesn’t have to be the case. Let’s say that, on an average connection, the average image that people upload for use in their designs takes one minute to upload. Not totally implausible given that designers often work with extremely high-resolution images while mocking up their work

Option 1—the easy option—is to fall back on the tried and tested common practices for image uploading. Click a button, select an image, and ... well ... wait.

Option 2—which is thankfully becoming more and more popular—is to process this upload in the background while keeping the entirety of the interface usable for the duration. This would let us drop our image in and spend that precious minute deciding which generic geometric sans serif from Google fonts we should use this time. We could even take this a step further and load in a placeholder or low-res preview of the selected image while the full image continues to upload—allowing designers to move and size the image into place without worrying about progress percentages or watching a loading spinner for a minute straight.

Finally, consider the concept of perceived wait . Perceived wait is, far above and beyond the actual waiting time, our major concern when designing interactions that might be a lot more involved than a basic “send-this-10kb-of-data-to-an-API-server-and-process-the-response” model. Many studies have been conducted on perceived wait in environments as diverse as hospitals, airports, and theme parks.

In a 1996 study of emergency-room waiting times, David A Thompson, MD, and colleagues concluded that “perceptions regarding waiting time, information delivery, and expressive quality predict overall patient satisfaction, but actual waiting times do not.” (Thompson, Yarnold, Williams, Adams, 1996). Thompson and colleagues, in a survey-based study, show that, while perceived wait had an impact on satisfaction, actual waiting time did not.

More anecdotally, we can look at how Disney manages their theme-park lines to account for the importance of perceived wait.

In Disney theme parks across the world, people wait in line—often for times approaching an hour (and sometimes longer still)—to ride a rollercoaster for 20 seconds. And while the psychology behind thrill-seeking (and rollercoaster riding in general) is genuinely interesting, I’m afraid it’s the lining-up part of things we’ll be examining right now.

While there are many logistical and systemic optimizations that can be performed to reduce actual waiting times in theme-park lines, a wait that feels shorter than it really is can often be the deciding factor in satisfaction—and Disney is a master of this. Our problem, it would seem, with waiting is that we’re just so easily bored. The time between formulating a plan (get on this ride) to achieve a goal of ours (feel like our stomach is turning inside out because we’re awfully strange animals) and having that plan actually unfold can, understandably, be excruciating. Disney—and to be fair, almost every other theme park in the world—understands that by filling this “empty” waiting time with smaller attractions and distractions, many people may be distracted enough to forget that they’re actually even waiting in line.

The lines for some of Disney’s larger attractions unfold through winding paths, littered with greeters and performers, food and drink stalls, and even video-game stations. By presenting people with these distractions, Disney benefits from people’s thoughts being diverted from “I wonder how long this is going to take?” to “I wonder if those are Gaston’s real muscles or if it’s just part of the suit?”

Closer to home (unless you work at Disneyland, of course), video games also handle perceived wait extremely well. As video games grow larger in every conceivable way, the time it takes to load certain areas can reach levels that are often worrisome for games designers. By managing our perceived wait, games designers can often mitigate the potentially drastic effects of loading times. The popular Ubisoft series Assasin’s Creed allows the player to roam around in an extremely limited environment while the main map and assets load—giving us a chance to practice our skills or reacquaint ourselves with any controls we may have forgotten. Bethesda Softwork’s Fallout: New Vegas manages perceived wait by presenting short facts or tips about the game’s world, lore, or mechanics (Figure 9-10).

For longer waiting times that cannot be relegated to background tasks, perceived wait is something that we can actively look to manage. By giving people something to do, or at least to read, while a longer process plays out, we can mitigate the negative impact of long waits. Of course, while shorter waiting times are always valuable, sometimes we have to throw our hands up and admit that we’re constrained by the technology we design for. When reducing actual wait times is either not possible or past a point of diminishing returns, look to managing perceived wait.

Respond

Finally, once our exhaustive-yet-exceptionally-well-designed waiting period is over, our interfaces must respond to the action that’s just been performed.

There’s not much to this section that hasn’t already been covered in the earlier exploration of moment endings. An interaction’s response is how we let someone know whether their intended action worked or not—which is an abstraction of telling them whether or not (or to what degree) their goal was achieved.

Responses, like acknowledgments, can take many forms, depending on context and relevance. Success and error flash messages are extremely common (Figure 9-11).

Other, more subtle, forms of response can be beneficial too, especially when space is limited or when the interactions we’re designing are themselves small and subtle. The spinner-inside-the-button from Figure 9-9 could, for example, present a brief success message in the button itself—essentially making for a single-element micro-interaction (Figure 9-12).

Just as a moment’s ending should offer some form of reflection, so too should an interaction’s response. If the interaction has fundamentally changed state in any way, then finding a way to reflect this will be a major factor in our response. In Chapter 2, we explored how animation can assist greatly in indicating state changes as the result of an interaction. I’d recommend a quick re-skim of that chapter if some of these concepts doesn’t sound too familiar!

Finally, action responses will, in many scenarios, need to communicate new action possibilities that might have arisen from the performing of the previous action. For example, the response state of adding a new to-do item might need to present new actions for marking that to-do as done, archiving it, or placing it somewhere different in our list. However, I’d like to use the remainder of this section to discuss what I believe to be the most important action, across the board, that should be communicated in any interaction’s response state: undo.

Throughout this book, I’ve tried to be as open as possible to different approaches to design, workflow, process, and implementation. As a field, digital design is, comparatively, in its infancy, and I truly believe there is no place for dogma or bullheaded absolution in such a fast-growing industry backed by an ever-changing landscape. However, this is where I break my own rule and espouse an absolute: Always let people undo their major actions.

No matter how well-framed, how wonderfully acknowledged, and how extensively optimized our interactions are, nothing can truly prevent mistakes. For too long, digital interfaces laid mistakes squarely at the feet of humans (or, to be less passive, designers of these interfaces deferred blame to the people they’re supposed to be making things for) and forced us into constrained and intimidating “Are you absolutely positively sure?” moments to (poorly, I might add) mitigate the erroneous performing of destructive or highly volatile actions.

“Are you sure...” is a framing device. It, in a roundabout way, lets people know that a specific action is not to be taken lightly and that bad things can happen if someone performs it. Now, I’m not suggesting that this approach to framing needs to disappear, but I feel it’s imperative to acknowledge how much of a roadblock this truly can be to creativity, self-expression, or just simply avoiding a state of sheer panic over a button press. My personal rule is to treat a modal as a lazy design decision unless I know I’ve explored all over avenues, and to me, “Are-you-sure?” modals are even lazier. No matter how much we convince ourselves that enough defensive measures will stop someone clicking the “Yes-I-want-to-delete-my-entire-digital-history-let’s-go” button accidentally, I promise you that with enough use, someone will click that button. Accidentally.

Preemptive modals are a poor and lazy safety net for us—designers and developers. Undo is an empowering safety net for the people we design for.

As we discussed in Chapter 3, an undo feature implies that mistakes are fine and expected. In an interface that allows for or attempts to foster creativity and self-expression, this is absolutely integral, but even in our general, everyday-use applications, it can save us. Since Google Inbox implemented “undo” for message sending, I’ve been saved from probably a dozen truly embarrassing e-mail moments, ranging from calling someone by the completely wrong name to pasting in a link that was absolutely, assuredly not the link I was supposed to be sending to a client. While these situations might not have resulted in total catastrophe, written communication on the web is hard work, and often even just knowing you’ve sent an e-mail with a pretty major typo in it can weigh heavily on your mind post-sending.

By implementing the undo functionality, we’re implementing a subtle degree of peace of mind. We’re offering a statement that, even when you really do mess up, you can always escape back to the previous state like nothing ever happened.