Un-Sucking the Touchpoint

A while back I was speaking at a conference and I described the role the touchpoint played in helping make sense of a cross-channel service. After the talk, perusing the backchannel for the good, the bad, and the ugly on my talk, I came across this tweet…

Sounds backhanded, but I took this as a compliment. I completely understood where this sentiment was coming from: oh great, another piece of buzzword jargon to integrate into my work.

It’s hard not to integrate proprietary words into our work discipline from time to time. When used internally, they create a shared vocabulary as we collaborate to put theory into practice. When used externally, they can mystify unsuspecting executives or clients in a cloud of abused, disdainful jargon.

So I took this to mean that I went beyond the jargon by framing it as a proper part of our design vocabulary. Success!

Evolving the Touchpoint

The touchpoint has been around for a long while, particularly in thinking about brand marketing and service design.

But as design disciplines and approaches collide—from customer experience, to service design, to experience design—and we start horse trading terms, methods, and outputs, some of these concepts are given new life. For me, the touchpoint has become a central way to view designing moments across increasingly complex journeys. Whether it’s an expanding digital product ecosystem, a cross-channel retail experience, or a complex, intangible service experience.

Defining the Touchpoint

A touchpoint often gets conflated with channel (or platform, or medium). Often referred to, for example, as the “phone touchpoint” or the “web touchpoint.” But a touchpoint is not a channel, and a channel is not a touchpoint.

Historically, touchpoints have been defined in three types: static: such as packaging or an advertisement; interactive: a website or a kiosk; and human: such as a sales rep.

But as a designer, this didn’t tell me much qualitatively about the touchpoint from a human-centered view. It wasn’t very actionable. Being a point of contact with a brand wasn’t enough.

It was time to rethink what it meant to be a touchpoint. What defined a touchpoint in a way that gave us a deeper understanding of that “point of contact,” and was more actionable from a design perspective. When collaborating with my then-colleagues Todd Wilkens and Paula Wellings on a workshop specifically on orchestrating touchpoints, we reframed the touchpoint hoping to have a more useful and concrete definition. For me, in my work, it’s stuck ever since.

A touchpoint is a point of interaction involving a specific human need in a specific time and place.

Now we’re getting somewhere.

Interaction—be it a conversation or an interface control, I can design an interaction.

A specific human need—I now know what is driving these interactions. What am I supporting?

A specific time and place—As a designer, I need to understand the context surrounding that need.

It became clear that a touchpoint is a moment in time. I want to design to support that moment in time. More specifically, a touchpoint is meeting that need through delivering on the company’s value proposition in that time and place.

Death to Features

I’ve been working with, and designing for, “features and functionality” going on 15 years. In the last few of those years I’ve become increasingly disdainful of using those words as part of my design vocabulary. First, the moment you start thinking about experiences beyond the context of a single digital product, such as a software interface or website, it becomes limiting. Even new cross-channel digital ecosystems—from Netflix to Nike+—start to deliver value that can’t be described simply through the lens of adding or modifying features. Second, there’s a lot of baggage with the word feature, and it tends to mean different things in scale and scope to different people within an organization, lacking anything human-centric to characterize it.

This is another reason why I’ve adopted touchpoint as a better way to express a capability that the product or service might need in order to address that specific human need in a specific time and place.

It’s more scalable than feature—a touchpoint might be a singular microinteraction within a single channel, or it may be a series of actions crossing multiple channels. Just by the fact that a touchpoint has “touch” in the word makes it more human-centered, supporting the mental model, rather than “feature” which feels very rooted in the implementation model.

A touchpoint is very much like a user story, but not confined to the context of an agile development environment (though we often articulate touchpoints in a similar way).

Most journeys, like most systems, are defined by the flow of information. Wayfinding, product descriptions, explanations of health services, data visualizations, asking questions of a customer service rep, typing in a search engine, talking with an advisor, giving billing information for a purchase, favoriting a post—the list doesn’t stop. Most moments on a journey are defined by this flow of information. But now more than ever, we aren’t just passively consuming the information, but interacting with it (a conversation, gestures, voice commands).

A touchpoint is an information object wrapped in an interaction.

What are the interactions that must occur to support the consumption, flow, or transaction of information in that moment in time?

Regardless of scale and scope, touchpoints provide something better to qualitatively judge whether I’m meeting the needs of that end-user. If you look at that moment you interact with an end-user or a customer, you want that moment to be:

Appropriate (context + culture)
Relevant (meeting needs/functional)
Meaningful (importance/purpose)
Endearing (subtle, playful, creating delight)

And lastly, whichever of these principles a touchpoint meets, it should be connected (seamless in the journey).

In this respect, every moment within the journey, be it a product ecosystem or a complex service experience, should justify its existence through its own value proposition. Does it meet one or more of these principles, and does it connect seamlessly with the other touchpoints and moments? Setting a qualitative bar for a touchpoint ensures its relevancy in the journey.

Only Good Touching

While it may be jargon, in the end, touchpoints are a more context-pliable way to express a system’s ability to meet a specific human need in a particular time and place. When mapped, they can be moved around and connected with other moments. En masse they can be orchestrated. It can be understood by marketing groups, development teams, product groups, design teams, and define a unifying understanding of the goal: “at this point in time, how do we meet the need of this person?”—a shared vocabulary around which this cross-functional team can design to support a more holistic journey.