As of April 2025, we will not be developing the family hubs digital service further. While we’ve learned a lot, some key challenges, such as how to ensure good quality data, prevent us from creating a valuable service at this time.
The value of the single directory depends on the quality, accuracy and volume of data we have about local services. To be useful for families and manageable for local authorities (LAs), we need a way to import data easily and consistently.
Until now, most of this data has been entered manually by people from our LA partners through the 'Manage family support services and accounts' (Manage) service. This approach isn’t scalable. We carried out a technical investigation into methods of importing data to understand the impact different approaches would have on the:
- user journeys
- features
- experience of using the single directory
One of the approaches we considered was using the Open Referral (OR) data standard to import data about local services. This post explains the work we did while exploring this approach.
The problem
The approach we investigated involved transferring data from LAs who already use the OR standard to save and share information about local support services. This would be done using an application programming interface (API).
However, we had a problem. Some fields we were previously using to ingest data through Manage were either:
- custom fields that are not shared with the OR standard
- optional fields within the OR standard
This meant that we would not be able to guarantee that data we were importing matched the fields we display on the directory.
Investigating the problem
To understand the potential impact on the directory, our Technical Architect and Lead Engineer conducted a ‘tech spike’ (investigation). As part of this they conducted gap analysis and mapping exercises. The fields highlighted as optional in OR data were:
- address (including postcode)
- categories
- cost
- age range
- service availability
- language
- contact details
- location opening times
The fields we have in Manage that are not available in OR data:
- delivery method (such as in-person or online)
- if a location is a family hub
- availability details
Risks identified
If we were to use the OR standard and APIs, to pull data into the single directory there were several issues we would need to address.
Not knowing the location of all services
The biggest risk to the current user journey is that not all services have a full address and postcode assigned to them. This makes creates problems for searching by and enabling users to find services near them.
The proposed technical fix to this was to apply a local authority address to all services that do not already have one. This would ensure that services were shown in the search results, however it would still have an impact on the accuracy of the results.
Services that we had applied the address to would need to have the location hidden from the user to avoid confusion. The sort order in the single directory is currently by distance from the post code the user had searched for. Without an accurate postcode this would also be inaccurate for some services, so we would need to change how we sort results.
Missing contact information
The value of our service to users depends on them being able to contact or follow up with services that would be helpful to them. As such, some form of contact detail (address, website, email or phone number) is required for each service listing. As these contact details are optional in the OR data standard, some listings may be missing them.
Based on user research, we decided to only include services with at least one contact method to make sure the directory remained valuable for users.
Not being able to accurately filter results
Some optional or missing fields affect users' ability to filter search results. Research has shown this negatively impacts the ability to use the directory. For example, as not all services have categories assigned to them, they would not be returned even when a user applied a category filter.
The technical solution we proposed was to add categories in the database through keyword association. This would mean categories filters might still be used, but filtering would still not be supported for:
- cost
- service availability
- age
- language
- search radius
Defining our minimum viable data
Following this tech spike, we started work on defining what our minimum viable data standard would be for displaying a service in the single directory. We agreed with our policy colleagues that this would be a service listing that as a minimum included a:
- title
- description
- way to get in touch (at least a website, phone number, email or similar)
Our next step was to consider how this would impact our designs.
Design considerations and approach
We started by mapping the findings of our analysis to the single directory designs and highlighting areas that would need to be removed or changed.
Filters
As most of the filters would be impacted, this left us with just the category filters.
Search results page
If we were to use the OR data standard, some information about services would not be consistently available. The information which would potentially be missing is:
- distance from search
- age range
- location
- cost
We mocked up what the designs would look like using sample data from three LAs to show just:
- service name
- description
- contact information
These lo-fi mock ups highlighted how inconsistent the descriptions from the OR data could be. Some were several paragraphs long while others were a few words or sentences. On the existing Manage service there is content guidance and a character limit which means we have a more consistent level of detail in descriptions. This is not the case with the OR data.
To understand more about the role of descriptions, we tested an early version of the directory showing only the:
- service name
- categories
- available contact details
Service details page
On the service details view a lot of the information we show in the single directory would not be available for all services. To investigate the impact of this we made lo-fi mock-ups from real OR data.
We found that there was noticeable variation between and even within service data from LAs. For example, some listings included age, price and availability in the correct fields, while others only mentioned them in the description. This means that there will be a large amount of inconsistency between listings which would have a negative impact on the user experience.
To test this, we created mock ups where we stripped back to just the:
- service name
- description
- available contact details
We then mocked up realistic examples with sample data from the LAs so that we could test the impact of variation with users. We made sure we had examples with different styles of description, including ones that were:
- long and detailed
- medium length with some detail
- short and vague
See the parent research design history for how we tested these designs with users.
Key insights from testing designs with parents
The quality and consistency of the data is critical to the overall user experience of services like the single directory. Parents found inconsistent service descriptions hard to scan and lacking the detail needed to judge if a service was relevant.
The fields which are optional in the OR data standard are valuable for users to decide if a service or activity would be relevant to them:
- location
- cost
- age range
- types of activities available
- dates and times of activities/ service hours
- website and contact details
- how to access the service (e.g. walk-in or booking)
Reducing the options for filtering to just the categories meant that searches were less well refined and results were less relevant to parents. In the single directory we do not use faceted filters, in a future iteration this might have improved usability.
Trust
There is implied trust in government services that the data we show has been vetted and is accurate and up to date. This is more challenging to ensure when the source of data is not within the same system as the service.
Parents need to be reassured of the quality and safety of a service before they choose to bring their family to it. We would need to explore this further if the project was to continue.
Proposed next steps
The single directory will only be valuable when there is more consistency in the way different LAs manage and maintain data about local services. Adopting the OR standard could help speed this up. Without better data, a centralised directory won’t be scalable, stay up to date, or meet the needs of parents, carers and young people.
If the data were readily available, our next step would be to test how to improve the findability of relevant services. We’d focus on adding value for users.
Here are some of the areas we would explore.
Improving service descriptions
A structured description with a clear hierarchy of information is easier for users to read and assess for value.
Resolving data governance issues
We do not currently have the right data governance in place to extract data through APIs as our data sharing agreement, privacy statement and processes do not include API extraction of data. Getting these in place may be a potential barrier for data ingestion methods in the future.
Understanding other impacts of this approach
Using an API to import data creates challenges for one of the single directory’s key features. At the moment, voluntary, community and faith sector organisations need an account to be added to the directory. This allows them to manage their service listings and receive connection requests from local authority practitioners.
If we pull in service data through and OR API, these accounts won’t be created. This means the connection request feature would no longer work for those services. We’d need to explore how to address this gap.