Planning data

Jamming together

Steve Messer — 2024-05-17

For the last five days, we’ve been looking at how we can make it easier for local planning authorities (LPAs) to provide data to our specifications. Instead of doing that in a standard delivery cycle, the team assembled in London for a design sprint.

A design sprint is a five-day process for building out and testing ideas to solve problems for our users. It’s close, collaborative work. Focused time away from the usual routine, away from Teams meetings and Slack, allowing us to go deeper, together. It’s a bit like being in a band: we get to jam together.

Understanding the problems

It all started on Monday. We got together to talk about the challenge, and we mapped out how people working at LPAs provide data currently – including all the invisible parts of the process. As we learned from an anthropology study done by Projects by IF, there’s several people working at LPAs involved in the process:

  • people leading the way in improving planning or digital ways of working
  • people driving project delivery
  • people on the ground within planning, and
  • people managing geospatial data.

We talked about the barriers they face providing data, related to tech, the data itself, how different organisations are set up and contextual factors that impact the organisations. We also called out some problems that users have mentioned to us or that we’ve experienced over the last twelve months operating the platform.

Identifying opportunities

Standing back, looking at all those together, we reframed the problems as opportunities for making things better. There were three main clusters.

One cluster focused on how we might make the journey of providing data more complete, an ‘end-to-end service’. That means meeting users where they are with contextual guidance, and breaking the process down into chunks that can be completed in an agile, iterative way. We also highlighted being better at communicating progress or specific processes to users.

Another cluster looked at giving users the tools to maintain their data and provide more over time, making the provision of trustworthy data a sustained, easy-to-repeat behaviour in LPAs.

A final cluster was focused around communicating the value of providing open data, helping users understand the benefits they’re helping to realise.

Exploring solutions

That gave us all the material we needed to sketch, map, design, iterate, and prototype a more complete end-to-end journey. Over the next two days we scribbled on whiteboards, used stacks of Post-it notes, drew scrappy diagrams and used GOV.‌UK Prototype Kit to turn it all into tangible things we could test with users. Because that was the main goal of the week: going from insight to idea to action as quickly as possible. Alpha is discovery.

On Thursday and Friday, we were joined by people from four LPAs to help us put our ideas to the test. We set the scenario and they navigated through our prototype, using it as if it was a real service. We collected tons of feedback on what worked well, what didn’t work well, and picked up other insights about our users’ day-to-day tasks and tools.

A simple flow diagram showing the main steps in checking and providing data. Image courtesy of Alex Torrance.

What we learned

We’ve got more analysis and synthesis to do early next week, but so far we’ve learned that:

  • users need to see the tasks involved with providing data, upfront, and get feedback on their progress
  • users need to know whether they’ve provided data successfully or if they’ve got issues to address
  • users find it helpful to map data headings to our specifications using examples (but we need to test this with their data)
  • after checking their data against our specifications, they need to provide conforming data straight away so that they can get on with their jobs, and
  • we can be better at explaining how the platform works, so that it’s clear where the data lives.

We learned that some instances of an idea didn’t work, and we needed explore variants of the solution. But that’s OK, we started small and can iterate.

Jamming together

We learned a few other things, mostly about each other.

As a team, we’re pretty spread out, working from villages, towns and cities across the country. (One of us even lives in a van.) But this week we got a chance to work together closely, to speak to each other face-to-face, and to get to know each other. We got a chance to hang out, to socialise. We got the chance to find a delightfully old-school pub in Fitzrovia and a place to eat pizza in the sun. And it helped our newly recruited service designer get to grips with the service, understanding the ins and outs.

What’s next?

As mentioned, we need to do some more analysis and synthesis on the findings first, turning those into insights we can act on. After that, we’ll be deciding which things we can build and release, and which need a bit more design iteration. But we’ve a strong bias to action, testing throwaway prototypes, so we’ll no doubt be talking to lots of people working at LPAs over the next few weeks.

Looking forward to it!

Credits: Owen Eveleigh (Tech Lead), Alex Torrance (Design Lead), Gwen Henderson (Content Lead), Jimmy Tidey (User Researcher), George Goodall (Developer), Paris Dharam-Peat (Service Designer), Michael-Jordan Faucher-Folie (Business Analyst), Darren Matthews (Delivery Manager).