Single directory: creating the MVP and thinking about post-MVP

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.

In our first design history on creating a single directory, we explained why we merged the ‘Find’ and ‘Connect’ directories to create a single directory that simplifies access to services.

To develop the single directory, we needed to define what would be included in our minimal viable product (MVP). This post covers the decisions we made in developing this and the next steps we were going to focus on post-MVP.

The design problem: merging ‘Find’ and ‘Connect’

The existing directories were designed for different primary user groups:

• Find support for your family (‘Find’) - for members of the public to find support for themselves and their families
• Connect families to support (‘Connect’) - for practitioners and organisations who are looking for or provide support for families

To effectively merge both services we had to consider how this one service will be beneficial to all user groups. The three user groups are:

• local authority (LA) practitioners - who could previously log in and view and send ‘connection requests’ for support to voluntary, community and faith sector (VCFS) organisations
• VCFS practitioners - who could log in and manage requests for support
• public users – who had no login and could only view LA services

The questions we needed to consider when designing the single directory included:

• what features need to be prioritised for MVP?
• will all user groups still be able to carry out the same tasks as they did on Find and Connect?
• how will users enter the service and what will they see on the landing page?
• how can we create content which caters for all different user groups?

We also needed to consider the limited amount of time we had to carry out any necessary design and research work as a constraint.

In addition to this, due to technical and product decisions, several requirements for the MVP were changed after we had started design ideation. This meant we had to quickly adjust our designs to be able continue the work on the single directory.

Our approach

We began by mapping out the user journeys for the 2 existing directories on a Lucid board to conduct a side-by-side comparison. From this we highlighted the differences between the two services, which included:

• start pages
• postcode pages
• the login features
• request for support tool
• search results page

User role mapping

Next, we carried out role-based mapping to identify the different potential users and what features they can and cannot use. Within this we highlighted any relevant user needs and pain points. These included:

• a need for content that allows all users to effectively use the service
• a location search is still a priority to include within our service
• ensuring public users and practitioners can find and refine relevant services
• avoiding any confusion and frustration around the login process and who this is for

Risks and assumptions workshop

To identify the key risks and assumptions of merging Find and Connect, we carried out full team workshop to gather as many perspectives as possible. The key risks and assumptions are:

• if we provide a login for MVP, how do we design it so that it’s clear which user groups need it?
• if we do not include connection request within the MVP, will practitioners find value in our service?
• will we be able to provide a start page that caters to all different user groups?
• will having this new service cause confusion for those currently using Find and Connect?

Gap analysis

We next carried out an analysis to identify any potential gaps between the current directories and what would be useful for our users.

From this we were able to identify any areas for improvement and begin planning how to best implement the merged service.

User research

We ran user research sessions with practitioners and parents which fed into our designs for the single directory. You can read more about this on our design history about research with parents.

Due to time constraints, we had to begin the design and building of the single directory before all the research was completed. However, we used the research sessions to validate the choices we had made for MVP and to also feed into design planning for post-MVP work.

Designing the MVP

We made the decision to use Connect as the basis for creating the single directory. This was because it had more of the potential functionality we expected would be needed, such as:

• a login for LA practitioners
• the option for practitioners to send connection requests to VCFSs

The development team began the technical work on creating the single directory, whilst the design and research team members worked to develop our designs.

To start, we created our initial designs in Figma. Once these had been demonstrated and signed off, the prototype was updated, and Jira tickets were created for the development team.

Key design decisions

This section includes our main design decisions that were made for the single directory MVP.

Hiding the request for support tool

A feature flag was created for the connection request functionality. This was done to allow us to turn the feature on or off. Due to concerns around privacy and technical feasibility the decision was made to turn it off for MVP.

However, having it behind the feature flag meant this could be done without deleting the supporting code and it could be easily turned back on in the future.

Hiding VCFS services

A feature flag was also added to show or hide VCFS service data. Due to GDPR concerns which were raised around the data held for these, the decision was taken to hide them. Once these concerns were resolved the plan was to make them visible again for both public and practitioner users.

Start page

The Connect start page was specifically designed for practitioner users. As such, we needed to redesign it to clearly explain the service for public, LA and VCFS users.

To design the start page for MVP we:

1. Identified the what the user needs are for the different user groups.
2. Looked at the risks and assumptions we need to consider for the single directory MVP
3. Researched the different methods other services have used as their landing page. We explored different options for a public user journey, a logged-in user journey and a combined journey for both.
4. Ideated different design options including with or without a login, and separate versions for parent and practitioners.
5. Took these initial ideas to a design crit and identified the best options for the MVP and to explore for post-MVP
6. Considered the feature flags and create a finalised design for the MVP start page.

The final design for this page had no login option and the content is designed for all user groups. A placeholder name was added to the start page - ‘Find support for parents, carers and young people’.

Login edge case

