Designing a Service Canvas Book (SCB)
or the unexpected creation of a new tool
“Ok, let’s add this new section in the Service Canvas poster.”
“Uhm, I’m afraid there’s no more space.”
“So, we need to go a little deeper on this topic.”
“I can add a line or two, but then we won’t have any space left.”
“Not even a bit?”
“Nope…”
“How can we communicate the complexity of this project then?”
During the early design phase of our latest project for an insurance company we were struggling with the growing complexity of the services we were designing.
We were, indeed, designing a network of five health-related micro services, each independent, yet connected and part of one bigger whole. The aim of these services was to become part of a mobile application, a web portal and possibly other touchpoints.
As the project took shape many issues came up. We started to ask ourselves how to address them.
— When we started the project, we didn’t know that we would eventually come up with a new tool, a tool we could use to design many other services, too.
But enough with the flashbacks — let us start from the beginning.
1. Service Canvas Book as we see it
So we are speaking about a weird thing we call ‘Service Canvas Book’ or, among friends, ’SCB’, but what is it exactly?
The SCB is a combination of different things. Like a recipe to a cake, SCB has many ingredients:
- 1/3 strategic design, as we were helping the company to give shape to their ideas, clear up their mind and structure a strategy for their new services.
- 1/3 of user experience design, because we translated the services into a mobile application, and designed all the user flows as well. And, last but not least,
- 1/3 of data journeys, as we designed all the data flows, to structure the information architecture.
2. Why did we need a tool?
To refer back to the beginning, we didn’t design the SCB just because of lack of space on the original service canvas poster, of course, but this was certainly a starting point.
In the early stage of the process we used a basic tool that we called Service Canvas, a single-sided-poster split into different areas, one for each part of the service.
This Service Canvas worked well as a synthesis for all the different parts of the service, but provided just an overview of them, with no possibilities to go deeper in analysis.
That’s why, when the design process was becoming more and more complex, we realized that we needed to think about a tool specifically designed for our purposes.
One tool to rule them all:
We knew that keeping every section in a single space was a key requirement for our new tool, as it would bring value both to ourselves and the people that we wanted to share the tool with.
Speaking of our needs: a single document would allow us to control each and every section. Having one section next to each other would also help us work on the different part of the service simultaneously, making it much easier to go through sections and navigate them back and forth.
Operationally speaking, as we had to use the tool five times (once for each service), we wanted a single document to quickly update according to changes, feedback received and so on. To assure the document was always updated to the latest version, we were controlling versioning while keeping track of every release as well.
Most importantly, we realized that having one, simple-to-understand and exhaustive tool would make it easier to share the project.
One tool to bring them all:
We didn’t have to share the project just with the client, though. Our goal was to communicate the services to a number of other stakeholders as well.
As you know, our client was an insurance company and we were working for them to develop a series of services.
What you don’t know is that we were speaking with different departments within the corporation, whilst also speaking with start-ups and other companies to select them as partners, while working together with another design studio and a consultancy agency. The situation was a bit crowded, in other words.
So, our biggest challenge was to share our research, analysis and project with all of these stakeholders, using language and visual contents that they all could understand.
3. How the SCB is made?
And finally, let’s come to how the Service Canvas Book is made.
The whole book revolves around a service model section which contains the map of the analysed service. In addition to this, the book is made of ten sections in which we analyzed the following aspects: project brief, stakeholders, team, partners, tasks, touchpoint, opportunities/constraints/risky points and data journey.
The stakeholder section was intended to map the complex and crowded nature of the project. Since the people involved were many, both from the project and the service side, we wanted to clarify tasks and responsibilities distributed among the different companies. We also categorised and listed the client’s internal stakeholders and final users.
In the partner-section, we map the companies to collaborate with.
We tell about the service through a service map which explains how the whole system should work. We made two versions of it, as we expect two different releases of the app.
The touchpoint-section contains flows and wireframes that we designed. These translate the service into an app. We worked on the UX of the app, while another studio took care of the UI. We designed this section to communicate every detail of the app with them.
Lastly, data journey-section was built to guide the IT team to understand data sources, storage and messages between entities.
In conclusion, as we were finishing up the project and talking to co-workers about the project and the tool that we were using, we realized that there was interest around the topic. So we decided to tell the story.
— The Service Canvas Book may need some updates and fixes but it is a tool that we will for sure use again, maybe adapting the format to meet the needs of other projects. We are thinking about an upgrade to digital as well.
We have worked hard on this challenge and we are proud of the SCB. The next step is to share it internally with the whole studio, and use it as a communication tool to speak about our service design skills.
Project team: Andrea Desiato, Cristina Paleari, Alberto Sarullo.
