Hogwarts Express

This is the final instalment in a two-part series about the service design technique: blueprinting, and how the Methods team applied it to the world of Harry Potter.

Read the first part. 

When we left off in the previous article, the teams had successfully created experience maps for their Hogwarts first years, and in the process, invented a series of characters JK Rowling herself could be proud of.

This part covers what to do next.

The team’s experience maps.

So what do you blueprint?

With one part of the ingredient list done (the who), the next task is working out what you 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.

Writing a scenario 101

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).

An example Harry Potter themed scenario.

The scenario should not cover the entirety of your experience map, only parts of them (and can cover more than one, it depends on 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).

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.

Digital Director Gordon being theatrical.

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.

Ask why why why why why why why why why until you get to the root of the problem.

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.

You can’t solve the right problem without insights.

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.


My research slide.


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.

Blue star team’s blueprint.


Yellow team discussing how one goes about setting up a wizard bank account.


Gavin from blue star team sneaking a look at yellow star team’s blueprint.


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.

How to take it down in a helpful way.

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 the automated postal delivery systems, no more owls, some sort of wizard Amazon, and a more reliable replacement for the fat lady.

How to run a Future Blueprint session.


Blue Start Team’s Blueprint (Thanks Jack).


Yellow Start Team’s Blueprint (Thanks Charlotte).


Big thank you slide.

Ben Lyons-Grose is a cat-enthusiast, a tea-advocate, and a novelist turned designer.

He is also Experience Design Lead 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.