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.

Planning for the hack days 

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

Running the hackdays

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

What’s next?

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.

What I learnt from the process

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 more broad 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 [link].

Running the first two conferences was fun, but they took a long time to plan. As with any large face-to-face event, there were logistical challenges and a significant amount of red-tape to get through. Running a smaller event, from a GDS office allows us to bypass a lot of this and put something together quickly.

Honestly, paperwork and approvals shouldn’t change the type of events we run, but the planning phases for this year’s #DSDay24 events stretched way longer than they needed to.

We re-assessed and updated our the design system’s community strategy recently. On reflection, we realised that the larger events have limited what we have been able to run for the community, and there is a sense we can deliver better value for the time invested. Delivering value for taxpayers’ money is the bottom-line at the end of the day, so a switch to a different way of doing things was necessary. Running smaller, more frequent events allow us to be more dynamic and responsive to the users’ needs.

Back to co-design

This situation is really timely, as I’ve been meaning to get back to creating things with the community. The co-design experiments I ran a few years ago were challenging and knotty, but allowed me to work directly with designers and developers across government and the public sector. This year has left me pining for some of that direct contact with the users our team serves.

#DSDay24 events thus far were community-led, and I worked with a lot of community members on the session format, content and themes. But essentially, our team provided a physical platform for the community to show off their skills and knowledge. All the heavy lifting was done by talented individuals, who are part of our community. All we did was create space for this brilliance to happen.

Right now, having sessions where we are more in control of the planning and can deliver to shorter timescales, seems a better fit. A variety of events has kept our user base interested over the past couple of years and we hope we can add some variety to this year too.

Organised chaos

We’re running the third Design System Day as a hack day. The theme is bringing the design systems in government closer together. This is something I’ve been talking about for a while now, but we haven’t had capacity on the team to prioritise this. I’m glad it’s something we can swarm on as a community, and get done collaboratively.

In the time since this has come up in community discussions (around a year), there are version of this that have sprung up in the wild.

It may seem like the topic has been dictated by the team, and that the community has had less input on topic. However, this was taken from our priority list from the Government Design System Assembly (board here), which is a collection of teams who run design systems in government. All of the members of this group are not only community members, but key stakeholders that the GOV.UK Design System is looking to foster relationships with.

The hack will be interactive on the day, with attendees expected to help shape the problem space and design solutions as well. The stages of the day have been planned: sharing user needs, ideation, feedback, and show and tell. However, user needs will be defined on the day, groups will be formed based on attendees’ priorities, and any output will be based on how people navigate the challenges on the day.

It could be chaos. But it will be exciting for sure.

I have run designathons and co-design sessions like this before. You can’t reliably estimate what kind of output you will get from a hack like this. But based on the plan, we will gain a bunch of user research, some prioritisation from the community, and a variety initial prototypes from a bunch of very talented designers. Which sounds like a very productive day to me.

We’ll see how it goes. The plan is to iterate the format and run a number of other hacks on different topics throughout the next year.