Submit social housing lettings and sales data Beta Assessment

The report for the Submit social housing lettings and sales data beta assessment on the 27 July 2022

From:
Central Digital and Data Office
Published
10 August 2022
Assessment date:
27 July 2022
Result:
Met
Stage:
Beta

Service Standard assessment report

Submit social housing lettings and sales data

From: Central Digital & Data Office (CDDO)
Assessment date: 27/07/2022
Stage: Beta
Result: Met
Service provider: DLUHC

Previous assessment reports

Service description

The service allows staff at Local Authorities and Housing Associations to submit data about each new social housing letting or sale in England. The data is collected by DLUHC on an annual basis, is released as official national statistics on GOV.UK and informs social housing and homelessness policy. The service is designed to allow users to enter valid data first time. Around 300,000 new sales and lettings are logged each year, by around 900 organisations. The service replaces a legacy DLUHC system known as CORE (Continuous Recording of Social Housing Lettings and Sales)

Service users

External users

The Submit Social Housing Lettings and Sales service has around 1600 users from data providing organisations such as local authorities, housing associations and charities. They are made up of:

  • Housing and Lettings Officers – often on the front line, collecting information while signing up occupants into their new home. Their role in the service is Data provider
  • Housing and Lettings Managers – manage front line housing and lettings teams. These users tend to check the social housing data entered into the service is accurate and submitted to DLUHC on time. Their role in the service is a Data Coordinator.
  • Business analysts – often manage several software systems within the organisation and are responsible for managing the CORE user accounts, setting up schemes for organisations that manage supported housing allocations, and submitting data via bulk upload. Their role in the service is a Data Coordinator.

Internal users

Users of the service work within DLUHC or as partners of DLUHC:

  • Statisticians and analysts at DLUHC, who manage the data collection and analyse the data for releasing to policy people in the department and to the public.
  • Customer support – made up of civil servants and an external helpdesk who provide 1st and 2nd line support to data providing organisations. Their role in the service is Customer Support

1. Understand users and their needs

Decision

The service met point 1 of the Standard.

What the team has done well

The panel was impressed that:

  • the team demonstrated an excellent understanding of their users including their job roles and pain points. It was clear the whole team were involved in user research
  • the methods utilised in this phase were varied, appropriate and executed well to provide valid data
  • the team have a good understanding of what makes their users similar or different and this was reflected in great sampling
  • the team clearly demonstrated how their research had a positive impact on making the service better for users
  • the research plan for the next phase was clear and well thought out

What the team needs to explore

Before entering public beta the team must:

  • increase the amount of organisations, users and submissions in the private beta phase. The team have taken a methodological approach to onboarding, but this has resulted in very low numbers compared to the user population as a whole. More observations of people using the service in a real-world context are needed to be able to answer the question of whether this works for everyone
  • conduct contextual research with users, especially those involved in private beta. The panel appreciate the logistical challenges but design and development have entirely taken place during the pandemic and this is a risk. The team could consider some immersive research where they work from a housing office for a period of time and make the most of the opportunities to observe that occur

  • increase the work undertaken with the access needs of users. The team need to actively focus private beta recruitment to include these users. They must also implement findings from the upcoming research focus on accessibility

  • refine their user needs. Those presented were created, and it needs to be made clear that’s what they are. The team should also present the high level needs of the user in relation to the service
  • be clear whether their personas are personas or case studies. They were presented as personas but the narrative seemed more in line with a case study or pen picture. It was unclear whether they were representing the experiences of one user or a collective

2. Solve a whole problem for users

Decision

The service met point 2 of the Standard.

What the team has done well

The panel was impressed that:

  • the team has recruited a content designer
  • the team has undertaken an accessibility audit and published an accessibility statement
  • the team have a good understanding of the legal obligation for users to use the service, and are working hard to ensure the service is simple to use to help promote use
  • the team have a good understanding of the work practices of organising and the various systems they use to compile data

What the team needs to explore

Before moving into Public Beta, the team needs to:

  • consider alternative designs for the start of the user journey, to support the needs of each of the identified personas (data provider, data coordinator and customer support users)
  • be confident that all users of the service can find the service (based on their needs) independently. References were made that user testing has started from the start page and onboarding users have been walked through the service
  • meet level AA of the Web Content Accessibility Guidelines (WCAG 2.1). The accessibility statement highlights the service still has Level A issues which need to be fixed

Before their next assessment, the team needs to:

  • design, test and iterate content to support the service, including identifying needs around providing notification on any changes made by a user other than the data provider and others parts of potential unhappy paths for the users
  • continue to understand and respond to struggles around motivation in completing the service
  • continue to test and iterate all features with users with differing access needs, allowing enough time and capability to keep them accessible. This will be particularly important for features such as bulk upload, a feature that will be developed during Public Beta

