Building a community around DWP's design system.

DWP had grown significantly, with designers, researchers, content specialists and engineers working across a large number of services and locations.

Teams had created and shared patterns for several years, but the work was distributed across different platforms. Designers were often unsure which guidance already existed, which patterns they could trust or how they should contribute improvements.

The design system needed to make it easier for teams to find, use and share the patterns required to build consistent and accessible services.

But the challenge was larger than creating a library of reusable components.

It needed a clear purpose, a useful contribution model and an active community around it.

I joined as the team's first interaction designer and began by reviewing its purpose, priorities and relationship with the wider DWP community.

The existing backlog contained duplicated requests, assumptions and ideas supported by very different levels of evidence. Before increasing delivery, the team needed a clearer understanding of its users, their needs and what success should look like.

I facilitated a collaborative discovery session that brought the backlog, user needs and future opportunities together in one place.

We grouped related work and distinguished between:

• Needs supported by research or existing feedback.
• Requests raised through community discussion and GitHub issues.
• Patterns that could be released experimentally.
• Items requiring further user research.
• Technical improvements that could reduce debt and improve the website.

After prioritising the work together, I introduced a now, next and later structure. This gave the team a more manageable plan and a clearer way to explain decisions to the wider organisation.

A design system cannot be sustained by a central team working alone.

I presented the team's purpose, current work and future priorities to an internal community of around 100 people. Rather than presenting a finished solution, I was open about the challenges the team faced and where we needed help.

The central message was that the design system did not belong to the design-system team.

Our role was to bring the pieces together, provide structure and help the wider community improve the patterns used across DWP services.

That transparency prompted questions, ideas and direct conversations from teams across the organisation. It also gave the community clearer evidence that their feedback could influence priorities and contribute to the system's direction.

The existing contribution model was not generating enough meaningful participation.

Rather than assuming that people were unwilling to contribute, I began exploring whether the process itself was asking too much, happening too late or failing to show people the value of getting involved.

I introduced and trialled several lower-friction ways for teams to engage:

• Office hours for sharing progress and explaining recent decisions.
• Power hours where teams could bring patterns and problems for open discussion.
• Brown-bag sessions for deeper, optional exploration of individual patterns.
• Community surveys to understand adoption, usability and unmet needs.
• Cross-team workshops connecting services, disciplines and locations.

This repositioned contribution as an ongoing collaboration rather than a formal handover into a central team.

It also helped the team understand that increasing adoption depended on education, engagement and trust as much as documentation or code.