BOPS Design History and Pattern Library

We’ve spent more than 5 years working with councils across England to develop the Back-Office Planning system. We took a collaborative approach, coaching planning teams to participate in the design process.

We had a unique opportunity to use a design-led, agile approach to transforming public services at scale. We've learnt a lot along the way and have curated this design history to support other teams working on back office systems in government.

Who is this for?

These resources may be of interest to:

  • product, service or UX designers working in planning or related services in local or central government

  • anyone adapting the GOV.UK Design System for back office systems

  • anyone involved in developing new products and services in UK planning

  • teams or companies that would like to use the BOPS open source code to develop their own services

The BOPS Pattern Library

This library is a public collection of reusable service patterns and components. We created these by documenting the design and build of the Back Office Planning System (BOPS).

The aim of this library is to help teams design and build their own back-office products, both inside and outside of government. By providing evidence-backed patterns and components, we can help other teams create a consistent and accessible user experience. We hope this will also increase the efficiency of developing and iterating on BOPS and other digital services. We welcome contributions from the wider design community and add these patterns to existing design libraries.

What is a service pattern?

Reusable, end-to-end user journeys or major interactions that guide users through completing a significant task or goal. They define the structure, flow, and key touchpoints required to achieve a specific service outcome, often integrating multiple design patterns and components.

We’ve worked with planners to create patterns that fit their workflows, reduce mistakes and offer a consistent, familiar experience.

Reviewing applications

The review process is a common task across many back-office teams. It's often the final step in a case management journey before a case is finalised or closed. Because it's a shared process, we believe this pattern could be widely useful for other services.

Review and approve a case service pattern

Showing key case information

When officers are managing multiple cases as part of their daily workflow, ‘sticky’ components give officers access to key reference information whenever they need it.

Showing key case information pattern

Sidebar navigation

In back-office systems, users often navigate between many tasks in a non-linear workflow. We developed the sidebar navigation pattern to make it easier for officers to move between tasks in the way that made sense to them.

Sidebar navigation service pattern

Saving pattern

Case officers often need to step away from an assessment to check a policy, wait for a site visit, or respond to an urgent query. The Saving Pattern ensures the interface remains a ‘source of truth’ throughout these pauses.

Saving pattern

Checking information with applicants

When case officers need to ask for information from applicants, this pattern helps speed up the process by keeping requests inside the system.

Checking information with applicant

Multiple questions at once

Expert users who complete familiar, frequent and repeated tasks can cope with high-density pages with multiple questions in one task. This builds on the GOV.UK ‘one thing per page’ pattern.

Multiple things at once pattern

Design principles

Design the service, not just the software

Back office systems are rarely used in isolation. Particularly in public services, they'll be used within a much wider ecosystem of technology, services and people. This ecosystem probably doesn't work perfectly, but it does work. It's important to keep zooming out to understand the big picture and the constraints that users are working within and the connections that keep things moving, so that you can design a service that fits within the wider context.

Create reusable patterns and resist unnecessary variation

One of the biggest challenges in delivering back office systems at scale is balancing standardisation with flexibility. We want to allow customisation for local needs, without losing our vision for a unified approach and reliable software. We always look for patterns and prioritise reuse over creating something new. It’s vital that designers and developers work closely to think about reliability and maintenance as well functionality of new features.

Nurture your believers

For transformation at scale, we need to nurture people who are willing to both participate in the design process and act as advocates for our approach. This helps us build a coalition of expert users with the confidence to challenge their accepted workflows and give their peers the support they need to do the same. We do this through frequent, multi-disciplinary collaboration, offering a variety of ways for people to participate. Seeing the impact of their participation creates a snowball effect, where advocates recruit the next round of participants, who then become advocates themselves.

Start from the end

When building a large scale back office system, it's tempting to start with a few features as a Minimum Viable Product. But in complex services, viability must be linked to service strategy. Councils don't buy a bit of a service (at least, not easily). We need to start with the wider outcomes - like adoption, procurement and the ability to integrate with other products - then work backwards. This means we need to understand needs around adoption and procurement as well at the product level.

Establish trusted, safe spaces for consensus building

Working across hundreds of providers brings many different opinions and entrenched ways of working. We need to allow a community of peers to come together and take ownership of design decisions. We create familiar, frequent and open spaces for people to give feedback, share different perspectives and learn from people they trust. This often leads to new connections that spark peer-to-peer activity beyond our involvement.

Design tools and artefacts

A Miro board showing the title 'Drop in session 21/01/26' . Next to this are some examples of mobile designs for BOPS. Sticky notes sit around these images, showing comments on the designs.

Sketching

