This design history covers work carried out relating to the results page in April 2026.
The results page is where users see how their answers translate into support and begin to decide what to do next. Earlier research had shown that many of the hardest problems for users emerge at this point, particularly around understanding what the results mean for their situation.
What we already knew
Across discovery, alpha and earlier private beta research, we had seen issues with how users interpret results. This included confusion about:
- which schemes can be used together
- when funding starts or changes
- applying results to personal circumstances
To bring this understanding together, we ran a team workshop to review existing insight, identify assumptions and risks, and prioritise what to design and test next.
As part of this, we created a set of “how might we” statements to clarify what the results page needed to do. These included, how might we:
- make it clear which schemes can be used together and which cannot?
- help users understand when support starts, ends or changes as their child gets older?
- help users understand what the results mean for them, not just list schemes?
- reduce overwhelm, particularly for users with more than one child?
- make next steps clear without making the checker feel like an application?
- show that results are indicative, not guarantees, without undermining trust?
While these questions covered a wide range of issues, several consistent themes emerged. The results page needed to:
- explain scheme combinations and exclusions clearly
- make timing and age‑related changes clear
- support users to apply results to their own circumstances
- manage cognitive load, especially in multi‑child scenarios
- provide clear, trustworthy next steps
This shared understanding shaped what we chose to design and test next.
The design problem
We needed to present results in a way that helps users understand what support is available, including:
- what applies to them
- how schemes related to each other
- when support would start or change
At the same time, we needed to avoid overwhelming users with too much information.
There was also a challenge around certainty. Some users have complex or changing circumstances, and the checker cannot give definitive answers in every case. The results page needed to handle this clearly, without undermining confidence in the service or making results feel unreliable.
What we considered
We had a previous version of the results page that was created as a placeholder concept during alpha that we needed to develop.
Before doing this, the team discussed different ways of structuring and presenting results.
We considered things like:
- how much information users should see at once
- whether to show only schemes users could apply for now
- how to separate current entitlement from future entitlement
- where explanations about timing, conditions and scheme combinations should sit
- how explicit we should be about any uncertainty
We explored several options that we chose not to take them forward, including:
- using tabs to switch between children, which had the risk that some users might miss additional content
- providing only a high‑level summary of what users could get, which risked not giving enough information for users to understand what they could do next
- using both a summary and detailed cards, which risked repeating the same information across the page and increasing the amount users needed to process
- splitting results by scheme rather than by child, which made it harder for users to apply results to individual children
- experimenting with different card styles to balance proving enough detail with users' ability to scan the content
Each option involved trade‑offs. Simplifying too much risked hiding important conditions or creating false confidence. Adding more explanation risked increasing cognitive load and making the page harder to use.
What we designed
At the top of the page, users are given a short explanation of what the results represent. Content also reminds users that results are based on the answers they gave and may change if circumstances change.
The page is structured around the child rather than individual schemes. This reflects how parents and carers tend to think about childcare support and addresses our earlier “how might we” statements around:
- reducing cognitive load
- helping users apply results to their own situation
Each child has their own section. Within each section:
- support the user can apply for now is shown first
- future support is shown separately, based on the child’s age
Details of individual schemes relevant to each child are presented using the summary card pattern. This pattern was chosen to support readability while allowing us to display key details consistently across schemes.
Each card includes:
- a short description of the scheme
- what the user can get
- when they can apply
- when the support starts and ends
- how the scheme can be used with other childcare support
- a clear route to apply or find out more
The page also includes a help and contact section to support users who need further guidance, which we know requires further refinement.
What we learned
User testing took place in April 2026 and included 11 participants. The sample included users with a range of access needs, income levels and childcare entitlements, and reflected a mix of ethnic backgrounds. This allowed us to gather feedback that reflected a variety of circumstances rather than a narrow user group.
Participants generally responded well to the structure of the results page.
Breaking information down by child, age and entitlement helped users orient themselves. Several participants commented that the use of sections and cards made the information easier to scan and less overwhelming.
However, this round of testing highlighted some areas that need further design consideration.
Managing cognitive load, especially for multiple children
While structure results per‑child worked well overall, several participants raised concerns about potential overwhelm when results are shown for more than one child.
One participant suggested a short summary at the top of the page, giving an overview of what each child is entitled to now, with links to more detail. Others noted that seeing many cards at once could be challenging for users who are time‑poor or already under stress.
This reinforced the importance of managing information density and considering additional orientation or summary patterns.
Understanding what results mean in practice
Participants generally understood what support was shown, but some struggled to understand how it applied to their situation. This included how schemes worked together and what rules or conditions would affect their use.
These responses suggests the results page needs to do more than list facts about the schemes. It needs to help users interpret the information in practical terms, without turning the page into a policy explanation.
Clarity of next steps
Testing with users reinforced how important clear next steps are to user confidence. Where it was not obvious whether a scheme required an online application, contact with a provider, or further action elsewhere, users hesitated or felt unsure about what to do next.
These responses from users highlighted the need to make responsibilities and application routes clear early, before users commit to an action or assume the checker is doing something on their behalf.
Showing ineligible schemes
We probed users about the fact they were not being shown schemes they were not eligible for.
Responses to this were mixed. Some users thought it could be useful for sense‑checking or future planning, while others thought it would be confusing or discouraging.
Based on responses we have not established a clear need for this at this stage.
It also suggests that showing ineligible would need to framed carefully if included. Without clear explanation, it risks increasing cognitive load or undermining confidence in the results.
We intend to explore this further in future research, especially with users who are not eligible for any support. However, we may leave this until after the launch of our MVP as we don’t think it is needed to meet our core user needs.
Reinforcing the need to capture information about leave
Testing the results page with users also reinforced the need for us to do more work to make the service work for users on leave.
Being on some kind of parenting related leave is common for users of this service and can affect both eligibility and when support can be accessed.
Users on leave often struggled to apply the results to their situation. They were unsure whether eligibility was based on their circumstances now or their circumstances when childcare would start.
As a result, we will be adding additional questions to future versions to allow us to provide more specific results for these users.
What we still need to learn
Our one-to-one testing with users helped us understand how users respond to a more detailed results page, but there are important limits that we need to note.
Research was carried out in moderated, test conditions. Participants had time to focus on the service in a way that may not reflect real‑world use.
Many participants also had prior experience of childcare and childcare funding, which may have reduced the effort needed to interpret results.
We need to test how the results page performs in more realistic conditions and with a broader range of users.
There are also still open questions about the results page design around how:
- to explain why schemes appear without displaying full eligibility logic
- the results page works for users who are not entitled to any childcare support
- users with little or no prior experience of childcare understand and act on the results
- the design performs when users are tired, distracted or using the service in short bursts
These areas will need further exploration in future rounds of research.