Register a property as a short term let Alpha assessment

Service Standard assessment report Register a property as a short term let 25 September 2024

From:
Central Digital and Data Office
Published
14 October 2024
Assessment date:
24 September 2024
Result:
Green
Stage:
Alpha

Service Standard assessment report

Register a property as a short term let

Assessment date: 25 September 2024
Stage: Alpha
Type: Assessment
Result: Green
Service provider: Department for Culture, Media and Sport (DCMS)

Service description

This service aims to solve the problem of…

  • a lack of reliable insight around short-term lets in England means they could be viewed as a possible risk to visitor safety, and the cohesion of communities, housing supply and affordability in some areas.
  • without reliable insight, there is a risk that the sector will continue to face challenges of fairness, sustainability, and consistency in meeting existing guest accommodation standards across England.

Service users

This service is for…

  • Primary users
    • Those who need to use the service to register a STL.
      • Operators and owners
      • Management Companies
  • Impacted / Involved users
    • Those who are impacted by or involved in the scheme.
      • Local authorities
      • Booking platforms
  • Data users
    • Those who directly benefit from the data.
      • Central government users
      • Relevant arms’ length bodies
  • Other users
    • Those who might have an interest in the registration scheme but not have to use or, or benefit from the data it collects.
      • Bookers
      • Neighbours

Things the service team has done well:

  • The team has conducted a very impressive alpha and successfully navigated policy constraints to deliver a compelling ‘story’ of this service. The panel were impressed with how the team are building user centred delivery within DCMS and sharing their knowledge and experience with cross-government stakeholders.

  • The design team has taken careful consideration to design and visualise the overall landscape to register the short-term lets in England, In the detailed service blueprint. They have made a great effort to research and understand how other organisations like local councils will take part and benefit from the service.

  • They have identified and prioritised their assumptions for the overall service and mocked up the service on the prototype kit. The team has proposed a phased approach that is pragmatic to allow ease of the STL sector to comply with the regulations while also ensuring the data collection can influence policy development and secondary legislation.

  • The team showed various options they considered, dropped or iterated for the service and user interface design for ‘Register a short-term let’ in the prototype by using user research findings and GOV.UK Design System patterns and components. The panel was impressed by the thought, consideration, design, testing and iteration of the offline and assisted digital journeys to make sure everyone can use the service.

1. Understand users and their needs

Decision

The service was rated green for point 1 of the Standard.

Optional advice to help the service team continually improve the service:

  • Very good understanding of the breadth of user groups and segmentation of primary user groups.
  • Personas are very impressive in terms of the depth of understanding of user needs and motivations demonstrated.
  • Wide range of appropriate user research methodologies employed, an incredible amount of research has been undertaken to-date.
  • Inclusive approach to recruitment. Approaches to recruitment have been varied to increase sample size. Guerilla type approaches are unlikely to be effective for most user groups (other than people who book STLs). As identified, clear ethical risk analysis needs to be considered for more vulnerable groups.
  • Plan for user research in beta is well considered and plans to expand segmentation within groups as well as engaging with secondary user groups.

2. Solve a whole problem for users

Decision

The service was rated green for point 2 of the Standard.

Optional advice to help the service team continually improve the service:

  • The scope of this service is very broad and detailed. The team has proposed a phased approach for implementation, to be tested further with Ministers. We further recommend they prioritise the riskiest assumptions for the registration phase to inform the approach that solves the main challenge of data. They need to identify the parts of the service and design decisions that are most imminent for the service in private and public beta.
  • This will help the team determine which parts of the service to build, the minimum data needed by the various stakeholders. This will help them avoid creating a complicated service that is difficult to use because they try to do too much.
  • The team has outlined considerations for beta and future rollout; however setting priorities, and determining the intended and unintended consequences of each consideration will help the team decide where to begin and make small, gradual changes as they go.
  • The team says many design aspects of the service as shown in the prototype are still undecided due to policy constraints. The assessors believe the team have an opportunity to use research to prioritise assumptions, use alternative prototyping solutions to test and obtain data to support key design decisions and continually iterate and improve the service frequently and in turn inform policy.

3. Provide a joined-up experience across all channels

Decision

The service was rated green for point 3 of the Standard.

4. Make the service simple to use

Decision

The service was rated green for point 4 of the Standard.

Optional advice to help the service team continually improve the service:

  • They tested the prototype with users with access needs and compatibility with accessibility software. They need to continuously iterate the prototype based on this feedback as they mentioned not having enough opportunity to do this in alpha.
  • They need to further test the content, wording and terms that could be considered jargon in the sector such as ‘short term lets’. They ought to ensure all users, including those of varying literacy and digital skill level, can avoid doubt and find the service easy to use and understand.
  • Test the naming of the service and iterate.
  • Test the content and interaction of users with the step-by-step navigation pattern and the start page. The pattern is recommended for use with links to relevant content that will help a user complete each step. The team can consider various options such as combining the links on the right hand navigation on the start page with the step-by-step navigation, to find an option that works easiest for the user.
  • Consider various scenarios and user journeys that can occur when registering a property and offer clear guidance, and relevant routes to users. Such as registrering jointly owned properties, properties owned under a vehicle such as a limited company.
  • On the address question, consider international addresses for property owners residing abroad.
  • The team has made good use of the tabs component on the check your answers page. It needs further iteration to ensure users don’t get stuck on the page and know the next action to take. Consider various options including use of primary buttons on the page.
  • Consider branching and logic such as on questions only relevant to owners with properties in London.
  • Consider the options and layout of the confirmation page where users register many properties at once and hence receive multiple registration numbers.
  • The guidance on structuring forms will be useful for the team to consider the best approach to structure questions in their service. Use a questions protocol approach to make sure every question is necessary. Test the content of the questions, wording, and require the minimum and only necessary information.

