Using a Service Ecosystem to Quickly Grasp Complexity

A unique visualisation to deliver insights right from the start of a service design project

Thanks to its holistic nature, service design is uniquely suited to bringing a customer-centred perspective to the design of today’s omnichannel services. In the earliest phases of a service design project, the ‘service ecosystem’ can be identified and visualised, long before more detailed customer journey mapping and service blueprinting work takes place. By building a shared understanding of the breadth and complexity of a service early-on, a service ecosystem is a powerful and easy-to-implement tool for the service designer’s arsenal. In this article, I’ll introduce the structure and format of the visualisation itself, the ways it can be created, and some different ways of applying it.

What is a service ecosystem?

A service ecosystem visualises the broad range of interactions and touchpoints that come into play across a customer lifecycle, and it does so with just a few layers of information. Yet despite its simple structure, it provides important new insights for the team that creates it.

What’s in the name?

Before diving into the structure and application, a little context might be in order. In service design terminology, ‘service ecosystem’ usually refers to the actors involved in a service, and the value exchanges that occur between them. The ‘ecosystem’ is sometimes visualised concretely as a ‘service ecology’, which pays particular attention not only to the value exchanges, but the distinctions between roles.

Structure of a service ecosystem

Let’s take a look at the elements of a service ecosystem, from the inside out.


User’s need(s)

Representing the user-centred focus of service design, the service ecosystem places the user at the heart of the visualisation. The user’s “underlying need” occupies the very centre of the circle, while needs specific to individual phases are located in the relevant segments of the next ring outwards. Taking the example of a service ecosystem for an insurance provider, the underlying need for the user might be something like “feel protected in case of the unexpected”, or more succinctly, “peace of mind”. During the “usage” phase, in which an event occurs that triggers a claim, the more specific needs might be “reassurance” and “assistance”.


The next ring outwards contains the discrete interactions the user has with the service, phrased in very simple, concrete terms (often ‘verb + noun’). Within a segment of the “Interactions” ring corresponding to a phase, no order is implied by where interactions are positioned; they are simply scattered through the segment. The interactions are also written without reference to a touchpoint, to avoid bogging down the document in unnecessary detail. Continuing the example of an insurance provider, interactions might be “initiate claim” or “change customer details” (not, “report claim via app” or “change address details in customer domain”).


The places on which the interactions of a given phase occur are gathered together in the next ring outwards: “Touchpoints”. Here, touchpoints that play a role in a specific phase are named. They could be things such as “app” or “call centre”, or “email newsletter”. Similarly to interactions, no order is implied by where they are positioned in the ring, and no attempt is made to visually link interactions and touchpoints. Finding the right level of detail when describing touchpoints is also important. “Online”, “digital” or “face-to-face” would be too vague to be of use. “Public website” is acceptable, but there may be even more value for naming specific aspects of that website as well, such as “customer support forum”.


The outermost ring is self-explanatory — it contains the high-level phases of the service that the user progresses through. In practice, these phase names should correspond with phases used in later deliverables, such as customer journey maps. For many services, typical phase names will suffice (e.g. “awareness”, “orientation”, “purchase”, “use”, etc.). It often makes sense to identify the phase names in advance of the service ecosystem workshop, to kick-start its creation.

‘As-is’ and ‘To-be’ service ecosystems

A service ecosystem can be created both for current services (‘as-is’), as well as for services that don’t yet exist (‘to-be’). For ‘as-is’ services, the creation of the visualisation relies on capturing details about the service experience as it is today. When creating a ‘to-be’ service ecosystem, care must be taken to ensure the identification of interactions and touchpoints match with the user needs. Specifying interactions and touchpoints without properly validating them risks an ‘inside out’ approach, and mismatched expectations. Therefore, a ‘to-be’ service ecosystem relies on clearly articulated user needs at its centre.

A word about granularity

It is tempting — especially with experience creating detailed customer journeys and service blueprints — to go into a great level of detail when creating a service ecosystem. However, this risks creating an unwieldy and overly-complex document, which will require significant time to create and interpret. Much as in customer journey mapping, a significant proportion of the value delivered by a service ecosystem comes about in the awareness and discussions it triggers within the team during its creation, and not simply the deliverable itself.


Purpose of a service ecosystem

Creating a service ecosystem early in a project offers several advantages, foremost being the insights it delivers into the (future) service’s eventual complexity. By systematically working through each phase of a service and identifying the touchpoints and interactions that come into play, a team often realises that things are more complex and interconnected than they had previously thought. And in cases where ownership and delivery of different elements of a service are spread among people or departments — such as channels or products — it can have an especially great impact. I have facilitated more than a few service ecosystem creation workshops in which individual product owners were for the first time confronted with the fact that their ‘product’ (an app, for example) existed alongside many other touchpoints that the end customers would also be using. Triggering this ‘service’ awareness, as the first step towards orchestrating all the touchpoints and interactions to deliver the best experience, is the true power of visualising a service ecosystem in this way.

How to go about creating a service ecosystem

So what does it take to draw a service ecosystem — whether ‘as-is’ or ‘to-be’? Firstly, it’s a team effort, rather than something crafted by a solo service designer. Identify a group of people who are responsible for the service, and invite them to a workshop. Strategic and ownership roles tend to bring the most value to the activity. Unlike customer journey mapping and service blueprinting, the specific insights of policy, legal, marketing or IT representatives — for example — are less relevant here.

New insights through additional annotations

A service ecosystem’s real value comes in the insights it delivers for visualising future services, but it can also be employed to bring current services into focus in a new way. This can be useful to see the impact of future changes to the service.

Harnessing the power of a service ecosystem

In addition to the insights that the creation of a service ecosystem delivers, it can also have more practical applications within a (service design) project. Here are several ways in which the information and insights it contains can be translated into action:

As a precursor to customer journey mapping

To identify areas of opportunity

For competitor analysis

To support the orchestration of complex services


It’s my hope that sharing this visualisation with the wider community offers a new tool which allows service designers to quickly grasp — and communicate — the complexity of services for themselves and for stakeholders. A service ecosystem requires a relatively low investment of time and effort, yet pays quick dividends, especially for those seeking to convince stakeholders of the value that service design can bring. And it can remain a living document, updated as required, and used to communicate the totality of a service, in a way well-known deliverables like customer journey maps sometimes fail to do.

An independent service design practitioner (, SVP of the Service Design Network, Editor-in-Chief of the journal “Touchpoint”, co-founder SDN Academy

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store