I recently cooriginated a new kind of design artifact that seems to be taking off in the service design world. I call it “experience mesh”.

The purpose of experience mesh is to represent a multi-actor design without taking any of the actors to be more primary or central than any others. This is crucial, because the main advancement of service design over older user-centric or customer-centric or any other mono-centric approach to design is that service design is polycentric.

Polycentric design does not focus only on one actor, but looks at the experiences and especially the interactions between multiple actors to ensure that all actors are having a good experience and are interaction with one another in mutually beneficial ways.

What has been bothering me about the main design deliverable of service design, the service blueprint — and what inspired the framing of the problem that led to experience mesh — was that a blueprint is only partially polycentric.

The very format of the service blueprint has been impeding service design’s evolution beyond the single actor perspective. Though service blueprints do represent multiple actors, the whole thing is organized around one protagonist’s storyline (usually the customer). The other actors delivering or supporting the service are viewed only in reference to the protagonist, appearing and disappearing on the frontstage and entering and exiting the backstage, called into existence by the needs of the protagonist.

But much of what is most decisive in the service experience of these other actors happens completely outside of a blueprint oriented around a customer. For instance, a call center agent who materializes in a middle of a blueprint, when a frustrated customer calls to ask about her bill, also arrives on the scene with a backstory of his own. That morning he attended a team meeting, where he was exhorted to reduce call times and to increase up-sells and cross-sells. The scorecard he keeps on his desk by his keyboard, shows that his numbers are down: no commissions this month. Also, he is sitting in a cavernous room with agent stats (including his) projected up on the wall the size of a movie screen, and he is surrounded on all sides by teamwork posters, performance award trophies and other motivation aids. These missing moments and touchpoints will affect how he feels about his life throughout the day and the quality of his interaction with the customer when their storylines eventually intersect. Longer term, they will help determine whether this call agent is inspired to stay at his job and jazzed about helping customers, or whether he ends up ground down to robotic apathy, looking for opportunities to quit as soon as he can. These omissions from the customer-centric blueprint might very well represent the problems most needing service design interventions.

An experience mesh keeps the customer’s, agent’s and all other actors’ storylines complete and unbroken, loosely weaving them together to show how the overall design of the service impacts the lives of everyone involved. Where the storyline threads converge and loop together, both actors are frontstage to one another in an interaction. When their storyline threads diverge (and perhaps loop with storylines of other actors within the service) they are backstage to one another.

But every actor’s experience with the service is shown in its full continuity and placed within the scope of the service design. Everyone has a continuous, unbrokenstory. Nobody is disappearing and reappearing in service of one primary actor who is placed at the center of the service design. Everyone is viewed as the center of an experience, which can merge and harmonize with each interaction, all of which can and ought to be designed as a single multi-actor system: this is polycentric design.

Experience mesh is still imperfect in execution. I think it might be one of those artifacts that benefits from the flexibility of digital tools, and might find its ideal form when it sheds the constraints of its physical paper and tape origins. But the problem experience mesh is meant to solve is now framed, and as John Dewey said, “a problem well put is a problem half-solved.”

In the 20th Century everyone aspired to be scientific. Unfortunately, the image of science and scientific knowledge was distorted by rationalist fantasies, and attempts at scientific practice were encumbered — and, in fact, sterilized — by misnorms.

In the 21st Century we we are off to a good start, aspiring to be designerly. However the image of design is also distorted and many key design practices are either omitted or falsified. Too much emphasis is placed on “creativity” and too little on the social conditions productive of (and produced by) effective design collaboration. Design practice is still a romantic antithesis to 20th Century misconceptions of science and engineering — which bog design down with the same sterilizing burdens that has plagued scientism.

What is needed is a better synthesis of science/technology/engineering and design that supports a more productive (or should I say “serviceable”?) redrawing of the definitional boundaries, divisions of labor and collaboration, and organizational relationships between the disciplines associated with deploying technology for human purposes.

When you work on a project with Harmonic it is very likely you will have the opportunity to participate in design research. This is something many people have never done before. We find that some people are either curious or anxious about what they can expect.

