If I were giving my talk on the differences between design researching service design problems versus UX problems today, this would be my talk:

*

A confession: not long ago I thought of service design as just one variety of experience strategy, specifically an experience strategy that defines the experience of a process, a connected series of events experienced specifically as a series of events, perceived as a story.

I no longer believe this. Service design is a form of design strategy, that includes experience strategy and relies on it heavily, but service design is not reducible to experience strategy. I will explain why shortly.

It will all come back to a somewhat peculiar definition of design I subscribe to: that design shapes hybrid systems comprising people and things — people being understood as free-willed actors, and things as algorithmic, rule-based actors. In design, free-willed, experiencing people are part of the design and we try to give people good reasons to freely choose to cooperate with our designs. An implication of this definition is that a design only kicks into action and becomes what it is when a person interacts with it, producing an experience.

(Engineering, in contrast defines its systems to carefully exclude the people-elements, or if people are an unavoidable element in a system to treat them as predictable rules-following elements, either by imposing rules through policy, logic, commonsense or written instructions, or governed by peculiar psychological rules that can be discovered and used, or just to be irrational noise which is someone else’s problem.)

(I’ll remove this from the talk, but here’s my own inflammatory editorial: This is why only hacks claim to design when the people component is present in the process only as an imagined “The User”, or a trail of past behaviors synthesized into some sort of abstract behavior-producing entity to game into compliance with one’s own schemes. This sort of thing makes me super-angry, especially when I suffer from it as a user. One of the more catastrophic conceits of the 20th Century was the equating of rigor and being sociopathic, that is, attempting, on principle, to cleanse every “scientific” question of subjectivity, in pursuit of objectivity. Much of this stunted philosophy is still with us today, and it seems to be enjoying a sort of renaissance.)

Before looking at the crucial difference between designing experiences and designing services, let’s take a minute to clarify the relationship between time and experience:

Though all experiences take place in time, the “object” of the experience is not always a process where time is foregrounded.

The experience may be of having or using a physical artifact, or a digital artifact. It may be of being inside an environment.

The experience may also be of some user-directed activity with its own object, where the designed artifact is as inconspicuous as possible within the experience. This is how the design of tools ought to be approached.

(By the way, if you are into philosophy, and this line of thought captures your imagination a school has developed around our relationships with things, which is directly relevant to design: Postphenomenology.)

And yes, in service design, a crucial element of the design will be a customers, patient’s, employee’s experience of a connected series of events, and the flow of time is a big part of the perception of the experience. This is why we are always gathering, analyzing and documenting experiences in the form of stories and journeys.

And obviously, our overarching experience with many objects — say, a car — is a mixture of nearly every kind of design we mentioned, a physical thing we look at and enjoy, an environment, a tool that might disappear into our driving, and, sometimes, unfortunately services to help us buy, fuel, maintain, modify and eventually sell the vehicle. Looking at the car in a long line of touch-points from start to finish is good experience design, and until recently, I would have said this was service design.

Notice, I differentiate touch-points, which are relatively short spans of time and lines of touch-points. If you’ll forgive the coinage, I propose we call these connected touch-points touch-lines, at least for the purposes of the big point I want to make.

The big point is this: service design conceives a service as a mesh of intersecting experiences — of woven-together touch-lines. Let’s call this a touch-plane. When we look at a service through a service design lens, we see the delivery of the service, not as a mere means to one actor’s experience, but a matrix of intersecting experiences, most of which are processes experienced by a person — all of which must be designed properly if the service is to function as intended. A customer’s journey criss-crosses multiple employee’s journeys, which cross-cross manager’s, vendor’s, regulator’s, etc. journeys.

Obviously, we cannot design every single touchpoint for every single actor in a service, but when designing services we do not automatically choose and prioritize one actor’s or user’s experience as the end and relegate everything else as a means. We do what designers always do and make the smartest-possible tradeoffs across all parts of the experience plane.

So it should not be hard to figure out how this long roundabout discussion comes back around to the key question: what makes service design research different from UX research? If research for experience strategy clarifies what one actor’s/user’s end-to-end experience is, and requires deep knowledge of that user’s context, in order to define the design problem in one or multiple touch-points, service design requires study of multiple actor’s/user’s experiences and understanding how these experiences intersect and interact across a touch-plane and looking for opportunities to improve the experience for everyone involved in and experiencing the delivery of the service.