Summary of the video
Have one shared library for service design principles within a team or organization to make it easier for everyone to access and contribute.
Use tools like databases to make the principles more actionable and filterable based on different pieces of information.
Tag principles by project to identify their relevance and usefulness for specific projects.
Consider the stages of the user experience and categorize principles accordingly.
Assess the impact and effort required for each principle to prioritize implementation.
Include mentions of key stakeholders for each principle to identify collaboration needs.
Video transcript
Video transcript
This transcript was generated using Descript. So it might contain some creative mistakes.
How do you build a service design principle library for a team or within an organization? And that's a question that comes more and more from people around the web that ask me these questions like, Oh, I really love this idea that you, capture this 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. So these are ideas more than things based on my own practice. So the few ideas that I will have to share are these ones. First, have one shared library that again makes very a lot of sense, just having one place where people go and not multiple ones, it's gonna make, your life easier as a team, because everyone knows where they have to put stuff.
The other element is... When you're working in a team or in an organization, you might need to have a bit of additional information or data to make these principles actionable. And 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, in a team, what might make a lot of sense is that you tag your different principles by project. And that 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 that when you start a project, you just open your principle library and you see all the things that could be used for it.
So this is one information that you could add that will make it more useful in a professional world. And then the other thing is having the information about the stages of the experience. So there are principles that are very useful for kind of the awareness stage. You try to get people excited about the 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. So I think it kind, it could make really a lot of sense to have, again, a bit of a tag or a category, for each principle where you name.
What stage, for what stage of the experience it is. And here, if you have, if you're working with a Service Design Blueprint, or a Service Blueprint, then you can reuse, the stages of your Blueprint, and have them also for your for your, library in your team. And then if you want to go even further and to make it even more actionable, and this is, I think, especially interesting for these very early ideas of Service Design principles, where you can say, Oh, this is how much impact I believe we could have with.
By following this idea or this principle, and this is how much effort it would take.
Because then, in the future again, if you are in a time where you say, Hey, we're going to improve, we want to improve our onboarding experience. You can then say, filter. by stage of experience being onboarding, and then say, what are all the low hanging fruit, meaning 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. And that's where it starts to be really a working tool. This might answer a bit the question of how do you categorize the principles do you have various subcategories, it really depends on the needs. If you are in a professional sector working with a lot of people, these elements might be very useful, for example.
And, another last information that I would like to add. If I'm working in a team on each of my principles, it would be to have kind of a mention of the key stakeholders. Being the decision makers, or team members, or maybe it might just be departments. So that you can say, oh, this principle, if we'd like to implement it.
We're going to have to work with marketing, or this principle to make it go live, we're going to have, we're going to need an okay from this person. For this principle, to make it real, we're going to need help from this external partner. And this again helps you to, say for example, you're going to have a coffee with the marketing team within your organization.
You can go and filter in your principal library in CA. What could be all the principles that make sense for the marketing team? And then, based on that, you can already give a few hints of these elements in the coffee conversation. Getting a bit strategic and lobbying before you even share with them all the principles in details.
A community question
This question was part of the fourth Service Design webinar. You can rewatch the full webinar for free with all the show notes and slides.
✨ Made with assistance of AI.