We previously blogged about how and why DLUHC is looking at reducing the burden of data submission to central government through user- centred design and automation. This post is about how we’re designing and building the new “Submit social housing lettings and sales data (CORE)” service.
The new service will allow users -- in this case housing officers and their managers in Local Authorities and Housing Associations – to share data on new social housing lettings and sales by:
logging individual instances of lettings and sales by answering questions uploading data about multiple sales and lettings using a CSV template transferring data via APIThe information shared by these organisations makes up a set of National Statistics, which need to meet a high standard of trustworthiness, quality and value.
For now, we’re working on the first submission method. We have an early draft of the API specification and we’re getting to the bulk upload next, but we needed to prioritise the user needs of less digitally mature organisations to ensure we’re delivering a data submission service that everyone can use.
Design challenges with a professional use service
From a design perspective, this service presents some unique challenges because unlike mainstream citizen- facing services that are used once and provide something in return (for example, your new passport or driving licence), users of this service are professional daily or weekly users and their need to is simply to get their job done.
But that doesn’t mean design needs to take a back seat! To help users do their jobs quicker and better , we’ve been experimenting with GOV.UK’s Task List pattern and the one-thing-per-page design principle, to replace the long online “form” with all the questions on one page.
This was risky because there are a lot of questions for the user to complete, so splitting the questions into one-thing-per-page could increase the time it takes to submit the data. Also, with the previous design, users liked scanning the questions quickly and knowing what questions are coming. However, user testing of the new design has found that users feel more confident in using the service and in the data they’re submitting.
Users said they were less likely to make errors which means their organisation is less likely to receive DLUHC queries about the data submission later in the year. They also just found the new design simpler and more pleasant to use.
We will be doing more scaled testing further down the line to assess the actual impact of the new service on data quality. But our priority right now is to deliver a service that’s more usable and accessible for all, on all devices, and can be improved more easily to meet data providers’ and DLUHC analyst’s’ evolving needs.
We’re also addressing the sheer volume of questions through smarter routing in the service, and inferring answers wherever possible, so that we can ultimately reduce the burden of the data submission. You can read much more about our design decisions and user testing in our design blog.
What’s in a service name?
We couldn’t get rid of the rather meaningless “CORE” acronym entirely because it’s become a bit of a brand in the social housing industry. Existing users told us they’d still call the service and the activity “CORE”, but we know new users don’t understand the acronym. Also, good service names are verbs, not nouns. So we’ve named the new service “Submit social housing lettings and sales data (CORE)”. This is according to what users expect to do, and for now, ‘CORE’ is staying in brackets!
A more automated way to build forms
From a tech perspective, we’ve moved from document / paper-form based data collections to being (JSON) schema-led. This means the online log submission user interface is now auto-generated. Other formats, such as a printable form, a bulk upload template and the API spec could be auto-generated in future, rather than manually built from a legacy paper form. The aspiration is for a much more efficient and flexible way to build and maintain a data collection service.
We've used DfE's frontend libraries including its form- building components as our source code and built a more bespoke form builder / runner on top. We've also worked with DfE to improve things for anyone else wanting to use the code. All the code is open source on GitHub.
Help us test the service!
The service passed an Alpha digital service assessment in September 2021 and is now in the Beta build phase. Our multi-disciplinary team of digital and stats people is now keen to hear from Local Authorities and Housing Associations who want to get early access to it during our Private Beta phase.
This is where some users start using the service for real, to help us test the service and build enough confidence to release it to all users in a Public Beta. If you’re interested in participating in the Private Beta phase, complete this quick survey and one of our user researchers will get back to you.
As a department that is typically more focussed on policy than transactional services for external users, it’s been a long journey to get here. We’re still learning and we’d love to continue exchanging ideas with other digital and data teams inside and outside of government on the topic of data acquisition and ingestion and digital services in general, to make things better for all users.