This design history describes how we approached the initial design and testing of the work and income part of our childcare entitlement checker.
This part of the journey determines whether working‑related childcare schemes may apply, and whether income thresholds or caps affect eligibility.
It is also the part of the service that carries the highest risk of confusion and drop‑off if not handled carefully.
What we already knew
Many parents do not have stable or straightforward work patterns. People may be self‑employed, work irregular hours, have multiple roles, or move in and out of work.
Previous research showed that parents often find questions about work and income stressful, particularly when they fear getting an answer wrong. Many users worry that incorrect answers could affect their entitlement or cause them to lose support. This risk is higher for people who might be less certain about their circumstance such as those on variable income or the self‑employed.
Parents on maternity, paternity or sick leave often struggle to know how to answer questions about work and income.
Research also showed that users are sometimes surprised by rules where a partner’s work or income affects eligibility.
The design problem
We needed to collect accurate work and income information so the service could apply eligibility rules correctly.
This information is required for both the person completing the checker and, where relevant, their partner. At the same time, we needed to avoid excluding users, especially those with variable or changing circumstances.
We also needed to make household and partner logic explicit, so results did not feel surprising or unfair.
Parents need:
to understand whether working‑parent schemes may apply to them
reassurance that they are not being assessed on their answers
the service to recognise variable circumstances
At the same time, we also needed to avoid making the service feel like an application or assessment.
What we designed
We designed a work and income section that comes after the add a child journey.
We followed the same GOV.UK question page pattern used in the add a child journey, asking one question per page. This reduces cognitive load and helps users focus on one decision at a time.
Asking about work status
We start by asking whether the user is in paid work.
We use ‘paid work’ as this is a requirement for working parent schemes. We included hint text explaining how to answer if the user is on parental or sick leave.
If the user is in paid work, we then ask what best describes their work status. We used a checkbox pattern to allow users to select more than one option, such as employed and self‑employed. This reflects real‑world circumstances and avoids forcing users into a single category.
Handling self‑employment
If a user selects self‑employment, we ask whether they have been self‑employed for more than 12 months. This reflects policy rules that affect income thresholds for some schemes.
We were not sure if users would understand why this matters, so we tested how this question landed.
Income thresholds and approximation
Rather than asking for exact income, we ask whether the user earns at least a minimum weekly amount.
This threshold reflects the equivalent of a set number of hours at minimum wage.
Weekly figures were used because they reflect policy rules and existing guidance. We provided monthly and yearly equivalents in hint text, as users rarely think about income in weekly terms. Research in alpha had also highlighted that just providing a weekly figure increased confusion and cognitive load.
We also included an ‘I’m not sure’ option to test whether users needed a non‑binary answer. Although we were aware this may impact the accuracy of results we can provide.
We then asked a question about whether the user earns over £100,000 adjusted net income cap. We included explanation and links to calculators to support users as adjusted net income is an HMRC term that users are likely to not be familiar with.
Benefits and childcare support
We asked all users whether they receive certain benefits, regardless of work status. This avoids the service missing benefit‑based eligibility routes.
We separate questions about general benefits from questions about childcare‑specific support, such as childcare vouchers.
Partner questions
Where a user has a partner, we mirror work and income questions for the partner.
This makes household rules explicit and allowed users to see how both sets of answers affected eligibility.
We wanted to test asking about the user and their partner side by side, rather than grouping all questions about one person first.
What we learned and how we iterated
We tested question wording, ordering, hint text and explanation, including partner logic using observed user testing.
We tested with 6 participants, who were:
all women
a mix of racial and ethnic identities
self‑employed, on parental leave, or working variable hours
mostly earning between £60,000 and £90,000
including 1 participant with learning, remembering or understanding access needs
This research helped us understand where questions caused issues, and where explanation and framing reduced it.
Work status caused anxiety for some users
Users with stable employment found the paid work question straightforward. Self‑employed users and those on leave were more unsure how to answer.
Many were unclear about the timeframe the question referred to. This reinforced the need to explain how to answer in different circumstances.
We iterated the wording of this question for our next round of testing.
Thresholds worked better with explanation
The minimum earnings question caused users to pause, but hint text with monthly and yearly equivalents helped.
Users said this made the question feel answerable, even with variable income.
The ‘I’m not sure’ option was not used. However, participants on maternity leave were unsure whether to use income from before leave or projected income after returning. This highlighted parental leave as an area requiring further exploration.
Self‑employment questions lacked understanding
Some users did not understand why we asked about length of self‑employment. They guessed it related to tax or income caps.
This showed we need clearer explanation of why this information is relevant.
Adjusted net income remained complex
Most users needed time to read the explanation, but could answer once they had processed it. The link out to extra information was seen as helpful.
This reinforced the need to include a clear explanation whilst exploring explore whether the question design could be improved.
Benefits questions surfaced confusion
Users could answer benefits questions, but some were unsure what counted as childcare support.
Some confused Child Benefit with other schemes and others were confused by references to childcare vouchers.
This showed the importance of clear labels or explanation.
Providing explanations using details components
In response to feedback, we added details components to explain why we ask about:
length of self‑employment
existing childcare‑related support
These explanations aim to reduce anxiety, increase transparency, and help users understand how their answers affect results.
What we still need to learn
We still need to understand:
how best to handle Universal Credit, which is assessed at a household level
how to be inclusive of users on parental leave and with highly variable income
where we should set the boundary between what counts as an entitlement checking and application level question
Further private beta research will help us explore these problems and keep refining this part of the service.