The following is a list of questions I’ve been asked more than a few times, and the answers I’ve given that seem to help people new to service design research feel informed and prepared, expressed in my own voice. Some of my fellow Harmonicas have expressed concern over how some of my answers are worded, so please know that anything here that strikes you as overstated or impolitic has likely been left in despite the advice of my colleagues.

Why are we doing so much research?

Short answer: Understanding the people involved in the service is, by far, the most important thing a team can do to ensure the success of a service.

Services are provided by people, for people. If you understand the people who receive the service, provide the service, and support the service behind the scenes (what we call in general terms the “actors” in a service) our chances of designing a service people value is far more likely. Our goal is to design services that people find useful, convenient and emotionally satisfying — the kinds of experiences that generate brand loyalty.

But people are surprising. Often what we think we know about them (even what we think we know about people in general) is wrong, and in ways that obscure real opportunities to improve their lives. Having a unique understanding of people gives a team access to new perspectives, new ways of thinking about serving them and can drive innovation and differentiation that is not only different but remarkable and relevant. (We call this “precision inspiration”.)

What kinds of research do you do?

To put it in the simplest terms, we think of our research in terms of foundational research (which helps us understand the actors who receive the service and those who provide and support it, which includes their needs, attitudes, behavior, contexts and worldviews), generative research (which helps us discover opportunities and conceive new ideas for improving service experiences), and evaluative research (which helps us see what ideas are most valuable to actors and how they can be made even more valuable). All these methods are qualitative, which means they are conducted with small numbers of people with a goal of gaining deep insights into not only what they do, and how they do it, but why they think, feel and behave the way they do. Most of the research we do contains elements of foundational, generative and evaluative research, but toward the beginning of most projects, the emphasis is on foundational and generative research, so most of what will be discussed here will focus on these.

Why do we need to do research with our own front-line employees?

Often when a company’s services fall short, it has little to do with the competence or attitudes of the employees who deliver the service. It has much more to do with how employees are evaluated or compensated, policies that limit what they can do for customers, or require them to do things customers don’t want. Or employees lack information needed to help. Or the systems they use get in their ways. Or employees are starting from behind, trying to salvage an already damaged experience, and (in extreme cases) numbed from constant exposure to customer anger. In other words, often a bad experience is not the employees’ fault, or anyone’s fault. The service has just organically evolved into something that isn’t working out for everyone.

And more often than not, no one person understands every factor that is contributing to the problem. The people on the front line who know the problems well are not always in a position to change the situation. And the people with the power to make changes are often far from the sites where the service is delivered and are operating with incomplete and sometimes incorrect information.

We do research with employees to help understand the big service delivery system, so we can find ways to make everyones’ lives easier. And we try to talk with them in ways that encourage them to tell us the full, unfiltered truth as they experience it, which is why we favor individual sessions, or sessions with small teams who collaborate together, especially when we are talking with front-line employees. We can only get the full truth if they are relaxed enough to speak freely and naturally.

How do we decide who we are going to talk with?

In order to ensure we are designing a service that works for everyone, we talk with a representative cross-section of people who use or might use the service we are designing. We are interested in both what they have in common, but also any important differences that might need to be considered.

Using what we learn from members of the client team, stakeholders we interview and available existing research we study, we list all the factors that might change the needs or attitudes or use contexts of the people involved in the service. These are developed into criteria we will use to determine the kinds of people we need to talk to.

Then we develop quotas for each of the criteria. We try to get at least three participants who have each of the criteria we identify, so we can get a sense of how that factor might affect the service. We try to get three because this is the minimum number where we can tell the difference between idiosyncratic answers and typical ones.

These quotas are used to recruit our research participants.

Why do we call them “participants”?

We call the people we invite to our sessions “participants” because they play such an active role in the session. Participant might even be an understatement. Effectively, we are asking them to play the role of teacher, and to help us understand who they are, what their life is like, and what they need and want in a service. We do design activities meant to help them do this teaching, but these are tools to aid the collaborative process of generating understanding.

Aren’t your sample sizes awfully small?

Typically, we will talk with twelve to twenty-four customers and with the same number of employees. To a person accustomed to marketing research, yes, this looks like a puny sample. The small samples make more sense, though, when you realize that what we are after is not only answers to questions — questions we think are the right ones to ask — but an understanding of how people see the world. This can sometimes help us see new non-obvious questions or even help us see that we have been asking the wrong questions!

