One of the classic tasks of a service designer is to create a customer journey map or service blueprint. Following meticulous, wide-ranging research these dense, detailed and occasionally beautifully diagrams emerge. But then what? Who is the recipient of this work, and what are they supposed to do with it? If you've been on the receiving end of these deliverables, perhaps this is something you too have asked? Maybe the same applies if you've toiled over their creation yourself.
All research and analysis should be undertaken with a purpose
There should be both an end goal and an immediate next step in mind, or the time and effort can be wasted. And remember that's not just the service designer's effort, but the precious time of the research participants too. That's particularly pertinent when you're undertaking internal service design, where the participants in journey map research – the ‘customers’ in question – will be staff taking time out of their busy day.
We recently ran research to determine the customer journey for some local councils' internal functions. Adur and Worthing Councils approached us with the task of mapping their human resources (HR) processes. They had a very specific reason for doing so, which meant we had to think hard about how we communicated our findings.
In a scenario still sadly familiar in public bodies and other less design-aware organisations, the Councils had procured a new HR system without talking to the people who would actually use it. Fortunately their lone Design Manager had got wind of this and insisted that, before rolling the system out, research was undertaken with its users. The end goal of the research was to ensure that, when the new system was set up, it met users' requirements and didn't repeat the same mistakes as the system it was replacing.
What wasn't clear at the time was what those mistakes were. What the Councils needed from us was some articulation of the current experience of the HR processes, in order to highlight the pain points that a new system should solve.
The kind of services we were looking at included onboarding staff and recruitment, booking holiday, and claiming expenses. It was clear that those couldn't be done entirely digitally, meaning we were mapping a service delivered only partly by a digital product – a classic internal service design problem. This presented a challenge of how best to visualise the information in a way that would be powerful enough to be useful.
Collaborate on how you’ll communicate
We worked with the Councils early on to determine what we could produce that would be of most use to them. In this case we needed a human-centred map which would provoke conversations and point a spotlight at the current system.
We ran our research sessions and began the process of synthesising our findings. Going back to first principles, there were really two dimensions that were captured: the actors (people) in the system and actions (steps) that they take. Rather than try to map the entire lifecycle of HR actions an individual employee might take, we mapped each process separately using the same visual language. What we produced was a diagram to show simply what happens in what order, and how people are feeling in the process.
Added to that was an executive summary of the systems used (an ultra-lightweight service blueprint). This was useful in and of itself, but also unashamedly propaganda. By listing the systems, decision makers would be able to see at a glance just how many were used to achieve an outcome, when maybe one system should suffice.
We gave the Councils' Design Manager an early draft of the deliverables to ensure the concept would be useful, bearing in mind the purpose was to provoke conversations and point a spotlight at the current system.
The final versions of the maps were designed to be printed out and taken to meetings with Procurement, Human Resources and Executive departments. And they did their job. By helping people understand the current system far better, and how it affected real people in their day-to-day working lives, the Councils were able to go back to their software vendor and make changes to what will be purchased and improvements to how it will be configured.
Without this work - without asking how people use the current system, where its failings are, and being able to communicate that convincingly to people in a position to make change – the councils would have spent a lot of tax-payer’s money on a new system not much better than the one they were replacing. Now the new HR software should slot into the existing processes and enable council staff to get on with helping citizens without being bogged down in HR tasks.