Reducing burden for social housing teams
How we're working with local and central government to help frontline teams submit better data about social housing.
Recently, I’ve been working with a brilliant team of Made Tech people and Civil Servants on a project for the Department for Levelling Up, Housing and Communities. We’re easing the burden on the data providers who have to report social housing data to central government.
The current service is one gigantic form. While it allows users to scan all questions and understand the entire ask in one fell swoop, it presents some problems:
The sheer number of questions means this is often overwhelming for people.
The form is highly challenging to navigate with assistive technology.
We always ask every question, but not all apply in every situation.
Validations can be complex, but there’s no way to tailor these to specific user input.
Our new design solves these problems by moving to a step-by-step model of asking questions. Using the task list pattern, we split the questions into logical sections. By following GDS guidelines of asking “one thing per page,” each question is straightforward to reason about in isolation.
We tested our new design to understand how it felt to users. Would clicking “save and continue” between questions add to their perception of the burden?
The feedback has been overwhelmingly positive. We observed users quickly focusing on what they’re being asked, in sharp contrast to the current form. Even when people expressed concern, their completion time was often as quick as those who loved the design.
Doing the hard work to make life easier for our users
We carefully consider each design change and validate them by testing our prototype with real users. Here are a couple of things we’ve tried recently that we designed to make life easier for data providers.
Set up your log
An excellent example of where we’ve gone the extra mile to make life easy for users is in a new section called “Set up your log”. In this section, we ask some general questions about the let or sale so that later on, we can only ask questions that relate to the specific situation.
We’d made certain assumptions when designing “Set up your log” that we later tested with users:
Users would understand that they were locking in their answers
Users wouldn’t need to change their answers later on
What we found
Kimberley Frame, one of our fantastic user researchers, writes:
Our hypothesis was proved as users were able to make a change to the ‘tenant code’ when tasked to do so during the testing. However, some users were unable to locate the tenant code from the task list page, expecting to find it in the ‘tenancy information’ section rather than the ‘about this log’ section. Therefore, we plan to conduct research work around the naming conventions of the sections.
Users’ mental models
When completing a log, we observed users not fully understanding where they were in the overall information architecture. We hypothesised that if we introduce new breadcrumbs and new navigation buttons, users can navigate to different log sections.
What we found
Back to Kimberley again:
This hypothesis was proven when all users were able to navigate to different sections of the log using the breadcrumbs and/or navigation buttons. However, they all used different routes to do so when trying to get back to the task list in order to complete the finance section. None of these routes was incorrect, but it means that the current navigation is not straightforward to users.
Consequently, we are going to reinstate the current section as the heading, a backlink on all question pages and only use breadcrumbs on the ‘check your answers’ page. Testing of the new buttons on the ‘check your answers’ page (‘save and return to log’, ‘save and go to next incomplete section’) was also successful with the majority of users favouring to use ‘save and go to next incomplete section’ to complete the sections of the log in order.
Keep on learnin’
We’re keeping a design history for our service to track what we’ve changed and, more importantly, why we’ve changed them. As we continue in our mission to reduce the burden for data providers, we’ll keep updating this blog.
Cover photo by Benjamin Elliott on Unsplash