The kind of research we do, especially early in the process, is designed to help people teach us about their lives, their needs, their way seeing the world, the significance of the service and its context to what they care about. This is very different from surveying them or asking them a list of questions. Imagine if you were learning a new subject at school, but instead of allowing the teacher to explain the subject to you, trying instead to survey the teacher to get the factual data you think you need to pass your tests. To allow someone to teach it is important to allow them to present information in their own way to convey the material in its own terms. (I like to believe we use the word “subject” to refer both to academic subjects and human subjects because we come to understand them by allowing ourselves to be taught.)

Instead of asking our participants a long list of question invite people to tell us stories, to help us understand how they see the world, to help them communicate what is most relevant to them, and in general to help us understand what questions we should ask them to learn what we need to know to design the best service for them.

By the time we are done with the first round of research, we have the information needed to design much better quantitative research. If you start with quantitative research, you’ll have a bigger sample, but you risk having statistically significant answers to insignificant, irrelevant questions.

How do we decide what we will do in the sessions?

We start our process by identifying the research objective: what does the research need to do in order to support the design? This is often mostly a re-statement of the project goal. We need to inform the design of the service by understanding all the people involved in it, their lives and how they might engage the service.

Then we identify areas of inquiry. In order to achieve the research objective, what will we need to learn about. Areas of inquiry are not questions — they are topics the team will ask to be taught about in various ways.

Once the areas of inquiry are defined and agreed upon, the team designs the research approach. It will include interview questions and interactive exercises designed to give the research participant opportunities to learn about the areas of opportunity.

The team then writes up a research protocol (sometimes called a “research guide”) and designs the materials used in the session.

It is important to note that the protocol is not a script. Some parts of it might be read like a script at some points, but the facilitator will use the protocol loosely to pace the session and to ensure the areas of inquiry are covered. But it is only a guide, and facilitators will often deviate from it. The goal of a session is to get the participant to teach, and that means keeping it conversational and giving the participant enough space to tell us things we might not have anticipated. Our sessions are designed for uncovering the unexpected — because this is where the biggest opportunities come to light.

Who from my organization should attend sessions?

Ideally, everyone would attend. Realistically, at least one person from any department or role that will be involved in shaping or delivering the service based on the research should be involved in the research.

We recommend this for two reasons. First, different roles notices different things in the sessions, and interprets them in different ways. Having a wide range of disciplinary lenses present in the sessions enriches the team’s understanding of what it hears.

Second, service design touches many roles throughout the organization. We believe people have a right to help shape their own futures. But pragmatically, it is a great way to build alignment, credibility, ownership and enthusiasm for initiatives if respected members of the teams who will contribute to the service were directly involved in shaping the service, and can explain why the service was designed the way it is.

What do I need to do to prepare for a session?

Generally, very little preparation work is needed. If you are observing a session the team will give you everything you need to know before the session. Often the team will schedule an orientation session to help everyone understand the purpose of the research and the flow of the session. Anyone who is playing an active support role will get additional training. Prior to each session the facilitator will remind everyone of what they need to know.

Generally, for in-person field research, everyone involved in a session will be given all the equipment they need. If the session is remote, you’ll want to bring a notebook and something to write with. We ask that you do not use your laptop for note-taking when conducting an in-person session.

What are the sessions like?

Typically sessions last ninety minutes, and are followed by a debrief that lasts between thirty minutes to an hour. Please plan to attend the debrief for your session, because this is a very important part of our process.

Normally, the session starts with an overview. The facilitator thanks the participant and explains the purpose of the session. The people attending the session are quickly introduced. Then the facilitator gives an overview of the session and sets the participant at ease by telling them that we are here to learn from them, that there are no wrong answers, that it is okay if they don’t remember everything and most of all to please tell us the full unfiltered truth about their experiences, and to not worry about hurting anyone’s feelings. We will sometimes joke with them and generally do whatever it takes to make them feel comfortable and ready to converse naturally with us. We answer whatever questions they have and make sure they have filled in the required release forms, understand the compensation and give us permission to record.

