From artefact to asset: A better way to think about service blueprints
There’s a quiet assumption baked into much of modern service design practice: that a “good” service blueprint is a finished one. Neatly structured. Perfectly aligned. Polished enough to present.
After more than a decade working across organisations, I’ve come to believe the opposite. You shouldn’t aim to finish your service blueprint at all, because the moment you do, it stops being useful.
In today’s remote-first environment, online tools have changed how we work. They’ve made it easier than ever to create clean, visually compelling artefacts. But they’ve also nudged us toward valuing polish over progress.
Pre-COVID, service blueprints rarely looked “done.” They lived on walls, layered with post-its, insights, risky assumptions, and half-baked ideas. Teams stood around them, debated them, pulled them apart, and iterated them in real time. They were messy and they worked. Not because they were complete, but because they were active.
A service blueprint is not a deliverable. It’s a snapshot. And snapshots age quickly.
The AS-IS state you map today begins to drift the moment it’s captured. Customers change, internal processes shift, priorities move. What felt accurate last week can already be out of date. Yet many teams still treat blueprints as static artefacts to be finalised, signed off, and filed away. This is where they lose their value.
For leadership, this presents a subtle but important shift in how we evaluate good practice.
The question is no longer: “Have we got a finished blueprint?”
But: “Is this blueprint helping my teams think, decide, and act?”
Because the real value of a blueprint isn’t in how it looks. It’s in what it enables.
Does it bring the right people into the conversation?
Does it expose gaps, tensions, and opportunities?
Does it support better decision-making?
Does it evolve as the service evolves?
If the answer is yes, then it’s doing its job, whether it looks polished or not.
For practitioners, especially those earlier in their careers, there’s often pressure to produce something “complete.” So here’s the reframe I offer teams I work with: A blueprint isn’t meant to be perfect. It’s meant to be useful.
That means being clear on:
The purpose of the map
Who needs to engage with it
What insights you’re trying to unlock
What decisions it needs to support
What problems it should help solve
Everything else is secondary.
The truth is, service design has never been about producing artefacts. It’s about creating clarity in complex, changing systems and that work is never really finished.