“It is designing the white spaces, the gaps between the things, the connections, the handovers, the handoffs, expecting that most people are messy, will have their hands full, will not be thinking about your shoes right now, they will be wondering if they will make the train, if their children will be OK, if they will sleep properly tonight, if their love is real.”
– Toby Barnes in ‘On designing Everything-as-a-Service.’
This is the human-centered, outside-in perspective that service design assumes, going beyond understanding needs to encompass the context they occur in. To design services accordingly, prototyping is an essential part of the service design process as it is in any other design domain. When one speaks of prototypes, it is generally understood as a product prototype. But when you bring service into the prototyping situation, people seemed lost and rightly so.
In contrast to the physical and tangible nature of products, services are intangible, heterogeneous, inseparable from consumption and perishable. This makes prototyping services unique but also perplexing. For example, it is much easier to create a prototype of a lamp than a laundry service. Couple that with the rapidly changing service context and you have an interesting challenge on your hands. In today’s networked world, services have moved from dyadic relationships to multiple, complex interactions with various members in a network. So how does one prototype services in this case? The first step is to ask the right questions before you start prototyping.
- What do I want to know?
Prototyping methods can give you an overview of your service or help you zoom in on specific interactions or “touchpoints”. Asking yourself what is it that you would like to know helps you select the right prototyping methods. For example, if you need to understand the how the front-end and back-end processes work together you would use a service blueprint. To get an overview of how your service interacts with other components of the system you would use a technique like giga-mapping.
- What resources does my service need?
This would help you determine what resources you can utilize from within your organization and what would need to be outsourced or borrowed from other actors within the network. Having a clear picture would enable you to design better services capitalizing on your resource integration capabilities with those available in the service system. Which brings us to the next question.
- Who should be involved?
Involving your customers or users in the prototyping process as part of value co-creation is a no-brainer. What can enhance this process further is the inclusion of the actors within the service system who are relevant for the successful delivery of your service. For instance, designing a service in the context of healthcare would at the very least require the participation of patients, doctors, nurses, administrative staff and hospital management. Prototypes serve as an external representation of your ideas and promote shared understanding amongst actors who will integrate resources and co-create value. This would further facilitate transferability during implementation.
- Should it be perfect?
Absolutely not! Prototypes are meant to be quick and inexpensive allowing you to test out ideas. The idea behind prototyping is to understand the outcomes and limitations of your service as well as the role various actors within the system play. Also realistically speaking no amount of planning can fully prepare you for the actual future use of the service. Blomkvist (2014) positions prototypes as surrogate situations of future service. As such prototypes can be used not only to explore how the service would function normally but also to experiment with variations and failures that may occur within a service. Thus the prototype can be used to evaluate how your service would function under different circumstances. The most important thing here is to let spontaneity and creativity play their part.