Welcome, everyone.
The plan for today is quite simple. We will answer a few Service Design questions and also look at a few Service Design Principles.
So let's go and discover three Service Design Principles and these one come from the book Service Design Principles 101 to 200.
I'm just gonna read the first three, which are in the chapter "Service Design Mindset".
The first one is called
"Think You're doing Well. There is a big chance you are not".
A study by Bain and Company looked at how companies perceive themselves, finding that 80% believe they provide a superior proposition.
Wow, that's, that's not bad.
Lots of company are doing great work. It seems that must please actually loads of people. However, when you ask the customers of these same companies the same question, only 8% agree with the previous statements. Oh, okay. There is a bit of a gap here, huh? That's what the guys at Bain and Company call the "Delivery Gap".
In a way, companies like humans tend to be too optimistic about their own qualities If you think you're doing an awesome job, it still makes sense to double check your belief with your customers. There is a big chance that the people you serve might disagree with you, and once you ask for feedback, you can learn something valuable.
You'll learn how to improve your service or your company because no, your service might not be so great after all.
Let's go for our second one, which is called:
Most new ideas fails Yours, might, too.
You are bringing a new service or idea to live, but after a few month, you realize, hmm, that is not really working out.
That's pretty pressing, right? You feel you or your organ organization are a failure. And then on the news and social media, you see all this organization which can change and innovate. You definitely must be stupid if you can't innovate, but is that really the case? I stumbled upon a few statistics in an article from Inc. Magazine, which tells a slightly different story. It seems that over that there are over 30,000 new products introduced every year. That's a lot. Lovely to know that we live in a world full of innovation, right? But the reality is a bit different. Out of these new products, 95% fail. I'm just gonna read that again.
Out of these new products 95% fail. That's a lot. And other statistics reports report relates the same. It appears that the, the failure rate of new grocery store products is between 70 to 80%. That's a lot. Hence, failing is just a part of the change and innovation process. Most new ideas will fail, and that's entirely normal.
You just need to keep failing often enough to ar arrive at that five to percent success. So here the idea is most new ideas failed. You will too. You as will too. Just, you just have to break out a lot of new ideas.
And for the last one of these little preview,
It's okay to steal ideas from others.
Good artists, copy, great artists steal to read this quote tries to show that coping is not enough.
You also need to adapt what you have copi by doing. By doing so, people won't see the copy anymore. And what you have adapted will not feel like a weird add-on, but as a complete part of your service, this means you can go out and look what other services do in other fields than yours, after which you can import and adapt their best practices in your area.
For example, a hospital could copy parts of a fast foods experience. That's a pretty good way to innovate. When you still idea from other fields, you escape your routine. If it works in another field, it often means someone already tested it with many users who find value in it. Therefore, there might be a pretty good chance that it might work in your field too.
When you still, what orders do, you can innovate and spend less money and time. You spend less time on all the user research you should have done. If your idea was completely new and you spend less time on all the brainstorming to get to this idea. Stealing can be okay.
I'll hope that it gives you a bit of a sense of these Service design Principles and the idea that there are simple mindsets that we can use to improve the customer experience.
And now I would love with you to jump in one other part, which is the part about the questions about Service Design.
As first chapter that we will cover today is some stuff about Service Design Worldwide.
You might know I'm Swiss. So one question that I got from Nico is:
What organizations use service design in Switzerland?
Very good question from Nico. And the answer is quite simple.
There is a Service Design Network here in Switzerland They made this lovely this lovely map, which shows the companies that are either teaching Service Design, or are consultancies or are offering services around this topic.
With this picture, we see, there is a lot of people. There are obviously the kind of usual key players, companies like PWC, Fjord, the big ones. Then you have the universities. I love the Lucerne university that you might see on the left part of the screen.
Obviously I'm totally biased. Because that's where I was brought to service design. And it's also where I from time to time go back to teach and coach a students.
But this picture doesn't tell everything. And I think it's the same, not just for Switzerland, but for many, many countries. There might be way more than you think. Why is this the case?
Because Service Design is a mindset that has many names. Some people might call it customer experience, other call it UX with a twist or whatever. There are a lot of companies that are doing Service Design in your own country, but that don't call it like that because in your country, that's not the fanciest word to attract clients.
That was first question. And now let's jump in the next question on Service Design and career.
Are there enough Service Design jobs out there? It's hard to get data about that. But there is a lovely experiment that is going on, which is servicedesignjobs.com.
Today, it's written that there are 1 62 open Service Design jobs and more than 4,000 archived Service Design jobs. And there are listed from 61 countries.
So there are a lot of Service Design jobs, and these are just jobs where they clearly mentioned the title Service Design.
This doesn't cover all the jobs where the the name and the title might be a little bit different.
So imagine how many more opportunities there are there for Service Design practitioners who, you know, are flexible enough to work in a job title that is a bit different than the word that they love to use, but which has the same mindset.
If we go a bit of in the detail, Marc Fonteijn looking at the data of the Service Design jobs website, saw that nearly one new Service Design, job opening comes out per day in the United Kingdom.
I just want to remind you that there is this lovely website, servicedesignjobs.com. Check it out. You can find them by country. You have also very interesting reports like the career report or the salary report, which gives you insights about how much service designers get usually paid for.
So, there is a pretty good amount of Services Design jobs out there.
Let's continue and jump to a new topic, which is Service Design Philosophy questions.
How should we call the people we serve?
There seems to be a bit of an historic shift from what I see and from what I have seen in books and discussions. It's that we started by speaking just about customers and then slowly there is a realization in time and in history that not all people we serve are customers.
So more people tend to use now the word "user" because not every person involved in your service is one that is paying or that is the customer. For example, Friends who come together to go shop a pair of shoes, but at the end of the day, there is just one person buying the shoes.
But the experience of the person next to the one who is really buying the shoe and who is waiting there, is also relevant.
Then we have another shift.
We go to humans. And we say: there are also people who make the service and these are also important and their experience is also important.
Therefore there is a shift. We should speak about humans instead. Because then we involve the whole organization.
There is a pretty interesting quote that I would like to share with you. It's from Indi Young a very, very interesting author. She has written three books, Highly Recommend and she posted this, which is I think a, a very interesting take on this question.
"The word user pulls attention away from a person's purpose. People exist apart from your organization, within their own framework, and our language in strategy and design must reflect that.
So yeah, it's a, it's a tricky question. How should we call people, the people we serve? There are different answers. There is this historic shift. It depends on who you really serve. And then it really depends on little things.
I have to say, I use these words as synonyms, as I'm writing books. In a book, I can't just say human every two every time I mention the people we serve, because that will be very boring.
So I have to work with the synonyms, customers, citizens, stakeholders, et cetera. It adds also a bit of precision when it's needed, but also it creates some rhythm.
But at the end of the day, the word that I love to use is human or people, because I, I feel it serves the purpose of saying, "We don't take care just of the end user, but we also take care of the people behind the scenes that are very important to make the work happen.
But that's just a very personal answer to a very philosophical and complex question.
And now, if we continue our exploration, let's go into Service Design Principle questions.
So this is a new chapter where we will focus on how you can create create and find your own Service Design Principles.
The first question is:
My God, Daniele, what is a Service Design Principles Library?
It's like having your own Pinterest of Service Design ideas. That's a very interesting take that we explored together in an interview on the Service Design Show. We came up with this idea with Marc Fonteijn the host of the Service Design Show.
What do I mean with that? You know, Pinterest is this platform where you go and take inspiration from many places and say:
"Oh, this is something inspiring for this project I'm working on. I'm gonna keep it as a reference That's basically what we're trying to do here with a Library of Service Design Principles.
You're trying to collect inspirations, tips, examples, case study as elements that will inspire you to improve your service in the future and you keep them all in one place.
What are the benefits of creating your own principles library?
It helps you to serve the humans around you better. The more you collect examples of good services, example of bad services, examples of statistics and facts about how people behave the more it will help you to serve the humans around you in a better way.
That's the first thing. It's the most important thing. You are doing that because in the end, it helps you to be to improve the services you're working for.
There are obviously also more advantages to that. It helps you to kickstart project.
If you are working in organization where there are many projects going on, for example, if you're working in a consultancy, whenever you start a new project, it's hard if you have to start from zero.
But if you have your own Services Design Principles Library, you can just say: "Okay, I'm starting this new project. What are principles that I think could be useful in this particular project?". So you're not starting from zero, you're starting already with a lot of ideas, possibilities, and information.
It's kind of a, being a lazy service designer, but a very effective one.
If you're working in a team, it's also something that can unite the team towards a common vision. You can then say: "Hey guys, we're starting this project. On this project we have defined that we are gonna use these five or ten key principles to guide us along the way.
Or you can say: "Hey, as a team, we want to test out these five principles and see if they match and work for our service".
Another advantages is this idea of building your own Pinterest, which helps you to not forget all the good inspirations you stumble upon.
People read something very interesting in a book. But nobody goes back to the book to read the highlights.
A service Design Principles Library helps you to take a note and put it somewhere to remember. So when I start a project, I don't have to open every book in my very physical library, I already have the key ideas ready.
This is a, something that is very dear to me. It helps you to fight, at least a little bit, your imposter syndrome.
The more your Service Design Principles Library grows, the more you you see that: "oh, I have a lot of knowledge". Especially if you count them. You say: "Oh, I already have 300 or 50 elements in my library. These are principles that I can take for next projects."
Then you feel like: "okay, I already know something". You see the number of your knowledge. It helps you to see your expertise.
Then having your own Service Design Principle Library helps you to grow daily as a service designer because you have this library that you want to take care of. And it forces you in a way to look at the world in a different way.
Look at the books you read in a different way. Look at the experiences you're going through in a different way. Because you become much more an observer of what happens.
You think: "Oh, oh, this is inspiring. I should take a note of that to put it in my library".
And so it helps you grow as a service designer because you're not just living life as anybody else, but you're taking a step back and looking at things in a designer way and say:
"Oh, this is interesting. It works because they did this small thing here".
And then you can copy that in the next project maybe in a few years and reuse it.
Having your own Service Design Principle Library is a good way to better serve your customers and, and users and humans that you're involved with. And then it has very practical advantages, like being faster to start projects, and also helping you to grow over time your skills as a service designer.
Okay, now let's continue and explore this question:
What tools to use to create your own Service Design Principle Library.
So you might say, Daniele, I'm excited. I like this idea of having a place where I collect all the ideas, tips, tricks that I find to improve the customer experience. I love this idea. So how do I build that?
Let me share a few of the insights I learned in my own journey doing that.
The first thing is think long term which means this is something that you will do for years.
And because of that, you have to switch your brain when you select the tools that you're using to select tools that will have a long lifetime.
So don't jump on the one shiny tool that came out just right now because you're not sure if it's something that will be with you over the years. And it might be quite difficult if next year you have to transfer everything you worked on to another platform.
Then we have very practical considerations.
If this service library you're building is just for yourself, then it's totally okay to work with note apps. You know, stuff like Apple Notes, OneNote, just some place where you can write text. It doesn't have to be super fancy as notion. It can just be Apple Notes that works perfectly well, or Evernote. If you keep it for yourself, you don't even need sharing possibilities. The simplest thing that you already own works really well.
If you are in the idea of sharing your Service Design Principle Library to the public, then it might be interesting to just not think into notes apps, but maybe more in website builders.
So tools like WordPress, Squarespace, Wix. Or Podia the one I use. Then you start with the end in mind.
You think: "okay some other people from India, Dubai, Brazil or Geneva might use this elements". So I want to already have a system that works with that.
It's nice if you already write in the place where it's gonna be published. Because if you have to keep track of all your library in two different places, that's gonna be a lot of work for not much.
If you're really going into pro mode where you say: "Hey this is gonna be my lifetime practice and it's gonna be something that I want to share, that I want also to teach to people in my company".
Then you might work with something which are more like database heavy apps like Notion, Trello, Airtable.
If you are interested in this idea of building your own Service Design Principle Library, there is a, a word that you should know: " Personal Knowledge Management". It's always funny when you have the right term to use in Google, suddenly you get really interesting results. But because you didn't know how it was called before you just got really bad results in Google. This keyword, Personal Knowledge Management can very interesting. So look at personal knowledge management tools in Google, and you'll find a lot of interesting resources.
One of the resources that I would recommend that you check is this website buildingasecondbrain.com/resources. It's one that is mentioned in this book, Building a Second Brain by Tiago Forte.
There you'll find this lovely video which explains the different types of note takers. It will show you the way you write and think about taking notes. Then shows you which app is working for your personality type. There also Tiago shares shares the three common pitfalls to avoid when choosing your app.
If I had to start today again, I'd go personally with Podia. Podia is this website tool that I'm using because it has this eLearning capability, which is really lovely. And now they have a free pricing tier, which makes it possible for me to now recommend it to others.
What I love is that you can now have a, a website where you share your principles as your writing them. And you can also get people to subscribe to stay in touch and discover more as you develop your Services Design Principles Library.
That's something that I really didn't see when I was starting my own library.
I thought: "Hey, I'm just gonna do for it for myself and publish it online for the few people interested in it. If I had known at that time that years after, it will be thousands of people interested in that topic I would have made it easier for them to be able to follow the journey by registering to a newsletter.
That's where Podia is really interesting because it brings together the writing, the publishing, and the tools to help people stay in touch. Plus it's free.
Next question, which is:
What are apps that help write clearer Service Design Principles?
A Service Design Principle at least in the way I do it, is something that is written. So writing skills are quite important. I'm myself not a very good writer, especially because English is not my first language. That's where apps can be very useful.
The one first app that I would recommend is Hemingway app. Hemingway is this author that had this very particular style of writing with short sentences and where he removed everything that was not absolutely necessary.
Hemingway tries to replicate this idea. You put your text in it and it shows you: "this sentence is way too long", or "this type of word is just a filling word, you don't need it, remove it".
It really helps you to stay more compact, maybe sometimes too much. That's then your choice to choose how far you want to go with it.
That is really helpful especially for people who come from a language like French, where we tend to make very long sentences, which are very hard to read.
Another useful tool when it comes to writing is Grammarly. It has a free option, which is pretty cool. It corrects all the usual mistakes and it really tells you: "Hey, these are things you cannot say in English like that".
There is another tool called languagetool.org that has other languages than English, because Grammarly just has English. It's a bit less advanced than Grammarly but at least it has many other languages like French, German, et cetera.
Writing has a few values which are important. The first one is it forces you to pop down in clarity what is not really clear in your head.
Then you have a text that is searchable, which is a big value because then you can type command F on your computer and search in your library. It's like searching in your brain in a very quick way.
Okay, let's continue. And the topic on app of apps.
What are apps that make it faster to write Service Design Principles?
You're building your own Service Design Principle Library, you will work a lot with text. Having little utilities that do some of the work for you is something that is pretty lovely.
What does Pastebot do? It helps you to quickly get to your paste board and also then transform what you have copied. For example, if you copy a quote, which was written in all caps, it then helps you quickly to bring it back in a normal way of writing.
That saves me a ton of time.
Another one on Mac is Bettersnaptool. If you're working with multiple windows you can say, window go, left, window, go right, Boom. And you can then work super quickly.
A last one will be Hazel, that's one app that moves your files for you around on your computer based on rules. For example, I take a lot of screenshots to show elements of the Services Design Principles that I have seen.
And the way the Mac works usually is it just puts all those screenshots on your desktop. Which then usually then gets very messy if you're like me, doing dozens of screenshots per day.
After one minute that a screenshot has landed on the desktop, Hazel app, puts it on a folder called Screenshot. The next day it, it goes in the folder of my screenshots, and it removes all the screenshots that are older than one day. Which means I don't have to manage all these little screenshots. They are automatically placed on the right place for me.
The same happens for my downloads. This little app goes in my download folder and removes everything from it at the end of the day.
One other part of this idea of building your own Service Design Principle Library, try to be very efficient in it. Because the more efficient you are with it, the more chance there is that you will do it over a long period of time. Because it's not a chore.
Okay, Next question.
How to organize your Service Design Principle Library.
There is a few questions that you have to ask yourself when you are starting in this idea of creating your own Service Design Principle Library.
One of the first questions is you have to decide, is this something that is gonna be private, internal, or shared with the world?
Can you put proprietary information in it or not? Can you be super critical of everything or not?
On the tool side if it's just private, I don't care what is the tool that I use. But if something that I'm gonna share worldwide, it has to have some sharing functionalities.
So this is a big distinction that you have to make knowing is it private just for me, internal. Me, my friends, or our company. Or shared to the worldwide web.
This changes the way you write and the way you use the different apps to create your library.
If you do doing it in a team, one advice might be to work with what already exists. Instead of saying: "Oh, we are gonna create a new tool to capture all the Service Design principles". Maybe just work with what the team already has.
There is more chance that people of your company might jump easier on it. There is less friction. They already have a login for it. They already know how it works. So it's quite easy for them.
Then one aspect that is important to consider too is motivation.
Doing it just for yourself in a very private way is very safe. It means that you don't have to think too much about it.
But, if you can share it in some way, be it internally with friends or in an organization or publicly, it's motivating because you'll get feedback or you'll see that people react to it.
If you're doing that for over years, just doing it for yourself in a hidden way you have to be your own motivation boost every day. And one thing that I have noticed over years is when I have a a down period, and I receive a message from someone:
"Oh I just saw this principle. It really helped me. Thank you so much."
It really helps me to continue the daily practice of taking care of my Service and Principle Library.
Another advice when it comes to organizing the services and principal library is keep all the data in the same place. Don't have principles about work in one place, principles about life in one other place. Just keep them all one place because it's just gonna be easier to search, easier to manage.
The last part about this organization of your Service Design Principle Library is this idea that it doesn't have to be completely perfect.
You might have principles where you just have a hunch, a quick idea. But it's not very well formulated yet. And that's fully okay. They can live there.
You might have principles that are very well written, where you have references, you have different sources to it. You have even images that you took of different places in the world that that make this principle grow.
These are kind of very two opposite things. These things can live in the same library and it's fully okay.
We can have different stages of writing. You can have drafts, and then something where you say: "This is something that I'm publishing and that I'm sharing openly". Thinking everything in that library must be totally finished and perfect is super hard.
Let's continue with another question, which is,
How do you build a Service Design Principle library for, for a team or within an organization?
And that's a question that comes more and more from people around the web that say:
"Oh, I really love this idea that you capture these principle, these ideas for yourself. But how. Do you do that in a team?
Before I answer this, I have to say I'm not using it in a team myself. These are ideas more than things based on my own practice.
Have one shared library. It's gonna make your life easier as a team.
In a team or in the organization, you might need to have a bit of additional information or data to make these principles actionnable. That's where you might tend towards tools which are more like databases where you can then filter based on different pieces of information.
For example you tag your different principles by project. You say: "Hey, this principle could be very useful for this particular project that we have at the moment, or for this future project".
So when you start the project, you just open your Principlesz library and you see all the things that could be used.
The other thing is having the information about the stages of the experience. There are principles that are very useful for the awareness stage, where you try to get people excited about their service.
And there are other principles that are very interesting about the moment where people leave your service because they're disappointed and these are very different moments in the experience.
It could make really a lot of sense to have a tag or a category for each principle where you name, for what stage of the experience, it's.
If you're working with a Service Blueprint, then you can reuse the stages of your blueprint and have them also for your team library.
If you want to go even further to make it even more actionable, say:
"Oh, this is how much impact I believe we could have with by following this idea of this principle. And this is how much effort it would take."
If you are in a time where you say:
"Hey, we want to improve our onboarding experience".
You can then filter by stage of experience being onboarding, and then say: "what are all the low hanging fruit? Things that don't need a lot of effort, but might have a lot of impact.
And your library tells you: "try out these ideas". That's where it starts to be really a working tool.
Another last information to, to add if I'm working in a team on each of my principles would be to have a mention of the key stakeholders, the decision makers or team members, departments. So that you can say: "Oh, this principle, if we'd like to implement it, we are gonna have to work with marketing.
Or "this principle to make it go live, we gonna need an okay from this person.
Or " to make it real, we gonna need help from this external partner".
Now another question which is:
What's the mindset of someone who builds their own Service Design Principle Library?
There is always, always something new to capture and learn. I started this process of capturing this, Service Design Principle Library.
I thought, "Hey, if I get to 100, my god I'm done". And then I thought:
"Hey, why not try to go to 200". And now I'm at the stage where I already have drafts for 450. And I'm thinking: "I'm surely gonna publish at least 500". I'm already thinking that the day I will get to 500, I'll still have the same curiosity to find out new principles because life changes.
For example, as I'm now a dad, which I wasn't before, I'm getting interested in a lot of stuff about parenting. There is always something new to learn because we change, the world changes.
Another mindset: it's like running, you might skip one run, but in the end what is important is that you run nearly every day and that makes you a runner.
The same goes if you build your Service Design Principle Library over the years.
You're gonna do that for the next 30 years. That takes out a bit of the pressure out.
It will evolve. The things you're interested in will evolve, but also the type of contents that you are interested in will evolve. And the way you are collecting data, the amount of of details you put in will evolve.
Maybe at the start, will add a lot of information in every principle. And maybe at the end you'll just keep a few notes because you now know what is really important to you and what makes your projects go further.
So there might be big stages in the life of this library.
Now I would like to cover this question from Bernard Borg who asks.
"How do you categorize the principles? Do you have various subcategories?"
As I'm collecting the principles, I already know that they will end up someday in a book. I have the categories of the books I'm writing. Because in a book it's makes sense to have chapters.
The one thing that I really love is that having them by text makes them searchable. So even if I don't tag them, I remember, I wrote something about errors, I just have to search the word error and it will show me a lot of the content.
That's a tool that I'm using just for myself. That's why it makes sense for me to not over categorize in that way.
But if you're doing it in a professional or shared way in a team, then you might have to use categories so that it helps others that work with your library to get quicker to their results.
Thank you a lot for joining. We'll keep that in a Swiss fashion, which means we'll start on time and we'll end on time.
A big thank you to all of you for following this little adventure today.
Have a lovely weekend. Cheers.