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

UK GovCamp took place on Saturday 18 Jan 2025. GovCamp is an unconference for people interested in making services better in the public sector. It was my fourth UK GovCamp, and my third as an organiser.

This GovCamp took a special significance for me as my friend, colleague and frequent collaborator Vicky Teinaki had passed away a week or so before the event. This really affected the way I approached the event, and also the way I participated in the day.

As a community professional in my day job, I felt I had to help mark her passing and honour her memory. As part of the GovCamp organisers, I was also well-placed to be able to adjust the schedule and say a few words. Whilst this was not the way I expected to let Vicky’s passing sink in, writing a few words actually helped me process my feelings and address the loss of a significant figure in our community.

During the opening ceremony, I gave a short memorial speech in her honour. To give others a chance to commemorate her too, a few colleagues set up a memorial wall where people could add their tribute messages and funny stories. I also pitched and ran a session to design a memorial sticker for Vicky. It felt fitting to base the session on the first blog post that I read of Vicky’s : ‘Metaphors we sticker by’. That blog post led to my first interaction with her, and as a result we became friends.

I think this GovCamp took a special significance for me because of Vicky’s passing. I’m normally really excited about the sessions and the discussions I get to have. This time around, I was just really grateful to see friends that I haven’t caught up with in a while. I did tell a few people that I wanted to speak to them during the day, but didn’t get round to it (I ended up being quite busy with the intro ceremony, sticker session and closing ceremony). I do intend to catch up with them all though. If there’s one thing Vicky’s passing has taught me, it’s to not delay catching up with friends, and to spend some time with them outside of work circumstances (if possible).

There are people that attend GovCamp every year and just do ‘Corridor Camp’ – i.e. have fruitful conversations with people outside the breakout sessions. I never fully appreciated the value of it until this year. GovCamp has always gathered people passionate about the public sector. People passionate enough to spend their Saturday talking about making things better for citizens. I always thought it was energising, but never fully appreciated it’s ability to convene so many like-minded, talented, driven people. I’ll be making more of that in coming years.

That being said, I did go into one session and talk a fair bit, and that was the ‘Creating teams that are more than the sum of their parts, including psychological safety’ discussion. Half of my role on the design system team is now essentially ‘team ops’, the other half is working outwards for the community. So it was really good to hear from people that are looking to maximise the talent of their team members and create an environment for them to thrive. The discussion made me reflect on my approach with my own team; especially the bit focussing on respecting an individual’s profession, whilst also permitting team members to go beyond their own role to deepen their understanding. I think there can be a fuzzy line on where one discipline starts and another ends on multi-disciplinary teams, and it was helpful to hear how other teams deal with that. There’s a few things I’m going to try out with my team, so keep an eye out for a blog post in the near future.

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.

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.

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.