The problem
The planning data providers service was originally comprised of a single tool to allow LPAs to check the validity of their datasets. Once the data had been checked, the LPAs had to complete a series of manual steps to send their dataset to the data management team, who would then get the data onto the platform.
The tool was designed to provide feedback on the data shared by the LPA, enabling them to make required changes to conform to the data standard. But, the feedback tool was not fulfilling all the needs highlighted by users nor internal stakeholders. Some of these needs were:
- aligning the tool to review errors similarly to internal tools as this would cause users frustration when submitting inaccurate data
- visualising the data so users could visually review data and assess it
- growing the range of datasets the tool could review
- tracking which LPAs were reviewing their datasets
- transforming the standalone product into a service to better assist LPAs with their jobs-to-be-done.
We were stuck because we did not have a shared understanding regarding what our users needed, nor had access to the insights into the perspectives of senior management. This was due to the team working in unintentional silos and not sharing relevant information. We realised that if this continued, we risked iterating a tool that would not fulfil the needs of all our stakeholders.
Following on from the feedback tool workshop we decided a design sprint would be a good way to create team consensous around designing an end-to-end service.
Our approach
To help establish shared understanding, we hosted a 5-day design sprint workshop. This allowed us to:
- identify and review insights from user research
- ideate and formulate ideas to address pain points
- rapidly build a prototype to simulate a new journey of the service
Read the blog post about our 5-day design sprint.
The agreed outcomes of the 5-day design sprint were to:
- empower LPAs to confidently identify and understand the specific datasets they need to contribute, aligned with clear data specifications
- provide LPAs with clear, step-by-step guidance and support for gathering, cleaning and transforming, publishing and providing their data, so that it meets the standards
- streamline data checks, to ensure it’s fit for purpose before publishing
- help LPAs understand how to go about publishing their data, and then enabling them to supply us with the endpoint where the platform and data consumers can access their data
- enable them to understand when there are issues with their data, and to understand how to fix them
The design sprint helped us to reach these outcomes. Take a look at the slide deck we used to kick off the design sprint.
Day 1 - create shared understanding
The first day of the 5-day sprint was focused on creating shared understanding. We brought together individuals who had an in-depth experience of the service, individuals who understood the research conducted to-date, and reviewed a series of artifacts to identify key insights to take forward.
Day 2 - solving the problem
For the second day of the sprint, we decided to turn our collective knowledge into ideas to help resolve known problems users experienced.
We engaged in a structured process, first designing paper prototypes to help structure and document our vague and rough ideas for refinement. We then began incrementally increasing the fidelity of the prototypes, until we agreed and designed an interaction design of the new journey flow.
Day 3 - building the solution
Working alongside our engineers and interaction designer, we dedicated day 3 of the sprint to developing a working prototype, ready for user research.
Day 4 - showing the solution
We used day 4 of our 5-day sprint to engage with 4 LPAs, validate assumptions and test our new prototype with the users. This enabled us to ensure the solution being developed was on the right track.
Day 5 - what did we learn?
The final day of the sprint was used to unpack the learnings we gained during the duration of the sprint. This helped us to validate what we learnt while also identifying future focus areas to implement the changes to the service journey.
Our solution
Links to the solutions from our MVP work can be found in Heroku and Mural:
We store links to iterations of the service on our Heroku application.
We have also collated ideas and insights on a dedicated Mural page.