3. Provide a joined-up experience across all channels

Decision

The service met point 3 of the Standard.

What the team has done well

The panel was impressed that:

  • the team has considered organisational needs around providing access to multiple data providers, and have been monitoring this in the private beta
  • the team are planning more testing with users with accessibility needs
  • the team have identified a need to provide guidance to support users understand when to provide log data
  • the team have a good understanding of the needs of the front line staff and potential issues with capability and internet connect issues when visiting tenants, and have continued to iterate the paper form to aid data collection
  • the team have been working alongside helpdesk support users to provide assistance to users who are unable to log data, for example small organisations and charities

What the team needs to explore

Before moving into Public Beta, the team needs to:

  • identify ways to test the end to end process with their Private Beta users. The team have acknowledged that testing the end to end of the service is challenging, as this happens over multiple sessions across multiple users and the service was broken down to test each section

Before their next assessment, the team needs to:

  • increase their testing with users on mobile devices
  • continue to test with user with access needs and new users
  • work with the content designer to identify the right place in the user journey to provide additional support. Current thinking is to create a standalone guidance page hosted on GOV.UK that would be linked to at various points through the site. If additional guidance and support is needed within the service consider redesigning the service to meet the needs

4. Make the service simple to use

Decision

The service met point 4 of the Standard.

What the team has done well

The panel was impressed that:

  • the team have responded to feedback and included a full summary view of submitted logs
  • the design overall follows the GOV.UK style guide
  • the team are working with the Design Systems and wider government departments (Ministry of Justice), providing insight and feedback on new components and patterns and had a good approach to sharing and reusing components and patterns
  • the team have iterated the service name to include the CORE brand that users are familiar with
  • the team are aware that users might not have all the information to hand when completing the service, and have provided options to ‘skip for now’
  • the team acknowledge that work is required to improve the error messages
  • the team has a dedicated content designer that is championing best practice in content design to wider stakeholders, including policy colleagues

What the team needs to explore

Before their next assessment, the team needs to:

  • remove multiple green call to action buttons on the ‘logs’ page of the service. Consider using links or secondary buttons as suggested in the button component within the GOV.UK Design System
  • update error messages and error summary details to reflect the language and form fields displayed on the page, an issue also highlighted in the content review
  • respond to feedback from the content review
  • provide clearer guidance where form validation could be triggered, for example it’s not clear what an acceptable date range should be
  • test and iterate content to explain the ‘collection window’ period to help users who might not be familiar with this service, or the timelines involved in submitting data
  • use the skills of their content designer to help draft, test and iterate supporting guidance

5. Make sure everyone can use the service

Decision

The service met point 5 of the Standard.

What the team has done well

The panel was impressed that:

  • the team have commissioned a DAC accessibility audit on the service, and started to implement fixes
  • the team have published an accessibility statement
  • the team have been co-designing the question within the service with policy colleagues, to improve the language and complexity within the legacy service

What the team needs to explore

Before moving into Public Beta, the team needs to:

Before their next assessment, the team needs to:

6. Have a multidisciplinary team

Decision

The service met point 6 of the Standard.

What the team has done well

The panel was impressed that:

  • the team was well-resourced with all key disciplines represented demonstrating a strong understanding of the Standard and a commitment to building the best possible service for their users
  • the team has strong relationships with key stakeholders in the Department, and were well-supported through proportionate and empowering governance, and effective relationships with partners, including the Department Technical Design Authority
  • the team are developing a plan for transitioning to in-house development capability through the Beta phase, considering knowledge transfer and ensuring long-term, sustainable support and continuous improvement of the service. Considerable effort has been made in documenting decision points and making information available through their collaboration tools, Jira, Confluence and Sharepoint

What the team needs to explore

Before their next assessment, the team needs to:

  • work within the constraints of departmental recruitment practice to ensure the transition to an ‘internal’ team is carried out successfully

7. Use agile ways of working

Decision

The service met point 7 of the Standard.

What the team has done well

The panel was impressed that:

  • the Team demonstrated a strong commitment to working in an agile way, learning and improving their working practices, and changing their service when it didn’t deliver value to users (as with their admin panel)
  • they have sought to be open and inclusive, sharing their work transparently to encourage input and challenge

What the team needs to explore

Before their next assessment, the team needs to:

  • ensure that they apply greater challenge to design choices by testing different solutions to problems. The panel had some concerns that by not prototyping alternative starting points for their service, to provide a guided or step by step approach for submissions, they may have missed opportunities to provide a more intuitive service for irregular users
  • the team should demonstrate at their next assessment that they maintain a Discovery and Alpha mindset throughout the service’s lifespan, and ensure they’re prototyping different solutions to new problems or additional functionality, before committing to a design solution
  • if the team is able to move quickly and can confidently decide the right design choices through each development cycle, they should also aim to bring forward decommissioning of the legacy CORE platform. We would encourage them to schedule Live Service Assessment in late 2022/early 2023, ahead of the current March/April target, to give confidence on progress and enable savings to be delivered sooner

