How to teach service design using wands, wizards, owls, and Hogwarts
Part 1: Blueprinting 101
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…
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).
However, I qualified this disclaimer by saying that those who were here for magic were in the right place.
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.
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.
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-centred 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.
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 in to an Agile project in the design process.
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.
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
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…
To create a blueprint, you need 3 things: experience maps, a scenario, and that scenario broken down into steps.
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…
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.
So what do you blueprint?
With one part of our ingredient list done (the who), it was onto the question of what we should actually blueprint…
The overarching theme of the blueprint should be a key scenario that takes place across customer experience and service delivery. An end-to-end view of an experience that spans some sort of start and finish.
To find out what these are you usually have to do some digging around, conduct both user and stakeholder research, and then validate them beforehand with the Product Owner, and relevant SMEs.
But beware — a scenario is not a user journey. It’s a signature moment, often one of pain (which is why you’re blueprinting it — to alleviate the pain and make it all better for the customer(s) and the service actors).
The scenario should not cover the entirety of your experience map, only parts of them (and can cover more than one, it depends who is involved).
Use the ‘doing’ part of your experience maps to help create it — which is why it’s always useful to make these maps for both the customers and service actors involved, so that you have a full view of who is involved, when, and where.
Activity no.2
So we had our experience maps, we had our scenario, now we needed to break it down into steps.
This is where I was relying on the Potterheads and their expert knowledge. I thought it was a good idea to brush up on my own already fairly substantial Potter knowledge, so I read some webpages on the tube that very morning. By the time I got to the office, I’d remembered/discovered that Muggle borns receive their letter by muggle post, the Sorting Hat gives a different song every year, and girls are allowed in the boy’s dormitories (but boys aren’t allowed in the girl’s dorms).
Whilst the pairs were presenting their experience maps back to one another I cunningly went around the room and put either a blue or yellow star on each, making sure that both teams had strong Potter knowledge representation. The team now split into those two groups and began building out their steps.
A few quick tips about breaking scenarios into steps
- Add the end goal first (in the case of this scenario is: student goes to sleep in the dorm)
- Aim for less than 25 steps, otherwise you’ll be there all day and your arms will fall off
- The scenario should not cover the entirety of your experience map, only parts of them (and can cover more than one, it depends who is involved)
- Use the ‘doing’ part of your experience maps to help fill them out — which is why it’s always useful to do them for customers and service actors
And finally the number one rule of breaking up a scenario, which also happens to be key point number 3:
You should know your scenario and steps, and have validated it with your Product Owner/SMEs, before the blueprinting session.
Blueprinting ‘jidoka’ style
We use a ‘jidoka’ style method of blueprinting. This basically means asking ‘why’ a lot. It’s a technique I adapted from the resources developed by Megan and Erik at Practical Service Design (so big shout out to them), and one we’ve used with several public sector organisations such as the Education and Skills Funding Agency (ESFA), the Institute for Apprentices (IFA), and The Advisory, Conciliation and Arbitration Service (ACAS) to solve problems and come up with ideas.
The jidoka blueprinting technique is inspired by an old concept for handling and solving error that was coined by Toyota Group assembly line. It means: automation with a human touch.
If production line employees thought they saw an error, they pulled a cord (the andon) to stop the line.
Experts then converged upon the problem area to determine the cause, asking — “Why? Why did it happen? Why is that the reason? But why did that happen? Why was that the cause?”
The philosophy is to ask why as many times necessary to get to the root cause of the problem and then fix it so it never happens again .
To begin with, you build out the blueprint of the scenario for both what’s happening frontstage, and backstage — the what(steps), the who(customer, service actors), the how (touchpoint, systems, rules) and then you ask why — a lot. The whole team writes pain points (drawn from your experience maps and the heads of your SMEs), questions they think they might need to go back out into the field and ask a user, as well as any other questions or ideas about how we could do things differently.
Third and final exercise
So having explained all of this to the team, it was time to blueprint our scenarios…
I gave the teams some more ‘user research’ but generally let them and their imaginations do the rest.
It took about an hour for each team to flesh out their blueprints and add as many jidokas as possible.
Which brings me to key point number 4:
Encourage everyone to add as many jidoka post-its as possible. Get people on their feet. Remove the tables and chairs if you need to. An empty blueprint is not a helpful blueprint, so you need as much on there as you can.
As a final flourish, I gave each team a blue or yellow star (impulse buys at Ryman that morning even though I had no clear plan for them) and instructed the teams to place it on the blueprint to mark a key or vital area of pain.
Takeaways
I finished up the session with a few top tips and takeaways, which I rattled through very quickly because it was lunch time and all the snacks had been eaten.
Some other top tips that I’ve learnt from doing this multiple times:
- Blueprinting is demanding on the facilitator. That’s why it’s best to have 2. (I once ran 3 separate sessions alone, covering 12 scenarios, and it almost killed me)
- Ideally you have 2 facilitators and a Product Owner to help keep things on track
- Do lots of work in advance. Work out the steps and put them up, as well as the Y axis labels
- Then the first stage should be quickly running through the steps to validate them with the group, moving some around where you need to
- Once you’ve documented it make sure you share it with the team (and beyond if you need to) so they can add anything that was missed, or has since come to them after the session. A blueprint is not a static identity, it should live and grow with the project
So — what’s next?
How do you take these problems, and get upstream of them to turn them into solutions? The hard part is done — after documenting and sharing it with the team and those stakeholders who couldn’t make the workshop (I usually do this using RealtimeBoard or Sketch) — next comes the fun part where you start to sketch what the future could look like.
And in the world of Harry Potter, that future world is one of automated postal delivery systems, no more owls, some sort of wizard Amazon, and a more reliable replacement for the fat lady.
Ben Lyons-Grose is a cat-enthusiast, a tea-advocate, and a novelist turned designer.
He is also Head of Service Design and UX at Methods, a digital agency that works with government to make public services better.
Get in touch at ben.lyons-grose@methods.co.uk if you want to find out more about Methods, service design, blueprinting, or Harry Potter.
