The family hubs digital project aims to improve how parents, carers and young people find support services in their local area.

We have been working with several partner local authorities (LAs) in our private beta stage to build and test 2 directories.

Find support for your family (Find)

Find is a directory primarily aimed at public users, showing LA services (many based at a family hub).

Users do not need an account to log in to access this directory.

Connect families to support (Connect)

Connect is a directory that provides information on voluntary, community, and faith sector (VCFS) organisation services. It is for practitioners working with parents, carers, and young people. Practitioners include people with job titles such as ‘Family practitioner’ or ‘Strengthening family's practitioner’.

Users do need to have an account and sign in to search and submit requests for support on Connect.

Why we are creating a single directory

We have now started work on merging Find and Connect.

We believe this will:

  • make the service easier to use
  • better meet our objective of connecting people with the right support

We need to test this further and explore how we might combine the directories.

The reasons for creating a single directory include:

  • user research findings
  • problems with maintaining 2 separate directories
  • technical considerations relating to our use of the Open Referral data standard

User research findings

Our previous rounds of research with LA and VCFS practitioners have validated the need for a single directory. We did this user research using a variety of methods including interviews, usability testing, and workplace visits (many of them at family hubs).

We found that:

  • the distinction between LA and VCFS services does not match practitioners’ ways of working or needs
  • it introduces unnecessary additional steps for users in finding the most relevant support, regardless of who provides them
  • it caused repeated confusion for organisations when adding information about services, as they expected them to appear on both directories

Problems with maintaining 2 separate directories

Find and Connect were originally developed as part of 2 separate projects. When the projects were merged, they were still kept as distinct directories. This was because there was a risk relating to making information about VCFS services available to the public and overwhelming them with requests for support.

There have been several challenges with maintaining 2 distinct directories, including:

  • duplication of effort when updating designs and code
  • an unclear value proposition when talking to local authorities
  • cost and resources of operating and updating two separate websites
  • ensuring compliance and consistency across both websites

Moving to a single directory would help address these challenges.

The Open Referral data standard

Another reason for adopting the single directory approach comes from the way we store and manage data.

To ensure quality and consistency when importing data from local authorities, we adopted the Open Referral data standard. However, Open Referral lacks a field to differentiate between VCFS and LA services. Maintaining 2 directories requires updating every service manually. This approach would be unsustainable when expanding the directories to more local authorities in the future.

Our hypotheses and the user needs behind them

We hypothesise that a single directory will make it easier and more straightforward for users to find and access relevant support services. It will:

  • provide public users and practitioners with a more complete view of what services are available in their area
  • make adoption of the directories more valuable to local authorities

We need to test if these hypotheses are correct and how best to approach creating a single directory.

User needs and stories

Our research has helped us to create user needs that support the move to a single directory. These include:

  • as a practitioner, I need to be able to quickly identify the most appropriate services for my clients, so I can help them in the best way
  • as a VCFS manager, I need to be able to assess the local offer, so that I can identify any gaps and work to provide the right services at the right time for our community
  • as an LA leader, I need to know that the digital services I employ add value to my organisation, so that I can make a case for their use

The user stories that come from these needs will help inform the design for the single directory. These include:

  • as a LA practitioner, I need to be able to narrow down information on the directory, so that I can select the service that best meets my client's requirements
  • as a LA practitioner, I need to easily see the type of service, how it's delivered, times, and distance from my clients' location so that I can judge if it meets their needs
  • as a VCFS manager, I need to be confident that I'll be able to manage the number of referrals to the service, so that I know I can address them

Next steps in creating the single directory

Our service designer organised several kick-off meetings and workshops with the entire team to identify the minimal viable product scope and requirements.

We reviewed past work, including user research and technical explorations, and addressed key challenges in merging the 'Find' and 'Connect'. We established a clear plan for the prototype and user research testing.

The main actions that came out of these workshops were to:

  • develop a prototype to test with users
  • gather and analyse feedback from testing
  • plan iterations to refine the product and scope following the research
  • investigate how LA users will access connection request features and log in
  • consider the implications of VCFS services choosing to remain hidden from the public
  • understand the technical requirements and constraints

Our approach to research and design

The next steps for research and design work on the single directory are to:

  • build the initial prototype (we will take one of our existing prototypes and start by incorporate feedback from the kick-off workshop)
  • conduct user testing to validate the prototype and gather insights for further improvements
  • refine the prototype based on user feedback and technical evaluations

We will conclude the first 2 rounds of research and design in December 2024 and then will continue with the next stages in early 2025.