Then we usually start with an interview, leading with some easy warm up questions. We learn about who they are. We will sometimes ask them their opinion on something tangential and fun to answer. Where do they like to eat, or what is their current favorite service? Then we get background on how they use the service, what they value about it, how it compares to other services, etc. We also sometimes touch on their current brand perceptions.

Then we shift into a more interactive mode, and do some collaboration. Almost always will ask them to tell us stories that help us understand their needs, while we visually capture the story, step by step. We are interested in hearing about their whole experiences, not only the part where they might use the service. And we ask them to tell us not only what they did, but how they felt, what they were expecting, what they were thinking about, what they wanted to accomplish. We also might visualize their service ecosystem, inventorying the people, places, tools, and related services that make up their lives. Frequently the team will design other interactive exercises to help us get at needs, behaviors, attitudes and preferences.

Another activity we often do is show prototypes to participants and ask them to respond. By prototype, we mean any kind of artifact that allows the participant to imagine what it would be like to engage the service. It might be storyboards or screens, or we might ask them to act out service scenarios with us.

If all goes well, the facilitator will build enough rapport with the participant loosens up and feels free to express their feelings in their natural voice. We like to get these moments on video so we can show them to people who were not in the session. We want to help everyone in an organization relate to the humanity of their customers and the people who serve them, and to see the human impacts of decisions.

How do these sessions differ from pre-Covid times?

Online sessions are very similar to in-person. The big difference is how the activities are done. In-person, we are handing our participants the pen and asking them to interact with the materials. This is more difficult remotely. We are often using virtual surfaces, electronic sticky notes, and doing some of the interactions for the participants under their direction.

The dynamics are also a little different, especially for customers. When we do in-person session we often visit them in their homes, offices — in their spaces. We work hard to make them comfortable, but sometimes it takes a few minutes for them to get used to us being there. It seems to be a little easier to adjust to a video conference. The downside is there is a connection made in person, and insight you get from being in their space that doesn’t happen with the same intensity in a remote session.

The biggest positive tradeoffs are probably geographic flexibility and the simplification of logistics. With remote sessions it becomes affordable to recruit participants from many diverse regions instead of limiting sessions to a small set of locations. In-person sessions require a lot of coordination of people traveling to the market where the research is being conducted and ensuring they have transportation to and from the session location. Remote sessions remove most of this complexity.

Once Covid is overcome we return to relative normalcy, some of the methods developed to cope with the pandemic will stay in our toolbox and continue to be used to fit client needs and make optimal tradeoffs.

What am I supposed to do in a session?

There are multiple roles in a session. Generally, one person facilitates and one or more people assist. When we do sessions in-person we normally limit the number of people in the session to three, not counting the participant. Participants are not used to research, and they can get stage-fright if too many people are staring at them. With remote sessions it is possible, though not desirable, to have more attendees.

If you are assisting with the research, you will get special instructions and training from the team on how to use the research tools. With remote sessions we sometimes ask for help operating our virtual whiteboards. With in-person sessions we sometimes need assistance with organizing materials or operating cameras. It is never terribly complicated, and you will never be put in any situations for which you were not prepared.

The primary thing to keep in mind is that we are trying to create a conversational dynamic. This requires some conditions that we do our best to set up and maintain. What we do not want to happen is for the session to feel or look like a meeting where multiple people are talking together, and this tends to be the default unless steps are taken to prevent it. When the session is in-person, we usually try to arrange ourselves so the facilitator and participant are facing each other and others present sit to the side out of the direct line of sight. With remote sessions, we often ask everyone to turn off their cameras and microphones except the facilitator, until it is time to open the session up for questions.

Taking notes is very important. Write down anything that speaks to the areas of inquiry, strikes you as relevant to how the service should be designed, or surprises you. And if the participant says any great quotes, capture as much of it as you can, or at least jot down some of the key words and roughly what time it was said so we can find it in the transcript later.

Your notes will be useful during the debrief.

What should I know about asking questions?

During the session, try to hold your questions or comments until the facilitator prompts participants. It can be helpful to write questions down as they occur to you.

