What on earth does Harry Potter have to do with service design? Well, as it turns out, quite a lot…

At Methods, we run monthly workshops on a Friday morning where one member of the team will run a practical session to teach the rest of us about a particular technique they’re using.

I ran a session recently about a service design technique called blueprinting.

(For those non SD practitioners, blueprinting is a workshopping method for mapping how a service works by breaking it down to its component parts.)

This is what happened.


Blueprinting isn’t the easiest technique to teach in practice. It relies on the people in the room having a considerable degree of knowledge about the chosen scenario and subject matter. We use it with public sector organisations to solve wicked problems by stripping them back to their core component parts. And outside of that organisation these problems aren’t always the most exciting, even if they are necessary to improve the lives of both citizens and civil servants. So coming up with a subject and a group of simulated scenarios to blueprint posed me a problem in itself. Do I use an example project, which no one in the room except me knows anything about? Do I make up a project? How do I make it both interesting and not the most boring 3.5 hours of people’s lives, and also ensure that we actually simulate a real blueprinting session as realistically as possible…

Having a strong theme is quite important to overall success. Especially if that theme suits those with an exuberant and active imagination.

Which led me to Harry Potter.

Which brings me to key point number 1:

Feel free to use this workshop template, but only if you have some real Potterheads in the room. I took a risk and fortunately it paid off…

…because Harry Potter himself turned up.

Setting the scene

It’s always best to start a workshop by setting both the scene and expectations.

You don’t want people to get the wrong idea about what a session like this is going to give them, so it’s a good idea to set the record straight from the off. Don’t promise the world. There’s a danger that some people could see workshops as a miracle cure, a ‘fix all’ technique that works because we will just throw some ‘design thinking’ at a problem and put some post-its on a wall, and doing that will solve the problem…etc etc etc.

It doesn’t quite work like that. So make sure you nip this expectation in the bud early.

Be honest. Be energetic. Be firm. Tell people to put their laptops away, then alleviate the silent but inevitable groans by drawing attention to the abundance of snacks on the table…

Which brings me to key point number 2:

Buy decent snacks.

I purchased a selection of Co-op bitesized snacks including caramel shortbreads and flapjacks, a box of matchmakers, and a multipack of drumstick squashies (which were a massive hit).

A suitable disclaimer.

However, I qualified this disclaimer by saying that those who were here for magic were in the right place.

Methods happened to have won some exciting new business that very morning.

With this in mind, it was time to find out whether I’d totally misjudged this lot and the workshop was doomed, or was going to be a roaring success.

The warm-up activity.

Thankfully we had a good mix of Potter knowledge grades from 8.5s down to 0s, and once the experts were paired up with novices, we were ready to go.

First however, I did a bit of talking to kick things off properly.

What is service design?

At Methods, we use a design thinking approach to service and product design. It’s not reinventing the wheel, more stripping the wheel back to its core components, and adding a third diamond to the double diamond because let’s face it, 3 is better 2. To avoid sounding like Gillette, I’ll qualify this a little more by saying that design is an ever-changing discipline. The emergence of areas such as service design and product design in the digital space have meant that the designer’s toolkit keeps getting bigger, as we tackle all sorts of problems across the industries. Therefore it’s only natural that the core process evolves too.

The triple diamond approach.
The ‘explaining a service to your nan’ slide.

There are lots of definitions out there for what service design is, some better than others, and I usually turn to an excellent definition coined by Erik and Megan at Practical Service Design, especially if I want to sound intellectual.

Service design is a human-centered design approach that places equal value on the customer experience and the business process, aiming to create quality customer experiences, and seamless service delivery.

However, if I am explaining this to my nan, as I usually do at Christmas every year, I go with something like the following.

Service design is a process and methodology for finding out what the problems are (for an organisation) and deciding how best to solve them.

The point of the context slides is to not only sell the idea that service design is necessary and important in our work, but to also cement the idea that the facilitator of this workshop knows what he’s doing.

Stage theory — illustration courtesy of Erik Flowers and Megan Miller at Practical Service Design.

Briefly cover important things like stage theory, the service design toolkit, the relationship between products and services, as well as what blueprinting is and where it fits into an agile project in the design process.

Service designers are choreographers.
Discovery and Alpha design tools.
When you blueprint.

So what is blueprinting?

A blueprint is a visualisation of how a service works across a particular scenario, broken down into its integral parts:

  • Actions
  • Actors
  • Touchpoints
  • Systems and policies
  • Pain points, questions, and ideas

It is a group workshopping method to solve a problem by getting upstream of it. It doesn’t work if you don’t have the right people.

When explaining the idea behind blueprinting I usually turn to a hero of mine — the advertising legend Dave Trott, who talks about solving problems by getting upstream of them.


Words from a legend.

Think of blueprinting as the embodiment of this approach to creative problem solving. It’s all about making sure you are solving the right problem.

 

 

 

It works well as a problem-solving technique because it:

  • moves memory out of your head into the world, freeing up processing power
  • allows you to see connections and relationships you can’t easily visualise in your head
  • creates a shared understanding for teams. Now your team can be part of that distributed world you think with
  • facilitates knowledge transfer/learning — a great technique for anybody whose role touches service design/management
    A blueprint in the wild.

    But essentially, a blueprint is a narrative — it helps the team creating it see the bigger picture. And it’s also the glue that brings all the disciplines together: UX, research, business analysis, tech, policy…

    Fancy slide.

    To create a blueprint, you need 3 things: experience maps, a scenario, and that scenario broken down into steps.

    Blueprint ingredients (borrowed from Practical Service Design)

    Experience maps

    An experience map tells the end-to-end story of your service from a customer or actor’s point of view.

    What they are doing, thinking, feeling, hearing, seeing…from before the start using your service, to when they stop using it. It’s a bit like a more actionable version of a persona.

It’s a visual representation rooted in empathy, and provides the experience skeleton for blueprinting. Like a persona, it’s usually not a depiction of an actual real-world, single customer’s (or service actor’s) experience. It’s an aggregate of experiences compiled from customer research and the knowledge of subject-matter experts in your organisation.

 

Activity no.1

 


After explaining all of the above context in no longer than 15 minutes, it was time for the first activity. I split the groups into pairs (Potterheads with novices) gave them an experience map template, and (to give them a steer) put the following slide up and explained I had already conducted some user research that very morning…

User research.
The team making their experience maps.
The team’s experience maps.
Hermione Strangeville.

We ended up with a colourful array of first year students — from gender neutral Hillary, to Biscuit Drumstick Malfoy, to Hermione Strangeville — and some even drew their Hogwarts first year, using the range of blue, black, red and purple Sharpies I’d so thoughtfully provided.

Biscuit Drumstick Malfoy.
Hillary.

Read part two to find out how the team used their experience maps to solve the Hogwarts first year onboarding problem set by Neville Longbottom.