Introducing a Design System at the Planning Inspectorate

At the Planning Inspectorate (PINS), we design services to meet a wide range of user needs. To help ensure services provide a consistent, user-centred experience and improve collaboration across teams, we've been developing a shared design system.

In this post, Claire McShane, who is deployed as an Interaction Designer at PINS, shares how it started and what we’ve learned so far.

It started in our community of practice

We run a weekly Interaction Design Community of Practice, which brings together designers from multiple services. These sessions are a valuable space for design critiques, where we review each other’s work, share progress and ask for advice.

As designers on public sector services, we constantly refer to the GOV.UK Design System. It provides a solid and trusted foundation, but it does not cover all areas, meaning teams often design new approaches and patterns to meet specific needs.

Over time, a theme began to emerge during our community meet-ups.

Designers would share parts of their work with the group, for example a filter panel, a grid reference input pattern or a multi-file upload flow, and someone else would say:

“We designed something really similar in our service.”

We realised we were solving the same problems multiple times. We needed a dedicated space to document, discuss, and agree on patterns for reuse across the organisation to address common user needs.

Turning an idea into a plan

I took the idea to our Interaction Design Lead: what if we created a shared design system space specifically for PINS patterns? 

Not to replace the GOV.UK Design System, but to extend it where necessary.

We began by talking to the wider design community to understand appetite and need. From there, we audited existing designs across services to see what had already been created. This was as much about discovery as it was about consolidation - surfacing strong work that others hadn’t seen.

A workshop brought everything together. Designers brainstormed the patterns they most wanted guidance on and raised broader considerations including accessibility, research gaps and maintenance. We then prioritised collectively, choosing one area to focus on first so we could test our approach before scaling it.

The highest-voted areas included:

• filters

• service headers and footers

• the redaction tool

• multi-file upload

Filters came out on top, so that’s where we began.

Starting small and learning fast

Our first focus area gave us a practical way to test the model. We gathered filter examples from across PINS services as well as other government services. We reviewed them side by side to explore what worked well, where usability could be improved, and how accessible each approach was.

The audit was revealing. Small interaction decisions had significant impacts on clarity and ease of use. By analysing existing solutions rather than starting from scratch, we were able to build on real service experience rather than theoretical best practice.

Workshop outputs and initial design audit captured in Mural

We documented our discussions collaboratively and worked towards a proposed pattern, making it clear that it would need further testing and iteration. The design system isn’t about declaring something “finished”. It’s about creating a shared starting point and improving it over time through user research.

Choosing a home for the design system

Rather than investing time in procuring or building something new, we repurposed an existing internal “design patterns” prototype, giving us a ready-made foundation to build from.

We refreshed the branding, restructured the content and began adding guidance for our agreed patterns. Starting with something tangible helped build momentum quickly and signalled that this was a live, evolving resource and not just an idea.

Homepage of the PINS Design System

Writing design guidance

Our design pattern documentation approach mirrors the clarity and practicality of the GOV.UK Design System. Each pattern includes guidance on when to use it, when not to use it, and what teams should consider before implementing it.

We provide Nunjucks code examples alongside links to live service implementations. 

Example Nunjucks code for the redaction tool pattern

Where available, we also link to existing user research that has informed the pattern, helping teams understand the evidence behind the design decisions. Accessibility considerations are always included from keyboard interaction to screen reader behaviour and known risks. Accessibility isn’t treated as an add-on; it’s integral to every pattern decision.

The aim is not just visual consistency, but shared understanding of what the component offers and how it addresses users’ needs.

Shared ownership, not central control

We’re now at a stage where responsibility is distributed across the design community. Designers choose a component or pattern they’re interested in and lead its development, while our weekly Community of Practice workshops provide space to review, critique, and align in direction. 

This model reinforces that the design system belongs to everyone. It also keeps the work grounded in real service needs, because each pattern is led by someone actively designing in that space.

As the system matures, we’re keen to involve our content design community to align shared terminology, tone and microcopy patterns across the department. Beyond design, the space has now also been used by PINS product managers to ensure consistency across features. We also want to extend usage of this more widely so that developers and operational colleagues can understand the patterns we're using and contribute to their evolution.

In the future, we’d also like to share our patterns and learning with the wider cross-government design community, helping others facing similar challenges and learning from their approaches in return.

Where AI fits in

As we build out the design system, we’re also thinking about how emerging AI tools can support the process.

AI has already proved useful in summarising workshop outputs into draft guidance and helping refine content for clarity and plain English. It can accelerate early prototyping by generating example code, and it can help us sense-check documentation for consistency.

It won’t replace research, accessibility testing, or collaborative decision-making, but it can lighten the load of maintaining documentation, freeing designers to focus on solving problems and validating solutions.

What we’ve learned so far

Starting a design system doesn’t begin with components. It begins with conversations.

Our Community of Practice made duplication visible. The workshops built shared ownership. The audits surfaced insight we didn’t know we had.

Most importantly, we’ve shifted from:

“How did your service solve this?”

to

“What should the PINS pattern be?”

We’re still early in the journey. Patterns need testing. Guidance will evolve. New needs will emerge. But we now have a shared space to make those decisions together.

Ultimately, a shared design system means people using Planning Inspectorate services - whether submitting an appeal, participating in an examination, or accessing a decision - experience services that are clearer, more consistent, and easier to use.

Contact information

If you have any questions about our user-centred design services, or you want to find out more about other services we provide at Solirius Reply, please get in touch (opens in a new tab).