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

Let’s set the scene. You started a new community; maybe it’s a forum, a community action group, or a local book club. At first, everything’s buzzing. People are joining, someone actually turns up to your first event, and you’re riding that early wave, convinced you’ve cracked the code on belonging and participation.

Fast forward a few months. The numbers have gone up, but so has the noise. More people, more ideas, more needs; brilliant! But also, more WhatsApp messages at 11pm about vegan snacks for the next meetup, more “just checking in” emails, and (my personal favourite) more people who seem to have merged into the background, like they’re part of the wallpaper.

Here’s the thing, with more people comes more places to hide. A bit like being at a family wedding; if there’s only six of you, you’ll be roped into clearing up the buffet. If there are sixty, you can safely disappear behind an aunt’s hat and hope no one notices you slinking off early.

Diffusion of Responsibility: The Invisible Handbrake

This is where psychology kicks in. The phenomenon at play here is called diffusion of responsibility. In the 1960’s social psychologists John Darley and Bibb Latané showed that the more people are present, the less likely any one person is to take action; because everyone assumes someone else will step up. This is the engine behind the bystander effect, which entered public consciousness after the tragic murder of Kitty Genovese in 1964. Kitty was attacked in a New York street; many witnesses saw or heard her suffering, but no one intervened or called for help. Each bystander assumed someone else would act, and so, heartbreakingly, no one did. It’s an extreme, but powerful, example of how diffusion of responsibility can disorientate a group, even in moments of crisis.

But this isn’t limited to emergencies. Diffusion of responsibility creeps into everyday group life: work projects, online forums, and yes, your growing community. It’s why that Google Doc sits unedited, or why the same handful of people always end up running the show.

Social Loafing: The Quiet Drift

Closely linked to diffusion of responsibility is social loafing, a term describing how people put in less effort when working in a group than when working alone. The classic Ringelmann tug-of-war experiment found that as more people joined a team, each person pulled less hard on the rope. Why? Because when responsibility is shared, individual accountability fades into the background. Social loafing is not just laziness, it’s a psychological side effect of group dynamics; especially when roles are unclear, contributions aren’t tracked, or people feel anonymous in a crowd.

Research by Karau and Williams shows that social loafing intensifies as group size increases and individual efforts become less visible or appreciated. The result? Lower productivity, reduced engagement, and a heavier burden on your most committed members. In online communities, this effect can be even more pronounced, as computer-mediated communication often reduces group cohesion and the social cues that keep us accountable.

The Cast of Characters in Every Community

Communities aren’t just a sea of identical faces. They’re made up of different types of members, each with their own rhythm of participation:

Core Team: The organisers, facilitators, and leaders. They steer the community’s direction, set the tone, and take responsibility for logistics, strategy, and culture.

Key Contributors: The folks who show up early, stay late, and bring snacks. They drive discussions, generate ideas, and inspire others. Not always in formal leadership, but always visible and reliable.

Active Participants: The regulars. They consistently attend meetings, join in discussions, and help sustain momentum. The backbone of participation, even if they’re not steering the ship.

Peripheral Participants: The “sometimes” crowd. They dip in and out, occasionally contribute, and might be testing the waters or juggling other commitments. Their engagement is sporadic, but always welcome.

Observers/Lurkers: The silent majority. They attend events or read discussions but rarely, if ever, contribute. You might not notice them, but they’re there—soaking up the community’s energy and learning quietly.

Diffusion of responsibility and social loafing are strongest among the peripheral participants and observers. The more people in the room, the easier it is to assume someone else will ask the awkward question or volunteer for the unglamorous task. The psychological effect is subtle but powerful: “Why me, when there are so many others?”

Communities are living things. People come and go. Your top contributor gets a new job, someone else has a baby, another just needs a break. That core team and those key contributors? You’ll need to keep topping them up, like the biscuit tin at a busy office.

What’s a Community Wrangler to Do?

You can’t eliminate diffusion of responsibility or social loafing, but you can design around them. Here’s what’s worked for me (and what I wish I’d done sooner):

1] Make the Unspoken, Spoken: Spell out roles. Don’t assume people know what’s needed—ask, invite, nudge. “Could you help with X?” works better than “Any volunteers?”

2] Set Expectations, Gently: Let people know it’s okay to dip in and out. Life happens. But also: here’s what helps the community thrive.

3] Shine a Light on Contributions: Celebrate the helpers, the question-askers, the “I’ll tidy up the Miro board” types. Recognition is rocket fuel.

4] Share Ownership, Not Just Tasks: Invite people to shape what the community is, not just what it does. Co-design, don’t just delegate.

5] Stay Human: Be kind about churn. People will leave and return. No hard feelings, just keep the door open.