Sometimes the facilitator has a specific way to ask the question in mind. And sometimes the facilitator will leave more silence after a question than is comfortable. Trust the facilitator, and resist the urge to jump in and clarify questions, or to try to help the participant answer or break awkward silences. It’s hard to do, but it is important.

When the floor is opened for questions, try to ask open-ended questions. The trick is to start the questions the right way. Starting with “Can you talk to us about…” or “Please tell us about when…” almost always finish well. Sentences that start with “Do you…” or “Would you…” are risky. If you notice your question has devolved into a multiple-choice and you are finding yourself stringing together a bunch of “or” options, your question is on the wrong track.

The good news is you can always interrupt yourself and say “Actually, let me try asking this question another way.”

What am I supposed to do in a debrief?

After the session ends, the team will reconvene for a debrief. This is one of the most important activities we do during field research. The purpose is to capture what was learned in the session while it is fresh in everyones’ mind.

The debrief facilitator interviews the team on each area of inquiry, documenting what was learned in a format that makes it easy to compare findings between different participants.

Often there are disagreements or differing interpretations of what was said, and this is good. The discussions around differing understandings are central to the process and helps the extended team align on what has been learned.

One thing to keep in mind: A debrief is not meant to be an exhaustive compiling of everyone’s notes in a single document. The debrief is meant to be a summary of what the group learned. Someone not in the session should be able to pick up a debrief and learn who was interviewed and how much was learned from that participant about each of the areas of inquiry. The debriefs are a powerful tool the team will use during analysis.

How do we make sense of what we hear?

When the field research is done, the team analyzes the debrief forms and the outputs from the activities, supported by video footage and/or transcripts of the session.

The analysis is done partly in collaboration with the people who helped do the research. Sometimes we will conduct an internal team interview to outline the high level findings of the research. We then use the debriefs and transcripts to guide discussions and exercises to find patterns and themes in what we learned.

We will also compare the stories we heard and look for commonalities and variants which are documented in an experience map which visually documents the experience customers and others are having receiving and delivering the experience.

When possible somewhere toward the middle of research analysis the team will invite employees of the organization into the analysis process. We call this Research Open Studio. We show people our raw research materials, including the stories we gathered, and selected footage from the sessions. We share the findings in their current rough state, along with the questions we are asking ourselves, and bring them into our conversation so they can share the thought process and the excitement of discovery.

When do we get a readout?

Often within a few days of completing the research the team will send out an informal top-line summary of findings, and sometimes will include links to the debriefs. But the full presentation of what the team has learned usually comes at the beginning of the next workshop, when the research is digested and interpreted to identify opportunities to improve or even reinvent the service and to generate new ideas.

What do we do with what we learn?

The research outputs are designed for multiple purposes. First, they are designed to communicate what was learned as clearly and compellingly as possible, and to help the organization align around a single version of the truth created by the extended team.

The second purpose of the research outputs is to serve as workshop tools, to help with opportunity identification and prioritization, idea generation, concept assessment and concept prioritization. The experience maps, the themes we identify and the other artifacts generated during research analysis become ideation canvases workshop participants use to think about experiences from a customer’s or front-liner’s perspective.

Am I going to love research and want to be involved in it as much as possible in the future?

Yes.

I often get asked questions about the relationship between service design (SD) research and user experience (UX) research. The answer is very simple, but communicating that simplicity is not easy. This post will attempt the briefest, clearest answer possible.

Explaining the difference in the two forms of research will require briefly explaining the relationship between UX and SD, so let’s start there.

• User experience is  typically defined as the practice of designing digital touchpoints. Digital touchpoints are usually parts of a larger experience that extends beyond digital to non-digital touchpoints, such as voice, physical spaces, printed materials and broadcast media.
• When many kinds of touchpoints, including digital, are designed together to deliver a coherent experience (usually, but not always for a customer), this is known as omnichannel experience design.
• Service design extends omnichannel design beyond, by designing for every person (service designers call them “actors”) involved with receiving the service and delivering a service (customers and employees interacting “frontstage”) and with supporting the service behind the scenes (employees working “backstage”). Anything involved in the delivery of the service — whether it is a human actor, departmental or team structures, a front- or backstage touchpoint, a technology, a process or even a policy — falls within the scope of service design.

