When Customer Journeys Don’t Work: Arcs, Loops, & Terrain
I want to share an article and a thought… Essentially, a different way to look at the work we do as designers (or anyone who touches the user experience or does service design kinds of work!).
Prelude: My Discomfort with Customer Journeys
Context: I’ve always felt weird about using customer journeys for an experience where we have dozens or hundreds of micro-moments whose sequence and/or usage is wildly different for many users. Take Gmail, or Webflow, as examples. These are both pieces of software where there are many possible journeys and paths, into and out of these tools. What features you choose to use and in what order might not map to a common path. Which, is the crux of my frustration: Many experiences aren’t linear. Or, your linear path and my linear path may not look at all alike. Even though we’re using the same tools to accomplish the same jobs. To be clear, I still feel customer journeys are a great tool for cases where there is a clear path or flow, such as initial on-boarding or the purchasing of a vehicle. But, it has always felt weird when there’s a request to create a narrative where there isn’t a common, recurring, sequence of activities (the best thinking I’ve seen on this topic has come from Andrea Resmini and his work developing non-linear ways to map a ‘cross-channel ecosystem’).
With this frustration with linear paths as context…
Act 1: Loops and Arcs
This post by Daniel Cook on “Loops and Arcs” is one that keeps crossing my path (mostly because a good friend I admire keeps bringing up this article). Anyway, while re-reading this recently for the umpteenth time, something clicked for me.
Loops and Arcs.
Loops…
and Arcs.
Loops and Arcs!
On the surface, the article is about ‘loops’ and ‘arcs’ in game design.
For what I want to share here—a version of arcs and loops adapted for UX & service design purposes— arcs are essentially the short narrative sequences we use to string together a series of loops. For arcs, you might think of stories, paths, flows, or any similar series of events. Arcs do resemble “journeys” except they’re not at all long nor are they all-encompassing. And, you’ll likely end up with a bunch of arcs, dozens of them, each composed of several loops. But, that’s enough about arcs, as they’ll make more sense after we discuss loops.
So… loops, they’re a bit different from touchpoints or moments or even activities. Loops are compressed, standalone moments of learning; moments where you try something, and learn, through immediate feedback. So, there is an action, but there’s also a feedback loop, that leads to learning.
From Daniel Cook’s article:
The player starts with a mental model that prompts them to…
Apply an action to…
The game system and in return…
Receives feedback that…
Updates their mental model and starts the loop all over again. Or kicks off a new loop.
Connecting some dots here, I HIGHLY recommend this short YouTube video on “How Super Mario Mastered Level Design.” This video is the single, best way to understand what I mean by moments of learning.
This short video, only 5minutes, is a GREAT deconstruction/explanation of all these tiny moments (aka “short iteration cycles”) we take for granted that work together to collectively onboard new players into a well designed game.
Oh, and even though loops have a “model / action / system / feedback” cycle…
…this cycle is not a long process (something that kept tripping up my own understanding of loops), as much as something that often happens in seconds. I’m a toddler; I touch my hand to a hot stove. It burns me. I learn something. Much of what we call learning comes through 1,000s upon 1,000s of these tiny learning loops (except in other fields we call this“pattern recognition”).
Okay, back to Daniel Cook’s article. Some excerpts:
Loops are very good at building ‘wisdom’, a holistic understanding of a complex system.
Hmm. Sounds like someone learning to use a new tool.
The player ends up with a mental model that contains a thousand branches, successes, failures and nuances that lets them approach new situations with confidence.
Loops work to teach us a system. They build confidence. And, if you look at a traditional board game like Chess, it’s almost entirely made up of loops (no arcs).
In the pre-computer era, games dealt almost entirely with loops. The light arcs that games like Chess or Monopoly contained served the highly functional purpose of triggering a player’s mental schema. Once that setup payload was delivered, the games focused almost entirely on loops. One could easily claim that historically the term ‘game’ was used to describe an entertainment made predominantly of loops.
I can confirm (from recent experiences, ahem), that chess is indeed a series of loops: The basic rules, yes. But then, chess patterns: Two Pawns Fork. Rook Double Attack. Relative Pin. And so on. And if your opponent (in this case my son) has gathered more loops than you, you will lose. Every time. Not that I’m bitter or anything. But hey… Loops. They make you smarter!
Contrast this with more modern games that have a strong narrative element:
With the advent of computer games, designers started mixing more arcs with their loops. Adventure games, game endings and other narrative elements became more prevalent. There are strong cultural and economic reason why this occurred at this period of time that are not strictly an inherent function of the computer game medium.The primary driver for the proliferation of arc-based games is that they fit nicely into the existing retail business model. Over the past 40-years, the dominant way you made money off media was to sell the customer an arc, be it a book, an album or a movie. Once they had consumed that, you sold them another one. With a large enough portfolio of games (typically managed by a publisher), you’d get a reliable stream of revenue.
Okay, so those are a few highlights from this amazing article. Definitely check it out, as I’m certainly not doing it justice! It’s a bit of evergreen wisdom.
Okay.
You might be asking, what does this have to do with [THE WORK I DO]? Chances are, you might be working on more of a “sandbox” tool, comprised of 100s of tiny loops, and loops within loops. And occasional arcs. And loops within arcs. All of which are described in Cook’s article. Kind of like… Minecraft (sorry, I have to slip this in!) where you discover all these things you can make from the stuff you gather, and… so begins a journey of crafting and imagination.
Something about this perspective… I dunno. It got me thinking.
How we might approach a project differently if we thought about things through this ‘loop’ mindset? And yes, as I’m writing this, it seems a bit like the “When [x] I want to [y] so I can [z]” job story phrasing, though I’ve never quite seen these mad-libs statements as a learning loop (and, I have trouble imagining this mad-libs JTBD phrasing being very relevant to something like the Super Mario examples shown in the video above!).
And the more I think about the bulk of my work — future, current, and past — as a collection of learning loops, any of which can combined into a big loop or an arc, it starts to help me see user experiences and customer journeys in a different way. I have a different frame. A more powerful frame!
Let’s take a visual collaboration tool like MURAL as an example (easy for me to use as an example, as I work at MURAL and think about this stuff every day!).
- The first time you add a sticky note, that’s a learning loop
- The first time you learn how to move, pan, & zoom around the canvas, that’s a learning loop
- The first time you participate in a voting session, that’s a learning loop
- The first time you run a voting session, that’s a learning loop
- The first time you find and add an icon to the canvas, that’s a learning loop
- The first time you figure out how to celebrate with confetti, that’s a learning loop
These tiny moments of interaction do not happen in any specified kind of sequence, and some may never happen at all. But, as a user of this system, you accumulate these loops over time and begin forming a mental model of how things work. Loops are a bit like skills we pick up. Example: I’ve used Photoshop for years, and I’ve learned to do all sorts of amazing things. But, I also know there are a ton of very basic things I’ve never learned. What’s more, other friends who learned Photoshop over the years picked up a similar but different set of skills. My point? While there’s a certain amount of very basic loops we figure out as a baseline for working in these tools, beyond that, what we learn may vary wildly from person to person. But, every skill we pick up along the way teaches us a bit more about this system. And, makes us more proficient at that thing. At this point, I can’t help but think of Kathy Sierra, making awesome users, and getting past the suck stage:
Oh, and look: It’s a learning loop!
“Leveling Up” then—in almost every software application—is all about experiencing and collecting all these loops. Loops then are combinatorial, in that every new loop can be combined with previous loops, leading to an exponentially growing number of possibilities (cue up images of a giant LEGO bin, where every new LEGO brick is a new loop, and can be combined with other bricks, er, um loops for near limitless possibilities).
Loops.
Loops and Arcs.
Thinking in this way allows us to let go of a specific journey or sequence (“This is how ALL people will learn to use Photoshop!”), and imagine dozens of scenarios and possible sequences in which these skills can be learned. This doesn’t mean there aren’t more fundamental skills that other skills build upon, but we can let go the tyranny of how, precisely, a person will move through a system. We’re free to zoom in and obsess on these loops, which does two things for us:
- Approach the design of a system as the design of these as small but significant moments of learning.
- Consider the many ways these loops might be sequenced, with the exact order being less important.
In visual terms, we go from this kind of constrained thinking…
…to something that can be mixed and remixed:
Sequence then, for experiences where sequence can vary widely, takes a backseat to the discreet learning moments.
And, that’s it. That was my initial thinking.
I could stop here, satisfied that I’ve found a preferable alternative to the linear paths so prevalent in customer journeys. Arcs and Loops.
Arcs. And Loops.
Except, except… there’s more!
Act 2: Terrain
One of the true joys of my job is getting to mix ideas with brilliant minds such as Erik Flowers. For the uninitiated, Erik is co-founder of Practical Service Design and was my first hire onto the Design Strategy & Innovation team at MURAL. Oh, and we’re both enormous geeks who have way too much fun at work. 🤡
Anyway, after being asked to create a customer journey map at a particularly high-altitude for the company, we both kind of glanced at each other, with the same unease at what was being asked of us. While Erik has been teaching folks about customer journey maps and service blueprints for years, we share the same perspective that many things aren’t suited for these widely popular linear artifacts. In this case, using MURAL isn’t a journey that someone goes through. There are any number of entrance and exit moments, and 100s (1,000s?) of possible ways you might use, or never use, this very creative tool.
So, here we are at work, feeling the same unease. Finally, a reason to share everything I’ve been thinking about Arcs & Loops. Rather than accolades and praise (though may have been a wee bit), Erik started talking about Terrain.
Huh?
At this point as you’re reading this article, I strongly advise you pause, and go read the article Erik shared with me:
- My first observation after reading this was about how we both—independent of each other and 5 years apart—are using Super Mario Bros to think about service design, though his example is quite different.
- My second thought was that Erik was saying if you blur your eyes enough, there IS a linear pattern; that’s not necessarily his point.
While Erik never actually uses the word ‘terrain’ in that article, what he’s describing, and has described to me since is the missing, third element, in our new way of thinking about service design: Terrain.
Think of terrain as the environment or ecosystem in which all players play. It’s the sandbox itself. If there’s a national park with dozens of trails (Erik’s example), the terrain is the entire park itself.
Here’s the crux of Erik’s article:
If hundreds of thousands of visitors from around the world go on that hike, who is the persona? There isn’t one. I don’t mean “there isn’t one,” but there isn’t “one”, no singular experience to focus on. This is true for any UX project, but I want to focus on where the persona exists; the landscape they traverse.
What Erik and I have discussed since is the role that we play designing the landscape or terrain—through which people traverse. Or the sandbox, to use my favorite term. In fact, we view our role as designers in a slightly different way from most: We think more about designing the terrain through which people move and interact, rather than designing for the person, directly.
🤨
Let me explain…
Actually, I asked Erik to explain terrain to me, and here’s what he wrote:
Think of terrain as the set of tangible touchpoints in the experience, software, or real-world, that are available for customers to experience. If you owned a little movie theater, your terrain is your parking lot setup, your ticket booth, your lobby, the amount of bathrooms, which arcade games you have, the seating, which projector you own, etc.
If you mapped the ‘terrain’ of your movie theater and found you have a film projector, but you want to show Marvel movies which are digital, you will need to change that terrain if you want to play digital movies.
He went on to share a second example:
You buy an old cafe that was going out of business, but you want to save it. All the chairs, kitchen equipment, type of books, old jukebox, faulting lighting — that’s your terrain. That is what you “have” to work with, and you can either fix things in this cafe’s terrain, or create net-new terrain by buying new chairs, better booths, new lights, etc.
Mapping your cafe’s terrain would tell you that the 240v Hobart frosting mixer you want to plug in won’t work because you only have 120v plugs and you don’t even have 200amp service — so you can’t add any high-amp kitchen equipment. You will need to now go and get the electric company to upgrade your mains so you can then run new plugs for the bigger stuff, etc etc.
Terrain. Nothing to do with the persona at this point since if you want a big frosting mixer, you already have decided you’re doing custom wedding cakes — now fixing your cafe to accommodate the JTBD of your customer is irrelevant because 240v plugs are generic — your terrain cannot support the job you want. So, either fix the terrain (new plugs), or change how you want to serve the JTBD (sell things that don’t require bulk frosting).
This second example got me thinking about the ‘terrain’ in software products as more than the surface area that people experience directly — the features and functionality we have available to us—but also the invisible stuff that happens behind the scenes: The tech infrastructure, the internal company culture and processes, the web of partnerships and integrations, the APIs you make publicly available, and so on. Which is perfectly aligned with (and a different way to view) Service Blueprints. Terrain is just the blueprint.
Time for another article by Erik (this is a non-blocking article — you can return to this one 😉):
In our slack thread on this topic, Erik shared this tidbit with me:
I think the word terrain came about after so many times having to re-explain the blueprint’s purpose. So I would reckon service blueprint is functionally the same as what I’d call a “terrain map” now in 2021.
Terrain is just the blueprint.
The Movie theater. The Cafe. Software.
Let’s look at one, final example, to explore what’s intended by our use of the word terrain:
If a game like Minecraft is one giant sandbox, in which we can do all these creative things, this terrain did not happen by accident. The game space has been intentionally designed. Things were considered, and probably weren’t the result of happenstance. For example: There are rules governing how much of each resource might be generated, how biomes get generated, how long it takes to mine different resources, the physics of this imagined game place, how many and where diamond blocks are generated, and so on. And these rules, in turn, ‘allow / enable / block / discourage / encourage / etc.’ various behaviors. I’ve occasionally wondered why certain things are allowed, while others are not, and what early learnings or opinionated design decisions governed the shape of the game we all know and love. For instance, Minecraft has half-blocks slabs, which are useful for all sorts of things; but… you can’t—without adding a mod—create a vertical half-block slab (which apparently was a very intentional design decision). Sorry. Nerd moment.
So… slabs, digital projectors, 240v outlets… these are details of the terrain that are very much designed and over which we—as ‘designers’—have control.
I’ll add that all this thinking about designing the terrain fits snugly with the personal growth journey I’ve been on for many years now, and the conclusions I’ve reached about designing the ‘facilitating structures’ in which people work, play, build, and learn. (For a different take on these same ideas, check out my writings on Facilitating Structures, or my most recent article on generative features. These articles are both more about designing (1) the space within or (2) the objects with which, people play.)
Okay, so that’s terrain. Let’s put all this all together…
ACT 3: Putting It all Together
If a game like Minecraft is one giant sandbox, in which we can do all these wonderfully creative things, that’s the terrain. But, what about that first moment you learn you can hit a tree, and it’ll give you wood, as a raw material? Or the first time you learn that creepers are bad and will explode if they get near you?
These are the loops—the tiny moments of learning. The first time you die (or almost die) because of a creeper, you learn that ‘Hmm, maybe I’ll avoid creepers in the future!’
And then we have arcs — the hundreds (or near limitless number) of ways to string together these loops we’ve collected. An example:
- Hmm, if I get wood by punching this tree (learning loop),
- …I can make wood blocks (learning loop),
- …which I can use to make a [crafting table | sticks | chest | slab | stairs | button | …] (learning loop),
- …which enables me to make a [wooden pickaxe | wooden sword | wooden shove | wooden hoe | …] (learning loop).
- With a wooden pickaxe, I can mine [stone | coal | gravel | …] (learning loop),
- …which I can use to make a [stone pickaxe | stone sword | stone shovel | stone hoe | …] (learning loop),
- …which lasts longer (learning loop),
- …and is faster (learning loop)
- …compared to a basic wooden pickaxe (learning loop).
All these loops — there was a moment you learned each of them for the first time. And the sequence of loops I just described to accomplish a particular job, in this case creating a stone pickaxe? That’s an arc. That is one of 1,000s of possible arcs. I could string together many other ways to sequence the loops you acquired. And more loops unlock more combinations which means more possible arcs; the possibilities grow exponentially. And all of this takes place within the designed space that is the game, the terrain.
Whew.
One Final Thought
There’s an order to how I just described these things:
- Terrain.
- Loops.
- Arcs.
Can you spot it what is?
.
.
.
Psst. It’s about control.
If you’ve been in UX or design for a while you’ve probably encountered the idea that “we can’t really design experiences, we can only design for experiences.” Yep. Pedantic perhaps, but accurate. I could suggest that you eat at my favorite restaurant; however, even if they delivered the same stellar experience I’ve had every time, your experience won’t necessarily be the same as mine. This is the subjective part of all our efforts that is beyond our control.
This is where this ALT-X model explains why: All we can control is the terrain (which includes the objects). We can sort of design the learning moments (loops). Arcs? They are more in the hands of the users. Beyond that, it’s all subjective and very much beyond our direct control.
It might help, at this point, to share this handy visual we came up with:
This ^^^^, by the way, is the money shot you were waiting for. This one visual sums up everything I’ve shared above, with some tidy icons for easy recognition and recall. And then you could put all this ‘together’ into a handy illustrative visual like the one below:
Back to the whole ‘control’ topic.
Presented differently, this could be a mic drop moment. Why? Notice the focus of our design: It’s not the humans in the system, it’s the system itself. The object of our design is the terrain and loops. In support of people and jobs, yes. But, this is not ‘human-centered’ design in the sense that I usually see HCD practiced. People are actors and agents playing within a designed system. We are designing the environment.
There’s plenty more to unpack. I’m still learning about what makes a good (or not-so-good) learning loop. And I haven’t even mentioned the supply/demand angle. And there’s stuff we’re picking as we put this model into action—on a real project! But, I wanted to get this idea out, while the dust is still flying in this new terrain. Enjoy!
