The problem
Our core mission as a service is to encourage and support Local Planning Authorities in providing trustworthy and high quality planning and housing data. If the data they provide doesn’t meet the requirements set out in the specifications, then the service provides feedback to them, highlighting data quality issues that they will need to address.
Feedback and insights from user research has highlighted that issue messages were not always clear to users and did not point them towards the action required to address data quality issues. We also know this from emails we receive and messages from LPAs in the #group-data-support Slack channel. For example the use of ‘{column_name} must have valid coordinates’ and ‘{column_name} must be above the minimum number needed’. In these instances, it is not clear what format of coordinates are required, or what the minimum number that can be provided is.
Our approach
In a workshop we mapped out where issue messages are seen by users in the service.
We then reviewed the content, and began recording issue types, severity of the issue message, the dataset it relates to along with which fields and datatypes it affects in a spreadsheet.
Severities are found in Datasette. ‘Errors’ are the most important ones for this piece of work, as they’re ‘external’ errors which means users must act on them to fix them.
This was with the aim of helping us to create new issue messages which are more descriptive of the action needed. To collate this information we used several tables which are held in Datasette. This work was complex and challenging to follow all of the relationships between the columns in a spreadsheet.
We moved our thinking and mapping from Google Sheets into a Mural board to allow us to connect datasets with data types more freely. We discussed that we wanted the issue messages to be more descriptive, however as some error messages can be related to datasets which may have slightly different requirements, we could not make them completely individualised due to how they are categorised in data management processes. We then collaborated with data management to pair write the new versions of the issue messages. These have now been transferred back into an amended spreadsheet for easier access when integrating into the service.
This process surfaced some other content inconsistencies within the guidance. These were recorded to be actioned as part of a wider guidance content review.
Our solution
Working with the data management team, we took each message and focused on how we could give the user more of a steer into how they should fix the issue. For example, “{column name} must have valid coordinates” does not give the user any indication of what we mean by valid coordinates. Instead, we can say, “{column name} must use the WGS84 or ETRS89 coordinate systems”.
We hope that the messages now include more information to users about how to fix their issues, and we will look to show them to users in upcoming research sessions.
Next steps
The wider team is meeting to discuss storage of new issue messages and how to integrate them into the service. We will also continue to conduct user testing across the service to ensure that the content resonates with users.
The wider user centred design team are also working on improving guidance across the service. The inconsistencies that surfaced will be shared in this process.