5. Make sure everyone can use the service

Decision

The service was rated green for point 5 of the Standard.

6. Have a multidisciplinary team

Decision

The service was rated green for point 6 of the Standard.

Optional advice to help the service team continually improve the service:

  • For Beta and beyond, DCMS must continue to create opportunities to hire civil servants into this team to bring knowledge and experience in-house and reduce the risks associated with a largely outsourced team.
  • DCMS must ensure an appropriately senior and empowered Service Owner is in place to own and manage the delivery of this end-to-end service, throughout the whole life of the service.
  • DCMS should ensure that insight gained from future prototyping and research of this service plays a significant role in shaping future policy choices, alongside or instead of more traditional consultative approaches. Senior leaders should ensure they’re sufficiently engaged in the design of the service to be able to lead policy development informed by real-world user needs and behaviour. Governance should follow the principles of Agile Delivery, empowering the team to work in an agile, user-centred way.

7. Use agile ways of working

Decision

The service was rated green for point 7 of the Standard.

8. Iterate and improve frequently

Decision

The service was rated green for point 8 of the Standard.

9. Create a secure service which protects users’ privacy

Decision

The service was rated green for point 9 of the Standard.

Optional advice to help the service team continually improve the service:

  • The service team hasn’t started building the beta service, which is a good thing especially as it’s possible that another supplier will be called in to do it. However the team has done a great job at making sure as much knowledge as possible will be shared to the next team. Part of that is considerations about specific aspects of building a robust and secure service:

    • estimating transaction rates,
    • proposing a technical architecture for beta,
    • integrating with well-known GOV.UK services like GOV.UK Pay and GOV.UK Notify.
  • The team has created a sound threat model with realistic scenarios, risks and mitigations. However it should include more focus on risks posed by bad actors posing as end users (as opposed to “bad admins”) and explore further risks of fraud and impersonation. Even if the risks have already been identified as low, motivation might still exist and a threat model should reflect that.
  • The team has written a decision log and beta recommendations, which will be invaluable to the next team.
  • The team has designed the service with a “save-and-continue” model in order for users to be able to register across multiple sessions. That has an obvious impact on the user’s experience of the service, as well as on the technical architecture of the service. Yet, while the team has confirmed their wish to use One Login and have incorporated its use in tech documentation, it seems like the work has only been half completed. The panel has no doubt that it’s a question of time and the team would have completed this part of the service eventually, but it might have been better to park the feature altogether and leave it to the private beta phase to establish the need and design the solution.

10. Define what success looks like and publish performance data

Decision

The service was rated green for point 10 of the Standard.

11. Choose the right tools and technology

Decision

The service was rated green for point 11 of the Standard.

Optional advice to help the service team continually improve the service:

  • For the alpha prototype the team used the GOV.UK Prototype Kit without any alterations to the Design System. This is the best way to design a prototype that adheres to GOV.UK front-end principles and prepares the ground for efficient accessibility testing.
  • The technical architecture designed is simple and sound and integrates with GOV.UK services like Pay and One Login whenever possible.
  • The tech stack recommended (python/flask, postgres, containers, etc) is tried-and-tested as the team saw no reason to introduce cutting-edge technology.
  • The team should ensure that all decisions on tools and technology are documented as recommendations for the next team. The panel acknowledges that this is probably mostly done in the existing handover documentation.
  • Regarding the service’s “potential use of AI”, the panel recommends focusing on functionality envisaged from identified user needs, which may end up using AI techniques for their implementation, as opposed to the “where could we use AI in our system” approach presented.

12. Make new source code open

Decision

The service was rated green for point 12 of the Standard.

Optional advice to help the service team continually improve the service:

  • The panel was impressed that the source code of the prototype is public.
  • The team works in the open, and as the prototype’s repository is public the panel was able to appreciate the quality of code writing and use of versioning.
  • The team should ensure that, as much as it is able to, the next team will keep working in the open.
  • Since the team has documented the system well, it would be of great value to share some of that documentation, or at least learnings, with the wider government digital community.

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

Decision

The service was rated green for point 13 of the Standard.

Optional advice to help the service team continually improve the service:

14. Operate a reliable service

Decision

The service was rated green for point 14 of the Standard.

Optional advice to help the service team continually improve the service:

  • It’s likely that, having designed the alpha prototype and envisaged the architecture of beta, the technical team will have a pretty good idea of how the beta service will need to be designed for robustness and resilience, but also of the context of running a digital service on behalf of DCMS. The panel recommends documenting this knowledge as much as possible.
  • Given that the beta service is expected to have many integrations, with other GOV.UK services but also address lookup and move, emphasis should be put on infrastructure design as early as possible. Too many teams start beta with a vague idea of what the infra stack will look like only to find that the private beta service is too unreliable to move forward towards beta with confidence. Adequate DevOps skills should be procured very early on in the next phase.

Next Steps

This service can now move into a private beta phase, subject to getting approval from the CDDO spend control team. The service must meet the standard at beta assessment before launching public beta.

To get the service ready to launch on GOV.UK the team needs to:

Updates to this page

Published 14 October 2024
Contents