A unique visualisation to deliver insights right from the start of a service design project
Published originally in Touchpoint Vol. 10 N. 2 — Designing the Future
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.
Like customer journey maps and service blueprints, a service ecosystem is a chronological view of a service experience, but it only concerns itself with phases, rather than the precise order of events within them. Within the phases, the user’s needs are identified, alongside the service interactions, and the touchpoints on which they take place.
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.
However, when my ex-colleagues and I developed our own interpretation of a ‘service ecosystem’ ten years ago, we saw it as a concrete visualisation rather than an abstract term. This interpretation of the term — the circular visualisation — is the basis for this article.
Structure of a service ecosystem
Let’s take a look at the elements of a service ecosystem, from the inside out.
Firstly, a service ecosystem is structured as a set of concentric rings, and reads clockwise from the ’12 o’clock’ position, phase-by-phase. This ring-based visualisation sets it apart from typical customer journey maps and service ecosystems, and also emphasises the fact that some service experiences don’t fully end, but begin anew with the discovery and consumption of new products. It also emphasises the holistic nature of the ecosystem — encompassing all its elements within clear boundaries, as opposed to the sprawling, linear nature of blueprints and journeys.
Here is a detailed breakdown of the individual rings:
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”.
Interactions
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”).
An additional benefit arises from identifying interactions in an agnostic manner within this ring. Because all of the in-use touchpoints are identified for a given phase, the service ecosystem can inform decisions on what interactions will be supported on what touchpoints. This can be done later, while scoping the functionality of the service (writing user stories or otherwise creating specifications), thanks to the generic way the interactions are written. By supporting the re-use of interactions across multiple touchpoints, the service can be built more efficiently, and also meet the needs of users who don’t want to be confined to doing things only within one channel.
Touchpoints
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”.
Phases
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.
For an interaction, “pay bill” is adequate; it’s not necessary to reveal further complexity by having individual interactions for “pay bill by credit card” and “pay bill by direct debit”, for example. Similarly, avoid getting too detailed when identifying touchpoints and phases.
Lastly, I’ve been asked several times about the possibility to create multiple service ecosystems. For example, to cater for different personas, when their needs differ. In our view, it’s best to stick with one service ecosystem, and abstract the persona needs enough so that they can be shared by all personas. However, in cases where the service is platform-based, individual service ecosystems do make sense. As an example, the service experiences for riders and for drivers with a car-sharing service is significantly different (especially the underlying needs and interactions), so it makes sense to visualise both services separately, as different ecosystems.
It’s also worthwhile saying that a service ecosystem will offer little added value for simple services that have very few interactions, or only one or two touchpoints. And lastly, don’t attempt to build a service ecosystem for a single touchpoint, such as an app. Keep the holistic nature of the deliverable in mind.
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. My previous colleagues and I 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.
Beyond the complexity that a service ecosystem often surfaces, it can also be used for more concrete purposes, which I’ll get to a little later.
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.
Working on a whiteboard or wall which can be later dedicated to the service ecosystem is ideal. If that’s not possible, two easel/A0-size pieces of paper taped together can be a good start. Start by drawing and labelling the relevant rings, and identify the phase names on Post-its. Distribute them around the outside of the outermost ring, but be prepared to reposition them based on the eventual size of each phase.
If customer research has been carried out already, it should be possible to identify the needs at the centre of the visualisation. If not, you can consider making assumptions of the needs, or leaving them blank until they can be filled in based on real insights (and then used to sense-check the interactions and touchpoints). If assumptions are made concerning needs, ensure they remain recognised as such, and are replaced with validated needs once research has taken place.
Then continue to fill in the interactions and touchpoints, on a phase-by-phase basis. Normally, the team members present, and the knowledge they bring, is enough to accurately capture the true extent of touchpoints and interactions. Although the service ecosystem is not intended to replace ideation activities later in a project, it can be employed at the earliest stages of a project and help identify expected functionality of the future service, and where opportunities might exist.
In general, a 90-minute workshop is adequate to complete a service ecosystem. For complex services, or cases where progress moves slowly due to lots of discussions, a second 90-minute workshop may be necessary.
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.
Two additional types of annotation can be used when creating the service ecosystem, to bring in additional layers of information:
Obsolete touchpoints and interactions: A line can be drawn through items to show that in the future, they will no longer play a role in the service experience. This is useful for seeing the evolving complexity of a service, transitions between channels, and highlighting those that are new.
Third-party touchpoints and interactions: These can be indicated with brackets surrounding the item, to show that the specified touchpoint is beyond the control of the service provider. This is useful to provide context when third parties still (significantly) impact the overall service experience, such as the role of an auto repair garage in relation to car insurance.
Releases and future functionality: When visualising a ‘to-be’ service, visual distinctions can be made between different product releases. For example, a different colour can be used to indicate interactions which won’t be available at launch, but later in time.
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
Although customer journey mapping is ideally done for an entire service lifecycle, practical considerations often mean that journeys are shortened to encompass only parts of the service experience. A service ecosystem can be used to identify individual, shorter journeys, by grouping sets of interactions that span one or more phases. With the journey identified, the requisite research and mapping activities can occur later.
To identify areas of opportunity
A completed service ecosystem makes visible the type and numbers of interactions in the experience lifecycle. In doing so, it also lays bare the stretches of time where no interactions take place, or perhaps where touchpoints are over- or under-utilised. Insights such as these can be the trigger to determine whether new elements of the service should be introduced.
For competitor analysis
When designing a new service, a deep understanding of what’s on offer from competitors is important. Based on simple research methods such as “mystery shopping”, it’s possible to easily gather enough input to visualise the service ecosystem of the competitor. Analysing theirs and yours side by side will make visible key points of difference, and might help trigger innovation.
To support the orchestration of complex services
Complex services — especially those delivered by large organisations — demand orchestration at a strategic level. This orchestration can be supported by the holistic perspective a service ecosystem affords. Rather than having touchpoints developed and managed individually, teams and managerial roles can refer to the service ecosystem when planning work, to ensure the “big picture” of the service experience is kept in perspective.
Conclusion
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.
This article also appears in Vol. 10, № 2 of Touchpoint, a journal published three times per year by the Service Design Network, and providing in-depth coverage of all aspects of the service design discipline.
Comments