I’m a service designer whose always worked in design studios and agencies...until now. Towards the end of 2018 I wondered if I truly knew what it takes to make change stick inside large organisations.

I wondered what does a Monday to Friday feel like inside the same place for longer than a project. How do people talk about customer experience when a consultant isn’t there? Do user-centric projects ever latch on to in-house teams who have their own established priorities and ways of working?

In order to find out and especially because the mission of the company was very interesting to me, I joined OVO in Jan 2019. This post is about the 50 days that followed, including an update of day 500+ about how things are today.

Day 0: Defining a strategy
Tasked to find areas of opportunities and with freedom to choose where to focus first, I picked up my favourite design tool: the Service Blueprint.

In my experience, making a map is less about the artifact itself and all about the team, method and aftermath. Making a map requires me to talk to people who deliver key aspects of a service and quickly sense what the business thinks customers are going through. It doesn't matter if I've met them yet or understand what they do in absolute detail. The task is to say hello, explain why and what I'm doing and work together to paint a picture of our process.

In the past, mapping has also meant experiencing the service out myself (for example donating blood, ordering a washing machine, driving a van to deliver repeat medications...etc) and annotating my experience. It's also meant bringing non designers on board to map with me and most importantly, using the map to re-design services altogether.

Day 14: Divergent thinking
It took me 14 days approximately to get my head around team ceremonies, structures and resources available. The UX community stepped in to help me find my way and run me through what had been done so far in terms of mapping, I can't thank them enough.

Around day 15, I rolled out a big piece of brown paper and labelled obvious sections of our retail service focusing on what is true for the customer (research for provider, on-boarding new provider, using energy…).

To plot things on the map, I invited the team responsible for the desktop online account to help me think about what we 'knew' or assumed to be 'true'. The question was: 'What do people do and when?'. The task was to use post-its, answer the question and stick that post it up if the group you were in agreed.

In 35 minutes we had written down dozens of actions. Later, on my own time, I split the actions into two sets: triggers and behaviours.I knew these would come in handy later when looking at experience rather than process. Remember that the service blueprint is not about the customer's experience, it's about how we organise ourselves to provide a great service. I think capturing what triggers which behaviour is more useful inside a customer journey map, used to intervene specific journeys.

Day 21: Convergent thinking
The actions looked more like a list rather than a service blueprint. To move the map forward, I needed a new format. So on a new piece of paper I drew out a horizontal black line, plotted out the same customer stages and began populating it with actions. The post it’s above the black line were customer actions, while post its below represented company actions. Touch points were stuck on the line itself. I'd say it was important at this stage to keep things very simple, no overthinking what goes where. The objective at this point was to have a prototype of the service map that colleagues could react to.

Day 30: Expert time
Different subject matter experts in the business joined me as I created yet a new version of the map. My goal was to further understand each section of the map by adding detail. 'Experts', as I like to think of them, would talk about specific things (process, comms, customer feedback...anything) they knew about and point me in the right direction saying things like "if you need to know more about X, speak to this person". Word of mouth was crucial here.

I spoke to experts in blocks of 1 hour, asking things like:

• How does a customer sign up?
• Then what happens?
• Who makes that happen? Is that a team or an individual? When? How?
• Is there a human triggering that email or is it automatic?
• What system underpins that process? Why? Is it effective?
• Do we send customers any communication at this stage? Why?
• What do we do when the customer sends us this information? Why?

Day 47: Map version 1 finished!
At this point I had captured the key journeys that a customer goes through before, during and after coming on supply with us. We had mapped for example how someone renews their contract, switches away or gets a smart meter. Every phase of the map showed what the customer did, where, how and how we orchestrated our internal and external resources to support them.

In total I must've spoken to around 40 people. I interviewed them, we mapped together, we had coffee's, we had runthrough's of the map on the wall and we talked about how to use it. Interestingly, they also talked to other people, which meant I was approached by new colleagues about the map.

Day 50-100: The aftermath

• Immediately after the above, I created a Sketch version of the blueprint to share with the OVO UX community. Sketch isn't build for service mapping, so I will be using Figma or Miro in the future.
• Months later and after running a workshop, the acquisitions team made their own service blueprint. Even better than that, they are using it to re-design how customers join OVO and more.
• New colleagues who saw the blueprint on the wall approached me to create visibility and understanding in their own team.
• A new service designer was hired and she began mapping out how our new platform serves internal and external users.
• Businesses outside of retail reached out, interested to map their services and hire service designers.
• Leadership became more interested in service design.
• I travelled to different offices to 'roadshow' the map and use it to support different types of workshops and topics.
• I regretted not having a plan for what to do after the map because the fame was overwhelming! Jokes, it was fantastic to meet so many people and get so much interest in the practice.

Advice I'd give myself

1. Perspective rocks
Don’t expect others to understand what you're doing from the get go. Instead, accept that using design to problem solve is a new practice within most organisations and it is up to us designers to patiently and empathetically show it's value. A service blueprint therefore is not important on it's own, instead it’s the using of it and the minds it can open that matter. It's just a tool.

It’s important to do the hard work and put in the hours of research, active listening, synthesis and visual design needed… but remind yourself not to become precious about the deliverable.

I've made the mistake in the past of spending hours and hours crafting. This is troubling for three main reasons:

1. It makes service design be about form rather than function
2. It takes time away from spending time with people
3. It stops teams from making changes to the product/service itself

If your map is not being used, it needs changing. If you need to make it digital, do it quick. Never fall in love with it and pull a neck muscle again making it ‘pretty’. Accupuncture hurts.

2. Qualitative data rocks
A service blueprint does not hold user insights, like an experience map or a customer journey map might. As you can see on the following image, it plots out internal process and orchestration of resources.

Even though the blueprint displays key actions, it does not hold qualitative info about them. It won’t for example show the hypothetical frustration of waiting for an engineer to arrive or the confusion created by an email. Both of these being crucial to improve the service level. Don't stop at service blueprint.

3. Quantitative data rocks
Pair a service blueprint with an experience map (see image below from Adaptive Path’s guide to experience mapping). With an experience map (or similar), you’ll be able to have a conversation about the qualitative aspects of the experience and show the factual process data on the blueprint when appropriate— ensuring business and customer interests are discussed at the same time. Add important metrics too if possible.

No matter the format, make sure you bring in helpful information about the customer experience into the space (room, team, Jira, slides, stand ups, wherever) to help others see the full picture.

4. Tools rock
Having a strong toolbox and/or a mix of skills in the team is helpful. Having access to different design tools means that you can tell the story of your customer's experience with a video animation, a storyboard, a poster, a written story, a test with an HTML prototype, an engaging presentation...etc

Always use the tools you're quickest at to tell the customer story to the team so that the service blueprint doesn't take over. Speed is important, especially when working with small agile teams.

That said, make time to try new tools (why not create your own service blueprint?). Make your own tools and share them with others who might benefit from them. Making our products and services better and making our customer's experience the centre of what we do is why you're here!

Day 513: Update
This is a very late post so I can say that the 500 or so days that followed were fantastic.

I love how much I've been able to do and learn, how leadership supports my work and especially how the importance of holistic design has been voiced not only by me but by colleagues all across the business! Upwards and onwards!

Feedback always welcome on Slack or Twitter by the way.
Thank you so much for reading.