It can be helpful to think about the relationship in terms of design materials. Every design discipline shapes a certain kind of material to produce value for the people who use it.

• The material of user experience is digital media.
• The material of omnichannel design is touchpoints.
• The material of service design is organizations.

The differences sketched out above should set the stage for understanding six main differences between SD and UX research. Most of the differences are matters of degree, and of course, there are always exceptions.

One key point that should be noted is this: Service design does not in any way replace UX, nor does service design research replace UX research. Rather, service design helps UX do a better job of designing touchpoints that support the larger service experience.

Another thing that should be noted: None of the six key differences I list are matters of technique. The toolbox of techniques used in service design overlap with those of UX, with only minor variations in how they are used. A UXer attending a service design research session is unlikely to see any completely novel methods , but is very likely to be shocked by the breadth of material covered and the rapid pace of the sessions. They might feel anxious about an apparent lack of thoroughness. This is by design, though, and I hope that what follows (in #3 and #4) will shed light on why.

Difference #1: Who helps conduct sessions 

Because the material of service design is the whole organization, many people are involved in the design of a service. A typical service design may change organizational processes, IT systems, policies, physical spaces, call center scripts, even how departments are organized. To improve the chances these changes will be made, it is important that the people who will be making the changes (or will be affected by these changes) understand why these changes are worth the effort and discomfort. If people reject the research or dispute the design decisions, change will not happen. Alignment of understanding is absolutely crucial.

The best way to create this alignment is to bring as many people  along to help with the field research. Service design research is the ultimate alignment tool. When respected representative stakeholders from across the organization participate in research, witness firsthand how the service affects people’s lives, and contribute their own disciplinary knowledge and perceptions to the effort, insights from the field are deeper, more impactful, and more credible across the organization.

UX also benefits from client participation, of course, but can normally win sufficient alignment with far fewer people.

It is important to note that one of the most important stakeholders to include are UX designers, who will derive many of the same benefits from SD research as they would from UX research, or at least from foundational or generative UX research. (More on this below).

Difference #2: Who is recruited to participate

Because a service is designed for both those receiving the service and those providing and supporting it, the research is done with multiple types of participants situated in different parts of the experience, both front-stage and back-stage. Additionally, because services are experienced in many places in many different channels, it is often necessary to conduct research in multiple kinds of settings. For instance, a service design team might investigate how a service is experienced in the home and in a retail space, and how the service is delivered digitally, by voice or in person. While UX research recruits a variety of cohorts and considers use in a variety of contexts, service design expands the number of participants, roles and settings beyond what is typically considered in UX.

Difference #3: Breadth of inquiry

Service design’s scope is relatively vast compared to UX. Not only must we investigate more actors and more settings, we often use different approaches for each of them, to help the team get insights on how the service comes together and how it is experienced by everyone involved. Further, service design is trying to piece together a whole experience as it unfolds over time and zig-zags across channels, so the scope of each research session tends to cover longer spans of time than a typical UX project, and investigates a participant’s experience with equal attention wherever it leads, regardless of channel. With UX research, times spans are often briefer, and non-digital channels are treated as context for the UX design, not as something that itself might be redesigned.

Difference #4: Depth of inquiry

Because its scope is so broad, service design does not go into the detail and depth that UX design does. This is why no service design should ever go directly into implementation. Service design only defines UX design problems it does not resolve them.  Every touchpoint, digital or otherwise, defined by service design requires further work by design specialists who have mastered the craft of designing that type of touchpoint, with service designers staying involved to ensure the service as a whole stays consistent and seamless.

UX research is concerned with gathering insights that will guide the detailed design of a digital touchpoint. It seeks to get deep, detailed information on the person’s use context, mental models, vocabulary, physical and perceptual abilities, etc. Service design research only skims the surface of these questions, in order to keep an eye on how the touchpoints are integrated with one another and other components of the service.

In evaluative research, service design only validates concepts at a high level, concerning itself mostly with the usefulness and desirability of touchpoints in the context of the broader service, and deemphasizing usability to the greatest degree possible.

The only part of UX research that service design mostly replaces is the foundational research, and even there, only partially.

Difference #5: How analysis is conducted

As mentioned above, service design research is the ultimate alignment tool. To stabilize and refine alignment, service design teams will often conduct analysis socially and in the open, preferably in a location where members of the organization can drop in and participate. At Harmonic, we have called this “open research studio”. The analysis is intentionally visual and easily digested. Stories and other insights gathered from the field are displayed in ways that invite conversation and direct collaboration on the artifacts.

The process of collaborating encourages cross-disciplinary conversations and brings out a shared understanding that is relevant and comprehensible to everyone in the organization. And because so many people have had direct involvement in shaping the understanding it is likely to be complete and credible.

Difference #6: How findings are applied

Finally, returning to the earlier point that the material of service design is organizations, a material this complex is too much for any single mind to contain or any single talent to shape. The whole organization must be mobilized in redesigning itself to deliver better experiences. Everyone must learn to function as members of a design team. To make this transition as intuitive as possible, many service design research outputs are designed specifically to serve as large-scale collaboration tools. Most service design research findings include various kinds of experience maps meant to be physically hung on a wall or otherwise shared, and to allow teams of people to interact with the surface as a canvas for collaborative work.

Of course, the design research findings are always tools used for designing. But because the interpreters of other kinds of design research are usually experienced designers who already know how to interpret findings to make design decisions, researchers are free to emphasize the content of the findings over their form. The fact that many of the people doing the design are inexperienced working in that way places special demands on service designers to think more about the form and explicitly make them not only easy to understand, but easy to use in support of opportunity identification, ideation, or evaluation.

*

Wow, that was not brief after all. But I hope it was at least clear. I’ll make one more attempt at brevity with a summary:

• Service design research seeks to understand many types of people who receive, deliver and support the service…
• …it accomplishes this understanding using a wide variety of research approaches in many different settings…
• …the research is conducted, analyzed and applied by large rotating multi-disciplinary teams which should include UX designers…
• …but it does not replace UX research, which should be used to both inform and evaluate the detailed design of each digital touchpoint in the service.

In the late 90s and early 2000s, designers used to repeat the mantra “learn once, use everywhere.”

It appears to me that this ideal has been waning for the last ten years or so, in favor of a different ideal, which involves understanding what people will be thinking, feeling and trying to do at each moment of an experience, in order to anticipate their needs and likely responses.

The first ideal emphasizes working systematically to develop and maintain conceptual clarity, consistency and coherence. The goal is to help people understand how the system works so they can learn it and control it easily. Let’s call this ideal Conceptual Integrity.

The newer ideal emphasizes empathizing with people and understanding their experience so that learning or understanding the system is unnecessary. The system shapes itself around their needs, their wants and their desired actions. Let’s call this newer ideal Empathic Anticipation.

It is clear that the two ideals conflict to some degree, which means tradeoffs must be made. Perfect Empathic Anticipation requires flexibility from systems to conform to the momentary needs of a moment. Conversely, perfect Conceptual Integrity would limit the repertoire of interactions to a small and learnable set, and would not support arbitrary deviations to address needs a person might have in only one moment of an experience.

Of course, no design is fully one or the other. Most designers try to strike a balance between the two ideals. The best solutions manage to minimize tradeoffs and cleverly conceal the tradeoffs that are made so people don’t even notice them.

But to make these kinds of tradeoffs designers need at least three skills and toolsets to support those skills.

First, to design with conceptual integrity, designers need to know how to think and work systematically, both conceptually and concretely, so that the relationships between the whole and its parts are perfectly clear and logical.

Second, to design with empathic anticipation, designers need to know how to develop deep insights into the people they are designing for, what they are trying to accomplish and how this need fits into their lives as a whole, so that each moment of the experience accurately anticipates and effectively responds to their needs, both functionally and emotionally.

Finally, to pull together the right experience for this particular person in this particular situation, we need to know how to think about design problems and make the best tradeoffs. We must never automatically apply our own favored skills and best-mastered tools, but rather select our methods intelligently in response to our understanding of the problem. To do this, we need to draw on both ideals and bring them to bear on design approaches themselves.

physical sciences : technology :: social sciences : design