We identified several edge cases where practitioners may possibly be able to login if they have bookmarked a page which is now hidden behind a feature flag. A decision was made to still allow users to log in in as it would require additional work to remove this functionality.

Once logged in the practitioner will be taken to a 404 error page which will direct them back to the start page. They will then be logged in but will not be able to carry out any additional actions. It was decided not to carry out any additional work to mitigate any frustration this would create as the number of users it would potentially impact was very small.

Additional changes

The single directory MVP will have a limited number of additional features which were identified within the previous rounds of user research with practitioners. These features are:

• grouping the category filter into dropdowns to reduce scrolling
• changing the cost filter to one tick box rather than two which states ‘Only show free services’ to eliminate confusion
• age groupings have been changed to align with common educational age ranges
• updating error pages 403 and 404 so that it will help dealing with the edge cases
• hint text was added to the ‘Days service is available’ filter so users will know this field is not mandatory to fill out
• delivery method has been removed from both the service results page and the service details page due to limitations in the data we had available

What was out of scope for MVP

Due to time constraints and technical complexity the decision was made to de-prioritise some parts of the directory.

Connection requests

This feature will be re-evaluated post-MVP to see if it should be included within this service.

Displaying only open referral (OR) compliant fields

We have some limitation on the data we can display due to the OR data standard we were using. However, we made the decision to leave work on making all the data we displayed compliant with OR. This was due to additional design and technical work that would be needed to address it.

You can read more about this on our design history about pulling in data using the OR standard.

Confirming the name and URL of the service

A place holder name ‘Find support for parents, carers and young people’ was chosen for MVP. A final decision on the name for the single directory was postponed until post-MVP to allow us to gather more insight and clarity.

You can read more about this on the design history on naming the service.

Further improvements to the user journey

Further improvements such as providing a search bar has been deemed beyond necessary for MVP as it requires more user research and design thinking.

Next steps

A working version of the MVP single directory was created. However, due to the end of the project, it was not made live. The code, along with design and technical documentation has been archived in case the project is revisited in the future.

Once MVP was completed the goal was to start iterating. We began by evaluating the user research on practitioners and parents as well as the competitor analysis to inform our design ideation for post-MVP.

Re-adding family hubs

We started exploring how we will re-add family hubs back into the service.

Details of physical family hubs were previously included in the service results list within ‘Find’. However, the way this had been done was effectively a ‘quick fix’ that was not technical sustainable and had to be taken out. It was decided for the single directory, based on business and user needs, that a design would be needed to add this back in.

We started by reviewing how family hubs were previously shown in ‘Find’. Based on this, we decided to keep family hubs separate from the service results list, as combining them added unnecessary confusion.

We then explored different design options in Figma, including:

• showing the nearest family hub above any filters and service results, linking to a family hub details page
• adding a separate tab for family hubs within the local authority based on the postcode entered
• exploring an alternative version using town or city instead of postcode (removing the ‘nearest hub’ feature)
• designing a family hub details page with a list or table of linked services

After creating these designs, we ran a small workshop with the family hubs team to gather thoughts, suggestions and risks. From this we identified questions that need to be explored, what research needs to be done and the ideal approaches for design.

The things we would go on to explore next would include:

• clarifying the purpose of family hubs in the service and what our priorities are
• further research to test how users interact with family hubs and what they prioritise
• validating the preferred design of showing the nearest hub on results pages, plus a separate tab listing all hubs in the area
• exploring the feasibility and value of adding maps and images
• planning for what happens if no family hubs exist in the user’s area
• investigating ways to link services to family hubs by location, and any limitations involved

Start page

For the start page we have begun to explore:

• how the practitioner login will work and where in the service will it be placed
• if we could combine the postcode and the start page together as to have less click for the user
• the content that will need changing depending on which feature flags are turned on or off

The name of the service

If the service were to continue post-MVP, the naming work would need to resume. This would involve reviewing previous insight, confirming the service’s purpose and audience, and testing refined naming options. The final name would then be agreed with policy and implemented across the service.

You can read more about this on the design history on naming the service.

Other design work we’d explore

Our research with practitioners and parents helped us identify several areas where further design work could improve the single directory

Refining how services are presented

We’d explore structured layouts for service listings, making key details like cost, location, age range, and access more scannable. We’d also test new content patterns to better support decision-making, especially for users skimming or feeling overwhelmed.

Improving filters and search behaviour

Design work to refine filters beyond service categories would be a priority. This includes exploring filter combinations, default settings, and the interaction between structured and free-text search to support more accurate results.

Testing how the directory fits into practitioner workflows

We’d do more work to explore how practitioners discover, save, and share services with parents. This would include exploring ways the service can integrate with existing tools or referral methods.

Iterating on the connection request feature

While this was deprioritised for MVP, we’d revisit how this feature could be designed to work for practitioners and or parents. This would include things like what support or confirmation users might need when making a request.