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].

We’re hoping to do a tribute to Vicky as part of UK GovCamp, which she was planning to attend. I started to draft a message for the opening ceremony, which I have found cathartic as it is helping me process my feelings.

I’m sorry to be the bearer of bad news, in case you haven’t heard, but a dear member of the community passed away last week in Vicky Teinaki.

Vicky, or Vi-y, as she was affectionately known in the North East, was a catalyst for design and the public sector. She was not only a friend, but an inspiration and hero of mine, as she will have been to many others.

She was kind, humble, witty, knowledgeable, thoughtful, hard-working, curious and prolific at whatever she set her mind to. When I first met her, I thought she was a content designer because of the amount of writing she did online. Turns out it was one one of her many skills; she was an interaction designer, former developer, design researcher, champion colourist, accomplished live tweeter, and keen traveller.

She had a voracious appetite for knowledge, reading more than anyone else I knew. She had the uncanny ability to process that knowledge and apply it to whatever she was working on. Her brain was truly a marvel.

We got to work quite closely together as part of the GOV.UK Design System. She was so generous with her time and her work had a huge impact in making things better for citizens. She was a frequent contributor, a key part of our working group, and frequent speaker at our events – such as Design System Day. In fact, Vicky so frequently spoke at our events, that our team joked that there was a permanent “Vicky Teinaki slot” in our event schedule.

Vicky was so capable, that she could have been very well compensated for her work if she were a bit more mercenary. But she chose her roles based on the impact she could have on the public sector, and how much she could help citizens. A testament to her values and integrity.

She was a natural leader. Someone who drew you in with their passion and enthusiasm for their work, whilst being humble with the amount of knowledge she possessed. And she was a tireless advocate for everyone else too. She often tweeted about the importance community management, put me forward for talks, and turned up to my talks to live tweet them (back when Twitter wasn’t sh*t).

Amanda Smith, used the phrase #GovCrush a few years ago, to describe people whose public sector work you admired from afar. Vicky was my first GovCrush. She made me feel excited about working in the public sector.

I just wanted a bit more time with Vicky y’know. The public sector and design world has lost a remarkable woman. She will be sorely missed.

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.

Functioning communities do not run themselves, especially those that actively ‘create’ together. That’s where a community designer, like myself, comes in; to build relationships with our users, find out their needs, and work with the team to design solutions. I’m there after things have gone live too, checking that things have landed as intended, feeding back to the team if they haven’t. A community designer is there for the whole user journey but where the community is the service.

As a team, we’ve been doing collaborative design for a few years and continue to iterate on our processes. When I joined the team, user research showed that users wanted more visibility of our roadmap and decision-making processes.

We’ve been working for years to break these problems down. Part of the solution was the community values we introduced to the team in 2022:

We try to embody these values whenever we interact with our community. That could be on support channels, on monthly calls, workshops and conferences.

Design System Day

Design System Day is our annual flagship conference. It started as a way to pick our community up after the summer lull, and it’s proving really effective at doing that. If we have one big-bang event for the year, this is it.

We’ve endeavoured to make all forms of contribution more participatory, experimenting with co-design, running open design workshops, crits, and testing sessions. This requires a lot of engagement work and a highly motivated, switched on community. During summer, when people take holidays and spend time with children during their school break, the appetite for extra-curricular activity is muted.

We use Design System Day as a re-energiser for the community, it brings focus back onto the design system’s collaborative work and draws even more eyes to our community. The event perfectly aligns with our open-source contribution model and with our community values.

Be Open

The GOV.UK Design System is an open-source platform and the team share our roadmap online. We do regular show and tells at our monthly calls, and we follow this up with a larger showcase at our events.

Here’s our showcase from the first Design System Day event earlier this year:

And we encourage the community to share what they are working on too. 

Be Inviting

Our community work is all about making people feel that we want active participation in our design system. We have a collaborative philosophy and welcome input in sessions throughout the year. We consider contribution to be anything that helps bolster our community and make it better. This can be attending an event, giving an answer during a discussion, spotting a spelling mistake on our site, sharing how you used a component, through to contributing a new component or pattern.

Design System Day is essentially a celebration and showcase of our community. We had an open call for speakers and almost all (9 of 10) speakers came from this call for speakers. We also invited Greg Macoy, a local speaker from Liverpool to speak about working with local charities and making positive change in the area. We like to pay tribute to the city we host in, and talking about local user needs is one way we do that.

Transfer Power

To stop our design system being too top-down, it is important to hand over some decision-making authority to our community. After all, most of the components and patterns that sit in our product are contributed by external users. We have an impartial, external panel of experts that make up the GOV.UK Design System Working Group, that have the final say on whether components and patterns are ready to launch. We also now co-design all our components and patterns, running collaborative kick-off sessions, ideations, crits and launches.

Design System Day helps that process of transferring power. It is our highlight event of the year, and that’s why we insist on putting our community members front and centre. We essentially create a stage for our community to showcase their work and skills. Every talk is user-pitched, drafted and delivered; much like any other contribution to the design system. The agenda is shaped by the community, for the community, and we love being able to give people that agency.

Educate

As with any good community of practitioners, we want members to learn new things from being part of the community. Whether chatting on Slack, sharing examples on Github, or discussing in one of our monthly chats, our community members have the ability to make new connections and share best practice.

We encourage collaboration, and one thing that we hope to see is community members working together on new projects and achieving something collectively. On Design System Day, we were lucky to have sustainability lead Ishmael Burdeau talk to us about his drive for services to have public sustainability statements. You can watch Ishmael’s talk here:

We hope it inspires you to take action in your service. You can join the Civil Service Climate and Environment Network and discuss on the Cross-Government Slack channels #sustainability and #green-software-development.

Show Gratitude

We like to say thank you to our community members for the hard work they put into making our product great. We put together stickers, credit people in release notes and send thank you messages to our speakers.

Design System Day is another contribution to the design system, and we love when people take part. 

There’s another opportunity to get involved with our community, a Design System ‘hack’ Day is coming up on Thursday 28 November 2024 with tickets on sale from the week of Monday 4 November 2024. Find out more here.

This post has been duplicated from the GDS blog.