You've maybe experienced that someone gives you a summary of a book and the summary is so, so long that you feel it's like reading the book.

A good summary is something that is short enough for you to start using it and reading it. And it's long enough so that you have the most important information in it.

That's exactly what a Service Blueprint should do for people.

It shouldn't show all the tiny details about the service. But instead give a good summary so that people can understand how it works in a quick way.

As Service Blueprints are very fun to create, there is a tendency to add details and details and details to them.

So when you have created a good version of your Service Blueprint, you can try this little trick:

Don't share that version, keep it well stored somewhere, and create a version where you remove some details.

And now compare the two and see which one is really the one that you should share to people that you think will not overwhelm them, but still give them enough information.

Many use the Service Blueprint, not just as a tool to describe how things are today, but to imagine how services could be in the future.

In that moment a Service Blueprint is like a prototype. Whenever we prototype, it's a good rule of thumb to not just prototype one thing, but to prototype several versions, and several versions that are very different.

Because this helps us to see that there are much more possibilities than what we thought in the first version of the Service Blueprint we created.

Here a good rule of thumb can be to have at least three versions.

Because when you just have one, you basically telling people: I've already figured everything out. And you feel like a bit. God-like figure which isn't so good.

When you just have two versions, it's a fight. It's either this version or that version.

When you have three versions, you show to people that there are many different possibilities. Even if you just designed three.

The Service Blueprint is not the end. It's just a tool to help you get started.

If you use a Service Blueprint to make a diagnostic of what's working well in the service, and what isn't working so well. Then this tool is only useful. If you change something in the service, based on what you learned from the Service Blueprint.

And if you use a Service Blueprint to imagine new services and new experiences, then the Service Blueprint is useful only once you really start to create those experiences. And to deliver them.

As with any methods like Personas, Business Model Canvas, or anything else, these are just tools to help us do the work.

They are not the final work.