6] Make It Easy to Step Up (or Back): Design for hop-on, hop-off participation. No guilt trips, just a gentle “we missed you” when someone returns.

The Takeaway

Scaling a community isn’t about keeping everyone equally busy, it’s about making it safe and easy for people to step forward, and just as safe to step back. Diffusion of responsibility and social loafing aren’t bugs, they’re features of groups. Your job? Notice them, name them, and keep inviting people to the table.

And if all else fails, never underestimate the power of a well-timed biscuit.

References:

Karau, S. J., & Williams, K. D. (1993). Social loafing: A meta-analytic review and theoretical integration. Journal of Personality and Social Psychology, 65(4), 681–706.

Latané, B., & Darley, J. M. (1968). Group inhibition of bystander intervention in emergencies. Journal of Personality and Social Psychology, 10(3), 215–221.

McKinlay, A., Procter, R., & Dunnet, A. (1999). An investigation of social loafing and social compensation in computer-supported cooperative work. In Proceedings of Group’99, the International Conference on Supporting Group Work , 249–257. Association for Computing Machinery.

Nonnecke, B., & Preece, J. (2000). Lurker demographics: Counting the silent. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 73–80.

Ringelmann, M. (1913). Research on animate sources of power: The work of man. Annales de l’Institut National Agronomique, 2e série, t. XII, 1–40.

N.B. Post edited (2.30pm, 21/05/2025) to highlight how some of the reporting was exaggerated. Hat tip to Clare McCarthy & Mia Allers for pointing this out.

The bystander effect has been strongly corroborated by many studies, some of which came about because of the Kitty Genovese case. You can read a brief literature review here: https://www.researchgate.net/publication/363028550_A_Literature_Review_of_Diffusion_of_Responsibility_Phenomenon

Liu, D., Liu, X., Wu, S. (2022) A Literature Review of Diffusion of Responsibility
Phenomenon, In Advances in Social Science, Education and Humanities Research, volume 664, 1807-1810

In October, I got to work with the fabulous DXW design team on re-vamping their community. It was energising to work with another community on a fresh set of challenges.

The ask

dxw are a design agency that deliver digital services for government, charities and public sector organisations. There has been a lot of change in the organisation over the past year or so, and the design leads wanted to spend more time focusing on the community. Music to my ears.

I went in to give a talk and run a workshop with the design team. The intention was for this to be a kick-off session for the community.

What went down

I delivered a bespoke talk about setting up a community and how the make-up of the community can affect organisational culture. This is a meaty topic, and I was glad to be able to share some pointers. I got to bring up a slide that I used for a lightning talk at SD in Gov a few years ago.

The overall message of the talk was to be very intentional with your community. Think about what you want to get out of it, and think about the steps you have to take to get there. I used case studies from my work on communities in education, government and charities to highlight each point.

I followed the talk with a workshop where I drew out what the designers want from their community (user needs), and the first steps to take after the workshop.

I wanted the workshop to be pacy and interactive, so there were lots of fun little activities. We did triz/ the anti-problem to talk about what a terrible community would look like. I also rolled out the agile ‘product box’ technique, to get people in the frame of designing their community in the same way they design services. It was a whistle stop tour of the technique, but it was really effective, and definitely something I’d like to experiment with further at a later date.

We worked towards the alpha prototype of the community and I left them with my community kick-off canvas as a next step. The design team had clear ideas on where they were headed as a community, so I’m very optimistic about their trajectory. I am now emotionally invested, and will inevitably pop my head in, in a few months to check on their progress.

Can you workshop culture?

Part of my talk covered aspects of culture, and how communities can go a long way in helping define an employee’s perspective of working culture. With DXW this is especially important, as you have people from the agency embedded in other organisations. With the limited time they spend together as DXW’s design team, the way the community ‘feels’ becomes very important.

You can’t transform an organisation’s culture in a 90 minute workshop, but you can be very intentional about the community’s aims, how you experience the community, and how it is run. A small aspect of how a community is structured can have a significant impact on wider organisational culture.

Gerry Johnson and Kevan Scholes’ (1992) Cultural Web model.

Looking at popular culture models, like Johnson and Scholes (1992) Cultural Web, you can see that it could affect several aspects of the cultural paradigm. For example, the organisational structure of a community can be top-down (the design lead is the community lead) or bottom-up (practitioners run the community and make decisions). These are the at opposite ends of the spectrum, and will affect the flow of power, become part of the organisational structure, and can reinforce/liberate from control systems. And that is just one aspect of how a community is structured.

“Communities don’t exist in vacuums.”

It is important to think about how your community will function within your organisation. And even more so, how leadership and daily practice can support your community in making cultural change. It looks like DXW are in good hands with their design leadership, I wait with bated breath to see where their community journey takes them.

Does your community have a brilliant culture? Let me know how you made that happen in the comments below.