It’s been a while since we have spoken about service patterns. To recap, service patterns describes common behaviour as users use our services. They might want to check information, apply for something or book an event. If we understand the common patterns of behaviour, we can build services that feel consistent as users go from one service to another.
We left you hanging on our last blog post about prototyping our first pattern - “check something”.
Since then we’ve spent a lot of time thinking about what service patterns means for us and how we can apply them in the real world.
We’ve worked on 3 patterns:
- check something
- apply for something
- book something
It was exhausting work but we have documented it in our service patterns toolkit. Here’s how we did it.
Service patterns in action, ‘check something’
After a lot of thinking about patterns as a concept, we realised the only way to make progress was to put what we had spent so long mapping out into action.
We started with the ‘check my nearest’ scenario.
This scenario applies when users need to find people, services or assets based on multiple locations, criteria and preferences.
We trawled through services that we thought had a ‘check my nearest’ element from a user’s perspective. This was a lot of effort, but it really showed us what worked. It gave us a chance to think about how a user might benefit from what we were adding.
Forearmed with this knowledge, we went back to the drawing-board, Post-its aplenty. We mapped out what the ideal user-journey for this scenario would look like.
Then we built, iterated and refined it. This became our journey template for the patterns.
You’re going to need a journey template
The journey template includes what you expect. It defines user steps, user needs and phases. Then we added the really juicy questions:
- As a service what do you need to consider to make this journey great?
- What research questions do we need to consider (things that we cannot assume)?
- What data do we have or need to consider to help inform the journey?
Trying again, doing it better: ‘apply for something’
We moved on to the next pattern, ‘apply for something’ and we did it better.
‘Check something’ was relatively straight forward but the ‘apply for something’ pattern was much more complex. This was good because it helped us understand the relationship between patterns and how they depend on one another, especially in complex processes.
We knew that to really develop a pattern we need to understand the pattern what progresses from it.
Designing for the ‘apply for something’ service pattern
We worked through every service that had an application. It was a tough exercise. We described every service in detail from a user’s perspective and documented the good, the bad and bits in between.
It was this moment where we saw the importance of patterns - every application we came across felt different and many had poor user experiences, some were even downright confusing.
Essentially we found our purpose for patterns from this design review. We knew we needed to create a pattern that would prevent this inconsistency. In a recent blog post, Ben Holliday talks of the power behind the pattern, in particular, the need to “scale consistency”.
Making sure the bits that work, work together
Again we developed a flow of what a good application could look like. But this time we need to consider how patterns link together.
For example, how does a user move from a “check before applying” scenario into “apply for something we do”?
A date with destiny (and tech services): ‘book something’
At this point we were a couple of months in and still wading through a conceptual minefield of patterns, scenarios, journey maps and flows. We needed a service to work with so we could test our assumptions of an ideal journey.
Luckily, out of the blue, some colleagues from technology services had been following what we were trying to do with patterns and were really keen to try it out. They were working on updating a booking system and asked if we’d like to work on it together.
Crucially this happened early enough in the project for us to work together meaningfully. This was genuinely an opportunity for us all to try something new.
Collaborating out in the open
So we started the ‘book something’ pattern, but this time in collaboration with our colleagues in tech services. We decided to do one sprint and see how far we can get to. As both sides began to see how they could benefit from the process, this one sprint turned into many.
As a result of this collaboration it’s probably our best pattern yet.
Our best pattern yet
We followed a similar approach to ‘apply for something’ except this time we worked more in the open.
Our design reviews were as a big group. The ideas that came out of our findings were even bigger. This wasn’t just developing service patterns, this was developing invaluable relationships.
Then we started to design the booking journey, working with the scenario ‘book onto an event’. Again we got out our Post-it notes and whiteboard and we mapped every step of the journey. We challenged each other, we pulled apart each element.
It was tough and we did this for hours.
Challenging each other
Tech Services were able to give us insights we wouldn’t have had otherwise. Why you’d have to log in, why certain systems wouldn’t work together. Having a safe environment where we could challenge each other, meant that it was much easier to understand each other and the parameters we were working in.
This was an exhausting process. It could only work if everyone had the belief that they had an equal part to play in making services better for Essex residents.
But at the end of it, I was definitely tired.
For me having a tech perspective was really important. It gave us much needed challenge and it broadened our thinking on service patterns. It also got us out, working beyond the service design team.
What this means for the future of service patterns
This is the really exciting bit. We are continuing our work with tech services.
Together we are translating what a ‘book onto an event’ pattern looks like for a specific service. We are moving away from an abstract understanding of a pattern, towards applying a pattern to real life.
It’s given us confidence, friendships and a really solid way of working in the organisation.
We start with the users in mind. We think about what has prompted them to the service, what are their expectations and needs of us. Then with pen and paper we simply sketched what each phase of the booking journey with us could look like. With each phase, we thought about what functionality is required across the booking platform for this journey to be successful.
Having this means anyone can pick up a service pattern and develop one, rather than starting from scratch.
We are iterating the patterns as we go. The more we learn, the more it will change.
Explore our Service Patterns toolkit- read it, test it and let us know what you think! Drop us a note at service.design@essex.gov.uk
Leave a comment