Designing a Planning System for local councils across England

Problem space

To build or renovate homes, local council planning officers process applications from home owners. However, current back-office planning systems slow planning teams down because:

the information for each planning application is hard to find
the planning officers use multiple applications to manage applications
they cannot access application data off-site, or on another device
legacy systems cannot be integrated with newer digital systems
each council has individual processes, systems and needs which has staggered waterfall projects previously

Opportunities

The Local Digital Fund was created by the Ministry of Housing, Communities and Local Government (MHCLG) to empower and support local councils to join together in solving common problems. Southwark Council applied for this funding to work on creating a new Back-office Planning System from Discovery to Beta.

Outcomes

In 2020, I joined this team during the Beta phase. Within 16 weeks we:

Delivered a minimal viable product (MVP) for Permitted Development and an API to publish data publicly
Created an initial prototype for Full Householder applications
Ensured the design and infrastructure could be scaled to larger planning application

My role

As the product designer, I was responsible for:

Prototyping
Co-moderating user research sessions
Co-synthesising and creating actions from research
Translating design into development tasks
Ensuring that the designs satisfy user needs (desirability) and map to the data available (feasibility)

The prototype

This prototype was created using the GOV.UK prototype kit. Because the prototype kit was made for public facing, transactional services, I had to adapt the patterns to fit our users needs. Within this blog post, I shared some of my findings: Challenges and opportunities: Using the GOV.UK Prototype Kit for Back Office systems

To access these prototypes:
Username: unboxed
Password: magic

Iterative process

In 16 weeks, we facilitated 39 remote user research sessions with 10 local councils to ensure that the product met user and legislative needs.

Design and research was roughly organised over 2 week sprints:

Week 1: User research with Planning Officers, Prototyping for Planning Managers
Week 2: User research with Planning Managers, Prototyping for Planning Officers

This enabled better management of user insights and versioning of the prototype.

Here is the most iterated page, where I had to balance user needs and the data available from the public-facing tool:

Version 02

From testing we learnt that:

The alert box before the questions was to notify the planning officer that the applicant's answers ensured it was valid. However, users thought it was generated from the planning officer's actions
Referencing policy would be helpful for junior planning officers

Version 03

From testing we learnt that:

The process had too many steps
Automating the recommendation based on the officer’s responses is possible
Some participants felt a lack of closure even when their tasks were complete

Based on this feedback, we added an automated decision notice in version 4.

Version 04

Although this iteration tested well, we found out what data we would be getting from the applicant validation system.

Therefore, we had to adjust our questions and answers according to this data.

Balancing user needs and data feasibility was essential in building a data driven project.

Version 06

From testing we learnt:

The question order, which is dependent on the public-facing system, is not a logical order for the planning officer.
Presenting the requirements in plain English makes it easier to assess the proposal
Officers wanted to know which policies related to which question

‍

Version 07

From testing we learnt:

There was concern that the decision notice may need to have other policies recorded that are not automated
Sometimes an applicant may apply for the front extension, and therefore need other policies accounted for

Therefore, officers need to be able to identify any policy; not just those identified from the public facing service.

This idea tested well, but could not be built until the API receiving applicant data was built.

Version 09

I simplified the officers recommendation screen so that:

When applications are refused there is a text box for officers to enter the policies. These will be published on the decision notice
Independent of whether an application is refused or granted, some officers also want to provide information to their manager, like dimensions. They can enter this in the box that will not appear on the decision notice.

Collaborating with developers

When joining Unboxed, one of my tasks was to improve the process and transition between design and development. In response, I adapted processes and activities dependent on development needs. I trialed the following activities:

Using the GOV-UK prototype kit for creating two prototypes - one for developers (skeleton journey) and one for testing new concepts (to prioritise features for MVP)
Leading design-research debriefs
Pair writing on user stories
Creating stories alone, and asking for feedback before sprint planning
Developers attending user research sessions and writing notes
Creating a user flows on Miro to communicate the design in another way

1. Two prototypes

In the beginning of the project, the incoming data was unknown and we were defining the features and user flow for the minimal viable product (MVP). Therefore, the developers needed to focus on creating a skeleton journey with basic logic. The prototype I was creating was too advanced and confusing to map to tickets, therefore I created a second prototype for their work to follow until the design was validated.

Prototype for testing

Prototype for developer

2. Design debriefs

Before each sprint ended, I would take the multidisciplinary team through the user research findings and prototype tested. The miro board had the prototype screens tested and digital sticky notes with user insights, quotes, and actions going forward. The actions would be tagged if there was a technical question that needed to be answered. This would enable transparency across the team and enable developers to flag any technical concerns about upcoming work.

Prototype images showing user flow. Below are sticky notes from testing sessions

3. User stories

Creating user story tickets enabled a common ground for turning a design into a development task. By writing all the specifications under a standardised template and co-writing them with developers, the right level of detail was achieved. Writing these together prior to planning also helped understand which stories needed to be prioritised and how stories needed to be broken down and estimated.

Working in the open

At Unboxed Consulting and public sector projects generally, working in the open is an essential philosophy. We host Show and Tells to share the work, publish week notes, and write blogs to share project vision and help others facing similar challenges.

Show and Tell example:

Next steps

Once the applicant-facing site is ready and an API is built, we will integrate our MVP for Private Beta with select councils to trial
We will continue prototyping and testing for full-householder applications
We will scale the prototype for Minor, Full Householder applications
We will integrate a new activity into the sprint to help evaluate the prototype for simplicity prior to planning

Lessons learned

Adapting prototypes quickly depending on data available
Managing and designing for many various local concepts while designing a single service
How to create page templates on the GOV.UK prototype to increase iteration efficiency through using partials
Understanding needs of developers more

Impact

By making it easier for local councils to process planning applications, more homes will be built in the UK to respond to the housing crisis.

This is a cross-council project and therefore can have a wide impact across local councils. In Beta phase alone, 10 councils tested the product and are very enthusiastic to see a new product that can account for so many needs.