Check out my new project, Practical Service Design!
User Experience at Hello Erik

My Service Design Elevator Pitch, Part 2: Blueprinting

Posted February 11, 2015

Last post, we left off with:

And by doing so, THAT is what gives us the ability to really apply service design as it is meant to be applied: for root cause analysis and remediation for entire experiences.

But that will take another (much taller) elevator ride to explain.

Well, it’s time to press that button for floor 100.


The next step in the pitch is sharing what a service design and blueprinting project entails, but more importantly the reason why we’re doing things this way, and not another.

To solve deep, complex issues that span teams, touchpoints, and channels, you have to really get together and focus (and finish) the end-to-end, surface-to-core, view of the scenario of what you’re trying to solve. You aren’t trying to just fix the snowcone machine experience in the amusement park. That might be how a problem is approached if you’re product focused, or not accustomed to thinking surface-to-core, end-to-end.


What you’re solving for is the amusement park – and the snowcone machine might be the lever for that whole experience. And it might be where you’re getting key pain data from. But remember, you’re solving for the park experience, which is composed of many snow cone machines.


For any complex experience that is going to have perspectives from many people, if you don’t get a critical mass of knowledge and documentation of the complexity, it’s difficult to really move forward with that true comprehensive view. The service blueprint is an artifact in the same way that a real blueprint is – it is an activity and tool, but it isn’t just an exercise and something you workshop.

You literally can’t build or diagnose issues in a huge skyscraper without knowing what is going on. And the odds are, the people who built the original skyscraper are gone, have forgotten, or the thing was built in chunks at different times, by different people, following different sets of rules.


You need that view to generate the work it takes to fix the overarching problem you’re trying to solve. Because like the original construction of multiple parties, the new work will probably be done by multiple teams, in multiple places, and possibly different channels, contexts, or products/services. Only this time, you’ll have the view of the whole thing and know what-connects-to-what, and where the root causes exist.


In simple terms, it’s one of the best ways you can spend your time as an ecosystem that is truly solving for ecosystem experiences, putting effort into things that fix much more broadly than a focus on the interaction of a certain product or screen. This doesn’t diminish the work of touchpoint UX at all; UX solves for focused points in the overall experience. We can go back to the amusement park, or the skyscraper analogy. You UX a snowcone machine or elevator controls; you service design the park and the building.


It’s how service design work, and it follows through on the promise of “thinking end to end” by carrying out your actions with end-to-end teams and projects. The project team represents the service they support; the internal team must mirror the external experience.

It just takes a time investment to get the information gathered and agreed upon. You want to be sure you leave with something that is actionable, accurate, and doesn’t leave you with missing information that prevents the group from moving forward, or worse, moving forward with bad information and an inaccurate end-to-end, surface-to-core view.


It is a big chunk of time to do a real blueprinting project, but it’s that deep, complex work and derives its value from the team knowledge. By working together on a single artifact you are able to find the opportunities to fix or improve in ways that can effect the whole ecosystem and downstream experiences.

This is where service design comes full circle. It started as team assembly, to information gathering, to central artifact creation and understanding, to generating work. Roadmaps can be created, resources can be assigned, the plan comes to fruition by the coordinated, informed focus of labor. And that’s how experiences are improved and created. Not through just service blueprinting workshops, but through the clarity and solidarity the shared understanding empowers all involved with.

For any business in any industry, if human beings are your customers, what you provide is an experience. There is no debate or alternate interpretation. This means that you can invest in designing at the ground level altitude of the specific interfaces on a set of controls, all the way up to the altitude of manipulating an entire ecosystem.

Well, this is my floor. Thanks for sticking around. I told you we’d need an exceedingly tall elevator to get through all this.

Isn’t it nice to see things from the top though, isn’t it though?


I love all things experience design. I work as a Principal Service Experience Designer at Intuit in Mountain View, CA.

3 Responses

  1. My Service Design Elevator Pitch, Part 1
    My Service Design Elevator Pitch, Part 1 November 10, 2015 at 6:48 pm |

    […] But that will take another (much taller) elevator ride to explain. Check it out in part 2 of this 2 part article: My Service Blueprint Elevator Pitch, Part 2: Blueprinting. […]

  2. Alan Joseph Williams
    Alan Joseph Williams March 8, 2016 at 8:28 am |

    Great post—is there a good example of a Service Blueprint artifact (or bundle of artifacts) out in the wild? I’m looking for something to serve as a “default from which to deviate” for teams at Code for America.

  3. Lex
    Lex July 4, 2016 at 2:52 am |

    Haha, nice pictures. Thanks for detailed explanations.

Leave a Reply

You must be logged in to post a comment.