• 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…

    tweet about touchpoints

    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.

    There are 13 thoughts on this idea

    1. Pingback: Un-Sucking the Touchpoint | Adaptive Path | Fred Zimny's Serve4impact

    2. Pingback: The User Experience Three. Handpicked 12/03/2013 - UXPin

    3. Pingback: My Notes on “Unsucking the Touchpoint” by Chris Ridson | walkerux

    4. Pingback: Worthwhile Reads 7.12.13 | סיפתח

    5. Richard Dalton

      Nice thinking Chris. Here’s a variant on it that i’ve been noodling:

      A piece of channel-specific functionality that supports a single point of engagement between a person and an organization.
      e.g. a web-page, a mobile screen, a letter, an email, a phone call.

      The orchestration of multiple touch-points (possibly from different channels) simultaneously or sequentially experienced by a person when engaging with an organization.
      e.g. the flow from a home-page, to a product page, then a phone call to ask a question.

      The totality of the touch-points and interactions experienced by a person; how they feel about it during the experience and how they remember it afterwards.

    6. Pingback: Un-sucking the touchpoint | Ideas

    7. Chris Risdon

      Thanks for the comment, Richard! We’re not too far apart in our thinking. The one thing I found, personally, lacking in the touchpoint definition you list was more context. Can we make the touchpoint carry a bigger load by making it represent intent?

      To me a “phone call” as touchpoint isn’t specific enough to make sense of it (and design to support it). A phone call around acquisition and a phone call around servicing could be so different, meeting different needs in specific time and context, that I feel (and propose here) they could be seen as different touchpoints, because of that intent and context.

      But the main reason I wrote this is because I think “touchpoint” can’t be avoided (and is a valuable way to think), so I wanted to start just such a dialog to evolve our shared understanding. In other words, we should chat more!

      – Chris

    8. Richard Dalton

      I totally agree Chris, I didn’t mean to imply that a generic “phone call” was a touchpoint – rather that phone calls can be categorized (by type) as touchpoints. So as you say, a “balance inquiry” type of call would be a touchpoint, a “money transfer” type of call another, etc. and the same with touchpoints on all other channels. Each webpage (or contextually related cluster of pages – a linear flow for example) would be a discrete touchpoint, etc.

    9. Jonathan

      Lance Bettencourt writes about users wanting to complete jobs when they interact with a product or service. I can see some similarities between Chris’ definition of touchpoint and the intent behind changing the perspective of the user attempting to perform a job. Are you familiar with Bettencourt’s work? If you are, do you see the same overlap, or do you see more dissimilarities than similarities?

      Great article, by the way! Got me thinking

    10. Pingback: A kiss is the ultimate touchpoint | Crossroad Competence Lab

    11. vidhya

      Fitting article – crystal clarity in driving home what I have wrestling with. thank you Chris and the comments were illuminating too:) thank you richard and Jonathan.

    12. marco

      Thank you Chris. I think I got the difference between touchpoints and channels, but I still do not understand the difference between touchpoints (the way you explain them) and steps (single moments that compose a journey).
      Can you clarify this point as well?
      Thank you so much,

    13. Joy

      great article. very insightful and got me to rethink about the relationship between the end user and business goals. However the images seem all gone, and none of them actually showing up… Could you please fix this?

    Add a Thought

    Slide to Submit

  • Close
    Team Profile