How to use a Service Blueprint for better prototyping?
In short: Create a full Service Blueprint, select the parts that aren't obvious, and then do a ping/pong between the blueprint and prototyping.
The 2D to 3D dance move
We can use a Service Blueprint to create a sort of dance, where we move from 2D to 3D, as my mate Emmanuel Fragnière often puts it. We move from a flat plan, the Service Blueprint, to something tangible, the prototype.
Then the dance move continues. We go back to the blueprint to adapt things based on what we learned from the prototyping, and so on.
The break in the dance move: selecting the risky stuff
We don't always need to prototype the whole service idea. Often we don't have the time for that. In those cases, before going from the Service Blueprint to the protoyping we need to select what we want to prototype.
Here you can choose your flavor of selection method:
Obvious versus new: you don't prototype the things that are already well known (like a registration form) but focus on the things that are new for the organization that you design for.
Risky: you look for the parts in your prototype for which there is the most risk of things going to shit, or where you just don't really know how that works. Similar to what's done in an assumption mapping process.
High investment: you prototype first the things that would cost way too much to fix later. There are things you can easily change and update later, and things that are a pain in the ass to modify. Focus on the the ones that are a pain in the ass.
Backstage of this article
This article was illustrated on a refurbished Remarkable II tablet and written on the tablet with a folio keyboard.