I recently cooriginated a new kind of design artifact that seems to be taking off in the service design world. I gave it its name. 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. Through these distributed actions, a service exists as a service, and lives in the way societal beings live.

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.”