A recipe for service patterns

By Imran Hussain.

I’ve been helping the Govstack UI/UX Working Group over the last few weeks. They have been focused on building an international service pattern library for governments around the world. It is a very ambitious project, and one where they plan to provide the tech stack that underpins the design work too. I wanted to get involved, so that I could learn what I could for the UK public sector, and bring some of the experience back with me.

Laurence Berry, Stefan Draskic and Betty Mwema, reached out and wanted to collaborate on some sessions and community strategy. I was excited to help as I love running co-design sessions, they are some of the most interesting and interactive types of session you will see. For this round of service pattern creation, we planned to run two hack days. We’d have liked to run more frequent, shorter events that were more spread out, but timelines were constrictive and didn’t allow for that.

Betty and Laurence had already put some service patterns together for Govstack. I was keen to dig into their methodology, learn from it, and see if I could add to it. I spent some time digging into the Govstack context, understanding the brief, understanding the timelines, and what we needed to put the service patterns together. There’s two things I realised:

Someone with good systems thinking knowledge has to compile the service pattern; it is hard to process that much knowledge and make it look simple. Quite often that is the work right there, making the complex look simple and straightforward.

The workshops I was creating needed to take into account elements with which you create a service pattern. Almost like ingredients for a recipe. Talking to Betty and Laurence – the ingredients were:

• Some real life collaboration with public sector people where the pattern is needed
• Information about the end users and what their needs are
• Information about more fringe users within their context
• An example flow that meets multiple needs
• Usability considerations from a service designer’s perspective

It is quite a lot of information to gather, and not easy to run a fun session whilst we were doing it. On hackday 1 we explored three patterns: GovChat, scheduling and admin interfaces. It was an action-packed session, where we had a lot to get through to get all the information in the ingredients list above. 

I wanted to give people plenty of time to work on all aspects of the service pattern, so hackday 1 was scheduled as a full-day 4-hour event. The day shaped up like this:

• Intro to Govstack and service patterns
• split into three tracks to work in groups on each pattern simultaneously:
  • Share real-life examples
  • Compare your real-life users’ to prototype personas
  • Map the “happy path” of the service pattern
  • Map alternative paths and edge cases
  • Reflect on what’s needed to use the pattern
• We got back together towards the end of the session to play back each tracks’ work, and celebrate the successes 🎉

Betty, Laurence and Stefan did a bit of a summary of the first hack on their Substack (link).

I switched things up for the second session, as we shortened it to a 2.5 hour session. We wanted to work on two patterns per person, so I had to design a session that was a bit more lightweight. The second session tackled e-signature, wallet and payments patterns. 

There had already been a bit of a GovStack session on the payments pattern, so we were able to stress-test the prototype in this second hackday. It was a fun way to stress-test it and find the gaps in the pattern.

It shaped up like this:

• Intro to Govstack and service patterns
• split into two tracks to work in groups on either e-signature or wallet pattern simultaneously:
  • Compare your real-life users’ to prototype personas
  • Map the “happy path” of the service pattern
  • Map alternative paths and edge cases
  • Reflect on what’s needed to use the pattern
• Short playback
• Comfort break
• Regroup for pattern smashing on the payments pattern:
  • Intro context and flow of prototype pattern
  • Discuss whether the pattern resonates with your working context
  • Throw scenarios at the pattern to try and break it
  • Playback
• Wrap-up the session and celebrate

The Govstack UX/UI working group are going to get together and comb through all the information and user scenarios we gathered during the hacks. They will analyse and group all the information and use the output to develop prototype patterns. These patterns will be well-evidenced from all the information gathered over months working with the community. However, it’s hard to plan for all eventualities, and there will inevitably be some gaps, or scenarios that the service pattern doesn’t resolve.

So, is that the end of the co-design? No. We need to look for further feedback and iteration once we have the prototype patterns. We want to make the service patterns as robust as possible, so looking for gaps and branching journeys is a natural follow on from this phase of work. We might get the chance to run some more pattern smashing sessions, which would be a really fun way forward.

It’s not easy building service patterns. There are so many scenarios and technicalities to think about. You have to be really focused and single-minded to get anywhere. Some of the information you need comes from others, so it is a factor out of your control.

You can only gain from the people that you have gathered. As stated above, some of what you need is extracted from the audience present. So, it is somewhat out of your control. You have to hope you are able to gather the correct people to represent a number of different user and service scenarios. Otherwise, you will need to go back out three or four times, until you get a requisite amount of research to make the pattern robust.

Less is more. The more you discuss different user scenarios, the less detailed the service pattern becomes. This sounds unusual, but there are fewer common touchpoints, the broader you go with user use-cases. A service pattern needs to be somewhat zoomed out to make it more applicable to different contexts.

But also, more is more. Whilst you need a zoomed-out service pattern, you need to have enough information for the pattern to be useful. This is why you will see sub-patterns and different branches of journeys with some service patterns. Govstack go further than this by mapping and providing the underlying tech needed to deliver the service too.

Context is critical. It is not simply about what level of zoom is useful, the context of the service is important too. There will be no universal service patterns, as the use cases in different countries and different sectors are so different. Ultimately, you will need different subsets of service pattern for different situations and sectors. This is probably reflected in the number of groups investigating service patterns out there. I think everyone is better of collaborating and sharing user scenarios, rather than flying solo. I will be recommending that GovStack join up with some of the other groups and collaborate where they can.

A co-designed library needs consistency and a contribution model. This is so that iteration can happen on service patterns over time. A standardised model will also help build consistency in the quality of the patterns longer term. I talked about the ingredients for a service pattern above, this would be the recipe to help deliver it.

Do you have an ingredients list or recipe for service patterns? If you have developed them, hit us up in the comments or via the GovStack Slack Channel.