Regular, collaborative sketching sessions to brainstorm and refine features with planning teams. We used methods like Crazy 8s to help planners think beyond the limits of their current systems and processes.

Over time, many planning officers become more confident in these methods and helped us explore solutions in other services, like Planning Performance Agreements and Building Control.

Design and research drop in session

Biweekly, remote sessions with officers across planning, validation, digital and business support teams across several local authorities. This was a collaborative space where we’d share designs or feature concepts, get feedback and invite challenge. We’d include developers in these conversations too, so that our services got a better understanding of the technical challenges and opportunities around each feature.

Prototyping tools

Building on our sketches, we used a shared space in Figma to build up prototypes of features and user journeys. These were particularly useful for working with developers to explore ideas from both design and technical perspectives.

Later in the project, we used tools like Google AI Studio for experimentation.

User research and insights

We carried out multiple rounds of user research and useability testing throughout BOPS product development'. We shared insights through regular Show and Tells and playback sessions. We’ve shared some of these insights here. If there’s anything you’d like to know more about, get in touch or you can view more research here.

Note: some of these files may have lost some of their original formatting.

2024

Consultation is an essential part of the planning process. It includes consultation with the public, statutory consultees and other experts who can give critical insight into a proposed development. It also includes publicity, such as displaying a public site notice and sharing details of planning application in local press.


2023

We wanted to create a better service for enforcing planning decisions. Through collaborative research, sketching and story mapping, we developed a basic enforcement service as a prototype. This report shares some of the research that led to the prototype.


2023

BOPS includes a public interface where neighbours can view details of a planning application and submit comments online. Their comments are immediately available to the case officer. This report shares insights from testing this service with residents in Barnet.


Learning from an 8 weeks Alpha phase where we developed, tested and iterated our prototype back office planning system with multiple local authorities. We also carried out wider technical investigation into the planning ecosystem and started to develop the business case for a better service. Funded through the MHCLG Local Digital Fund.

Insights and recommendations based on testing the first iteration of the BOPS MVP (minimum viable product). This include a service for managing Permitted Development (PD). Funded through the MHCLG Local Digital Fund.


2019

The full presentation of research and insights that led to the development of BOPS, led by Southwark Council and partner councils. Funded through the Ministry of Housing, Communities and Local Government (MHCLG) Local Digital Fund.

2020

2020


Acknowledgements

Over 5 years, we worked with planners, digital teams, validation officers, business support teams, procurement leads, system specialists and many, many others across multiple Local Planning Authorities and local government and UK digital planning, to research, design and develop BOPS. We’d like to acknowledge their role as experts, codesigners and, in several cases, Product Owners.

We couldn’t have done it without you.

Abimbola Lasisi, Southwark, Aimee Gregory, Gateshead, Amy Ly, Camden, Andrew Fulford, Birmingham, Andrew Holmes, Gateshead, Anthony Stephenson, Salford, Ben Higgs, Gloucester, Catherine Neal, Lambeth, Dan Clark, Newcastle, Daniel Foster, Medway, Dave Chamberlain, Barnet, David Forster, Doncaster, David Allen, Salford, Denisse Patten, Barnet, Duncan Miller, Newcastle, Ed Arnold, Buckinghamshire, Emily Hadley, Buckinghamshire / MHCLG, Eva Quille, Barnet, Ewan Lawless, Southwark, Freya Cunningham, formerly Southwark, Greg Woodford, Lambeth, Harvey Robson, Gateshead, Jack Ricketts, formerly Southwark, Jacky Olsen, Medway, James Sewell, Newcastle, Janine Arnold, Dacorum, Jenna Rumley, Doncaster, Joann Meneaud, Gloucester, Jonathan McClue, Camden, Jonathon Simon, Tewkesbury, Jordan Lister, Lambeth, Karen Lucas, South Gloucestershire, Kevin Buckthiorpe, Barnet, Lisa Maryott, Medway, Lisa Rowntree, Gateshead, Mailili Rex, Newcastle, Matt Wood-Hill, MHCLG, Maya Szybicka, Buckinghamshire, Nigel Brown, Newcastle, Nikitha Felix, South Gloucestershire, Nora-Andreea Constantinescu, Camden, Paul Downey, MHCLG, Pete Egan, Gloucester, Pete Forest, Southwark, Phil Rumens, GDS Local, Rebecca Balfour, Southglos, Rich Limbrick, Camden, Rish Mehan, Barnet, Rob East, Lambeth, Samantha Mason, Salford, Samantha Wightman, Newcastle, Samantha Ingram, Southwark, Tom Buttrick, Southwark, Stacy Pring, Medway, Stephen Barnes, previously Lambeth, Will Callaghan, LocalGov Drupal