Zero value funding lines

Background

The prototype produced for the alpha phase of this project was designed to show users all the funding lines associated with their adult allocation statement, even when no money was due in a particular funding line. In these cases, the amount showed as ‘£0’.

User testing during alpha told us providers found these £0 funding lines confusing. They were unclear on the meaning of ‘£0’. They had multiple interpretations, including:

• they were ineligible for this funding
• they were eligible but would not receive the money in this funding period, and questioned why

The feedback from users was also contradictory. Some of our participants felt the £0 lines could be removed entirely, while others preferred to leave them in, as they felt they could be eligible in future.

We were also curious about the presence of these lines to begin with. Was the decision to include them in the live service based on previous research?

Our challenge

Before we came up with design proposals, we wanted to understand:

• what are the different scenarios where users might see £0 values, and what do they want to see in each case?
• why are £0 values currently shown in the live service? Are there business rules that govern their inclusion, and should we be following them too?
• how consistent are the calculations created in the Calculate Funding Service (CFS)? Is the structure consistent, and what can we do with it?

From a user-centred design perspective, the challenge is: how might we only display funding lines that are of interest or value to our users?

Our approach

Our first task was to get a better understanding of the data that we were pulling through to the statement. Our tech lead explained there are two types of funding line fields - information and payment fields – and both are pulled through. However, only payment fields are given a ‘funding line code’.

When we were gathering data for the alpha prototype, we came across payment fields with both ‘null’ and ‘0’ values, when they were not showing a monetary value. When designing the statement, we had transformed both the ‘null’ and ‘0’ values to show as ‘£0’, because we were not sure of the business logic behind these two values. What did they mean and when should each one be used?

Without knowing the answer to these questions, we couldn’t confidently exclude either of them from the statement in alpha, which meant users saw a larger number of £0 value funding lines than they expected or wanted.

The product owner of Manage your Education and Skills Funding (MYESF) told us that £0 values were included in live adult allocation statements because user research into other funding streams showed users were interested to see where they might be eligible for funding in future. Which echoed our findings from the alpha research.

The meanings of null and 0

To help us understand the meanings of null and 0, we spoke to the product owner of CFS. They explained the business logic that governs their use as follows:

• null is used to indicate a provider is ineligible for a funding line
• 0 is the result of an eligible funding calculation

These rules seem to be applied consistently by CFS users who work with adult funding. And the solution is easy to implement from our side; we can use code to ensure any funding lines with a ‘null’ value are hidden from view in a statement, while we show those with a ‘0’ value.

This becomes more complicated if we need to show funding lines that users could be eligible for in future. This is not currently feasible.

Analysing user needs and feasibility

To begin with, we mapped out the scenarios where a user might see a £0 result, and the technical feasibility of delivering each one. We iterated on these as we learnt more about how adult funding works and developed a better understanding of the technical constraints.

A simple decision tree diagram helped us to link scenarios to users' needs.

Initial recommendations

This enabled us to arrive at initial recommendations and confirmation that the rules we were proposing would meet user needs.

To summarise:

• null values
  • null = ineligible (both short- and long-term)
  • excludes null values from being shown
  • impact: users will not see any funds that they are ineligible for, including any that they may be eligible for in future

• 0 values
  • 0 = eligible but not granted in this allocation, perhaps due to a change in their funding
  • impact: this should not happen frequently, but we can reflect the change when needed

• process or culture changes
  • ensure the rules are followed by CFS users
  • ensure this process is fully operational before scaling it to include non-adult funding
  
  

  Extending the decision tree helps us to establish how we will meet users’ needs.

  Validating with input from other disciplines

  Next, we ran a session loosely based on the Three Amigos approach in Agile, to get feedback from non-designers in the team. This was time well spent. Input from user researchers, developers and the product owner revealed there were potentially other scenarios where:

  • a provider’s eligibility for funding changes from one year to the next
  • their eligibility changes mid-way through the year
  • scalability could become an issue (although our understanding is this applies to pre-16 funding and is therefore out of scope)

  By mapping out these new scenarios, we realised our recommendations would not cover the scenario where a funding line amount changes because of an in-year change. This line of enquiry is more complex, and we need to test it further in user research.

  Revising our rules

  To see if we could arrive at a workable rule for displaying null and 0 values in our known scenarios, we visualised them as happy and unhappy paths, using a mix of descriptions and page mock-ups.

  This helped us to focus our thinking and exclude those that would never apply to adult funding (although they might need to be revisited if data-driven statements are considered for pre-16 funding).

  Doing this also enabled us to update and simplify our logic for displaying null and 0 values.

  This sets out the rules for transforming funding values.

  It also helped us to generate questions and recommendations for other areas of the funding service, along with ideas for future product functionality.