This design history describes how we approached the initial design of the add a child part of the childcare entitlement checker.
The focus of this work included challenges around how to:
support families with more than one child
include parents who are planning ahead, particularly those expecting a child
We needed to design a way for users to add children to provide accurate results, without making the journey harder or more confusing.
What we already knew
Discovery and alpha research showed that parents think about childcare support in relation to each child. This is especially true when parents have children who are at different life stages.
We also saw that parents can struggle to relate information to their personal circumstances. They may understand what support exists, but not how it applies to them.
Parents told us they want to plan ahead and understand future childcare support. This was especially important for people expecting a child.
Existing childcare information and checkers often fail to support this. They tend to focus on children who are already born and on entitlement ‘now’, which can exclude planning use cases.
These insights shaped our understanding of what parents would expect from a childcare service and informed the approach we took to designing the add a child journey.
The design problem
We needed to collect accurate child‑level information so the service could calculate eligibility and explain results clearly.
At the same time, we needed to avoid overwhelming users at the start of the journey, particularly families with multiple children or more complex circumstances.
This meant balancing inclusion, clarity and accuracy, and avoiding designs that may force users to speculate or give misleading answers.
What we considered
We considered limiting the service to children who are already born for the initial MVP. This would simplify the journey and reduce early complexity. However, this would not meet the user needs we had already identified. Expectant parents wanted to plan ahead, and excluding them would undermine the service’s usefulness. It might also force these users to give speculative or false answers, which carried risk.
We considered asking about all children at once using a different design pattern, such as a checklist. This risked increasing cognitive load for families with multiple children or different circumstances.
Alongside this, we explored whether users should be able to skip adding children. This was to understand whether people felt uncomfortable sharing child details at this stage. We tested this hypothesis in the round of research on these designs.
We also explored whether asking for names would feel too sensitive, and how to include unborn children without creating false certainty. For this round we tested if this could be mitigated through prompt text.
What we designed
We designed an ‘add a child’ sub-journey at the start of the service to collect information about the children the user wants to check childcare support for. We assumed this would make sense as the first part of the wider check that users would complete.
We used the GOV.UK question page pattern, asking one question per page. This helps reduce cognitive load and makes the journey easier to follow.
The journey allows users to add children one at a time and review what they have added, rather than asking about all children at once.
We included an option to skip adding child details to test whether there was a genuine user need for people who wanted to avoid sharing these.
Adding existing and expected children
We modified the first page slightly to include 2 questions.
We asked whether the child had been born yet, to make it clear that unborn children could be added.
The users journey after this page changes depending on whether the child is born or expected. This alters wording and tense in later questions.
For example, on the following page we either ask “What is Jack’s date of birth?” for born children, and “What is this child’s due date?” for unborn children. This responds to known sensitivities around naming unborn children.
On the same page, we asked what the user would like us to call the child. This was to support clarity in results and help users apply results to their own circumstances.
We included prompt text to support expectant parents: “You can enter anything you’d like us to call them. For example, ‘Baby Smith’.” The aim of this was to allow these parents to use a placeholder or nickname. We wanted to avoid forcing them to give a formal name to their unborn child as this can be a sensitive issue.
Other questions we ask
For each child, we asked about birth or due date, relationship to the child, and how much time the child lives with the user.
We included questions about disability or additional needs only for born children. This ensures relevant entitlements are identified without forcing speculative answers. We decided to not ask this for unborn children as this may require speculation and could be potentially distressing.
Check answers page
The sub‑journey ends with a “check your children’s details” page, using a card‑based pattern. This groups information and supports review and editing.
Following a design crit before testing we changed the “add another child” link into a clear secondary button to improve visibility. This takes the user back to the start of the process of adding a child.
What we learned and how we iterated
For our first round of private beta research we focussed on testing the add a child section of the journey on its own. We also included an initial concept for the results page. Additional questions around work, income and benefits were looked at in the following round.
We tested with 7 participants, made up of:
all women
people expecting children, those with children and those with a mix of both
2 participants with access needs
a mix of income levels
a mix of racial and ethnic backgrounds
Users expect to provide children's details
Research showed that participants expected to add children’s details when checking childcare entitlement. Several questioned how useful results could be without this information.
This confirmed that placing the add a child journey early in the service matched users’ expectations and mental models of a childcare service.
No users wanted to skip adding children as they all wanted to understand how entitlement related to specific children.
Based on these responses we removed the option to skip adding children at the start of the journey.
There was a small amount of uncertainty about how to add children and providing a name
Expectant parents felt included and understood that they could add an unborn child. Some parents were unsure about the order to add multiple children, or whether they needed to add all children.
Asking for a child’s name helped participants understand which results applied to which child, particularly in families with more than one child.
However, some participants were unsure why names were being asked for and if it would link to an application. This could potentially increase uncertainty and anxiety when answering.
Following this round, we split this first page into 2, asking for the child’s name and whether the child had been born yet separately. This follows standard use of the question page pattern and reduces the number of decisions on a single page.
We also clarified the instructions for adding children and added a details component to explain why we capture a child’s name.
Most were happy with adding birth and due dates
Most participants were comfortable sharing birth or due dates and understood that this affected when funding could start and end.
Some parents did hesitate, worrying that entering a due date could lead to inaccurate or misleading results. This highlighted the need to be clearer about how this information is used.
To address this we also added a details component to the page to explain why these dates are needed to provide an accurate answer.
There was some confusion around the question on how often the child lives with you
The question about how much time a child lives with the user caused the most confusion. Participants understood why it was asked but struggled with the wording.
We noted this question, about time spent with a child, as a priority for refinement and further testing.
Users found the check your children’s details page useful
The check your children’s details page worked well and helped participants sense‑check information before continuing.
Users were clear how they could add more children from this page.
Providing an explanation, adding a details component
Across this journey, we saw that uncertainty increased when users were unsure why information was being asked for.
We added details components to explain why we ask for:
a child’s name
birth or due date
time spent with the child
These explanations aim to reduce anxiety, make the service feel more transparent, and help users understand how their answers affect results.
What we still need to learn
For further research and design iteration, we still need to test if:
this journey works well for users with more complex situations, such as shared care arrangements
alternative wording for the question about time spent with a child or if this question is needed (as it may relate more to who applies for a scheme than entitlement itself)
parents clearly understand when results are indicative
We need to understand how the add a child sub‑journey works with the wider service, particularly in supporting clear and accurate results.
Further private beta research will help us validate these decisions and continue refining the journey.