We redesigned the homepage, including the service name, to help professionals more easily search for, and connect families to, support services.

Changing the service name

We changed the service name to ‘Connect families to voluntary and community services’. This made it specific to voluntary and community services (VCSs) because, at the moment, we’re only showing voluntary and community services in the directory.

Talking about children and families

We changed the language we use throughout the prototype - where we previously referred to children and families we now just say ‘families’. This is to save space and make content shorter and easier to read. We can reverse this decision if we see problems in testing.

Making our safeguarding messages more helpful

We changed safeguarding messaging to say that our users should call the police if anyone in the family is in danger, not just children. We did this because some of the VCSs offer domestic abuse support. In light of this, some professionals will be making referrals for that reason. We also flipped this message and front-loaded the most important action: ‘call the police’ as opposed to ‘do not use the service’, which now appears after.

We still need to validate this with a user need.

We changed the inset component consent message to a bulleted list with paragraph text. That’s because we needed to specifically tell users what they’ll need to give a service when connecting a family to them. This need came from our Data Protection Impact Assessment (DPIA) team. One of those is consent from the family. We also removed reference to age in the consent message because local authorities told us that was incorrect.

We moved to single postcode search that shows users all services within the local authority area the postcode is located in. We moved away from searching by name of service because this was not supported by back-end functionality we were using (for MVP, we’re just displaying services by local authority).

We used ‘search’ rather than ‘find’ because ‘find’ implies that the user will find what they’re looking for.

We deliberately did not include ‘family’s postcode’ in the ‘enter a postcode’ content because it may not always be that postcode the professional uses. We’ll wait for user research findings to see what professionals enter.

Search results

Sorting the results

We removed ways to sort results because, for MVP, we are displaying results from local authority rather than by distance. This means we can’t use common sorting methods like distance.

Previewing services

We structured the service preview by using what users told us was most important to them when choosing a service. For example, users told us that cost is the most important factor for families when choosing services. Professionals also told us that type of service is the most important factor for them when searching.

Filtering by category

This filter is first because professionals told us in early rounds of research that ‘type’ of service was the most important factor for them when searching.

We used ‘category’ because this is consistent with other search services in government.

Filtering by cost

Users told us cost was the most important factor when families consider services they can use. For that reason, it’s placed above other filters and is closer to the top of the page.

We also changed ‘paid’ to ‘pay to use’ in case users interpreted ‘paid’ as meaning that some services were already paid for. ‘Pay to use’ clarifies that families have to pay to use these.

Filtering by who the service is for (children and young people)

We changed this to reflect that this need is now met by categories, and that we’re not collecting this info from the add service prototype.

Filtering by how the support is delivered

We changed this to ‘delivery method’ because it's shorter. It also allows us to display this info in the service preview - ‘how the support is delivered’ is too long to fit in the service preview otherwise. ‘Delivery method’ is used in existing local authority directories.

Adding new filters

We added ‘can families choose location’ and ‘language’ filters based on findings from user research.

Service details page

Table of information

We brought the information table to the top because it’s the only piece of user-generated content on that page we can control. Leading with the ’more details’ section at the top was risky because users may not enter information during the VCS admin process, which means this could be blank.

Adding connect feature, new button, and removing contact details

We removed contact details from the page because there’s no need now that the user can use our service to connect a family to a VCS service. This new content explains that:

  • the service will contact the family if they can help
  • the user needs consent
  • their contact details will be shared with the service too

‘Your contact details will also be shared with the service’ is deliberately passive because it meant we could front-load the words ‘your contact details’. We were conscious of the amount and length of content on this page.

Removing the second start page meant that we needed to surface this information here instead.

Moving the call to action (CTA) button

We moved the CTA from the right hand side column to the bottom of the page because there was evidence from other DfE user research that this causes cognitive difficulties for dyslexic users.

We also changed the CTA from ‘Start now’ to ‘Connect family to service’ to better reflect the action the user takes when they select it.

Connect flow

Removing the second start page

We removed the second start page. That’s because it was unnecessary and made the journey longer than necessary. Any content that users need to see was moved to the previous service details page.

Adding a safeguarding speed bump

We added this page to make sure users do not use the service if someone in the family is in danger. If the user says someone is in danger, they’re sent to a page that tells them to not use the service and to call the police.

We sent our safeguarding messages to the Child Protection Safeguarding Unit for them to review and sign off. They returned their comments on 11 November 2022.

This question already existed, but we received business requirements from the DPIA team to make sure we were: very specific in telling the professional to get permission from the family and specific what the family’s data will be used for.

To meet this need at this point in the journey, we used content to tell the professional which details we were going to ask them for later in the flow.

If the user says they do not have consent, they’re sent to a page that tells them they cannot continue. It also tells them they should go and get consent from the family if they want to make a connection. We also tell the user, again, about which details they need consent for.

Asking who to contact

We completely redesigned this page and shuffled its contents around to other pages in the flow.

Firstly, we now ask users who to contact in the family. This question is more inclusive because it avoids language like ‘parent or carer’ for situations where the child or young person receiving support can be contacted themselves.

Asking how to contact the family

We broke this page down using checkboxes to show common methods of communication. We opted for checkboxes because users can select more than one method.

Professionals told us during research that some families prefer to be contacted by Whatsapp or text message. To meet this need, we added a checkbox and field for text message.

Getting details about family

Research showed us there’s an issue with services receiving vague referrals. To meet this need, we added guidance to this page. Professionals also directly asked us to provide guidance for them.

The exact guidance we show users was shaped by research. For example, users told us that often it would be useful for the service to know when the best time to contact the family is. For that reason, we added it in.

Interestingly, professionals told us families may withdraw consent if they’re forced to share lots of personal information up front. We were also faced with the problem of different services needing to know different types of information about a family in order to process or triage a connection. To meet these differing needs, we made sure guidance on this page was not overly prescriptive. We’ll need more research to help define how we approach this page. We’re conscious of causing vague referrals.