8. Iterate and improve frequently

Decision

The service met point 8 of the Standard.

What the team has done well

The panel was impressed that:

  • the team have been making incremental improvements to the service based on real world user insight

What the team needs to explore

Before their next assessment, the team needs to:

  • be able to demonstrate that they have used data in addition to qualitative user research to iterate their design
  • consider that the short time in private Beta means both qualitative and quantitative insight is limited. The team should carry out at least 2-3 more rounds of research, with an increased private Beta community to provide greater understanding of potential problems before opening the service to all users

9. Create a secure service which protects users’ privacy

Decision

The service met point 9 of the Standard.

What the team has done well

The panel was impressed that:

  • the team have considered security risks associated with the service and have designed the data transfer process to only include daily deltas, ensuring that if the data in transit is compromised, the impact of a data breach is minimised
  • the team have decided against linking the data to other departments or sharing agreements to remove the need to store personally identifiable information
  • the team have implemented authentication controls appropriate for different user needs and proportionate to the data they are able to access
  • the team look to minimise dependencies within the codebase, only use actively maintained packages and use Dependabot for automated dependency updates within GitHub
  • the team audit access to the Production environment, and all engineers with access to the data have appropriate security clearance
  • the service has undergone penetration testing and the team have prioritised fixing critical issues

What the team needs to explore

Before their next assessment, the team needs to:

  • consider a plan for putting the system offline in the event of a security incident

10. Define what success looks like and publish performance data

Decision

The service met point 10 of the Standard.

What the team has done well

The panel was impressed that:

  • the team have a performance framework in place and have identified KPIs clearly linked to user needs which measure service success
  • the team have thought about the intention/spirit behind the mandatory KPIs and are using these in a meaningful way to develop insight, producing detailed work around cost per transaction and using proxy measures to dig into digital uptake
  • the team have thought about how they will track errors to better understand user journeys and identify pain points within the service
  • the team have a plan for how they will publish their data

What the team needs to explore

Before their next assessment, the team needs to:

  • use the performance framework to develop and implement a clear plan for how they will analyse and report on user journeys in order to support future iterations and development
  • consider segmentation of journeys by user type and other characteristics to understand whether particular groups of people struggle with particular parts of the process
  • consider the scale and volume required to draw evidence based conclusions around success and failure of features, ensuring roll out milestones and future development is driven by statistically significant conclusions

11. Choose the right tools and technology

Decision

The service met point 11 of the Standard.

What the team has done well

The panel was impressed that:

  • the team are using the GOV.UK PaaS to host the service
  • the team have selected a mature and stable framework in Ruby on Rails for web app development

What the team needs to explore

Before their next assessment, the team needs to:

  • continue to work with the Technical Design Authority and other relevant bodies for future hosting options

12. Make new source code open

Decision

The service met point 12 of the Standard.

What the team has done well

The panel was impressed that:

What the team needs to explore

Before their next assessment, the team needs to:

  • consider using a suitable tool to automate secrets detection in source code

13. Use and contribute to open standards, common components and patterns

Decision

The service met point 13 of the Standard.

What the team has done well

The panel was impressed that:

  • the team have published a design history of how the service has developed over time
  • the team have used open-source tools where available
  • the team have used common components, such a Ruby Gem for OTP generation, GitHubs actions for CI/CD, https://postcodes.io/ for postcode lookups and GOV.Notify for email notifications

What the team needs to explore

Before their next assessment, the team needs to:

  • consider how other teams can use the code they are developing and explore how they can contribute to common components and patterns

14. Operate a reliable service

Decision

The service met point 14 of the Standard.

What the team has done well

The panel was impressed that:

  • the team are able to regularly deploy zero downtime software changes
  • the staging environment is live-like and hosted on the same PaaS as the Production environment
  • the team regularly host mob sessions for exploratory testing
  • infrastructure and web application monitoring is available
  • alternative process flows have been considered in the event of external services such as the postcode lookup service being unavailable, and rate limiting has been implemented for requests made to GOV.NOTIFY

What the team needs to explore

Before their next assessment, the team needs to:

  • explore if the dashboards and reported metrics are sufficient to feel confident the service will remain performant during the end of the data collection window
  • explore the service wrap around the project - currently Sentry error alerts are being picked up by the team when alerted - would it be beneficial to formalise this process?
  • understand that it’s noted that scaling is not an issue due to the user numbers in private beta, when moving from private beta, a future load testing pipeline should be explored to ensure cost effective autoscaling

Updates to this page

Published 10 August 2022
Contents