Sprint 3

Sprint 3:

We set ourselves the following goals for this sprint:

• make progress with our ideation and journey mapping plans
• gather our desk research into a deck that could be used to inform future design
• engage with Operational Excellence colleagues or other subject matter experts (SMEs) to gain insights into funding calculations

We also made time for a mid-alpha checkpoint, to:

• review what we’d learned about our problem statement, hypotheses and riskiest assumptions
• re-prioritise the tasks for each discipline in the team, to ensure we met our project goals

Expanding our technical knowledge to build a proof of concept

In this sprint we could finally start building a prototype that was automatically populated with adult funding data from the Calculate Funding Service (CFS), delivered via an application programming interface (API).

To begin with, we established close working relationships with the product owners of CFS and Manage your Education and Skills Funding (MYESF), our new SMEs. Together with other senior stakeholders, they made it possible for us to:

• access the data sets we needed to power our prototype
• do deep dives into the data, to get a better understanding of where they were located and how they were structured
• take a much closer look at calculation data, although this did tell us it would be more complex to include them in our early prototypes
• start to build the API and get feedback from technical stakeholders and SMEs

Desk research helped the team make significant progress

User-centred design (UCD) teams in service delivery have conducted research with providers on many occasions over the last 7 years, including the previous funding communications alpha in 2024. It made sense to pull together our insights across all this work, to:

• provide our team with a consolidated set of known user needs and user stories
• make it easier to map these insights to our hypotheses
• support design and ideation
• ensure we’re not repeating work that’s already been done

This desk research helped the team to identify gaps and understand technical constraints as we iterated our lo-fi designs. It also helped us to build a focused plan for upcoming research with users in sprint 4.

Scoping and delivering our first prototype

We initially expected to design six different adult grant funding statements, but our SMEs soon clarified there are only 4 in this space, and 2 of them are likely (but not guaranteed) to be decommissioned soon. That meant our early design thinking only needed to consider the following:

• Adult skills fund
• Adult learner loans

However, we decided to include all 4 possibilities in our thinking and research for now, to reduce the likelihood of coming up with design solutions that were too narrow in scope.

As we were trying to design a template that could be used to display a range of adult grant funding statements, it made sense to take a component-based approach.

We collected component examples in Lucid for ease of reference.

Our possible component sources were:

• current live designs
• newer designs in the MYESF prototype, which implemented the design and accessibility recommendations delivered by a design review team in 2024

We decided to use the latter, as we knew the designs were optimised for usability and more closely aligned with the latest business thinking.

Next, we looked at whether we’d need to design a range of template variants to reflect statement updates and other changes. This turned out to be less of an issue than we expected, as the changes are usually quite small.

We’ve noted that some complex funding streams use a tabbed interface or service pattern to present the data. We aren’t including this in our proof of concept, but we will come back to it later.

Once we’d finalised our components set, we checked that the data needed to populate them were available in CFS. In doing this we realised that a lot of the CFS data are not ‘human-readable’ – they weren’t designed for this purpose – so that told us we would need to:

• come up with automation rules to make the data more readable
• create an API that will help with data transformations
• identify recommendations for upstream changes in the data such as naming conventions

Once we had our templates and a way to feed them with data, we were ready to mock up a couple of adult allocation statements. Many of the components were straightforward to work with, but we had to work hard to make the table component technically feasible. We learned we needed 2 table variants, one to show a summary view, and the other a line-by-line breakdown.

Data-driven adult allocation statements can be produced with a limited number of components and data values.

We also revisited the information architecture and came up with content for table headings that will adapt and still make sense when conditional logic is applied to the data.

Checking in with our problem statement, assumptions and hypotheses

During an alpha it’s important to keep referring to what we’re trying to do, because we’re learning so much as we are doing the work. So, we made time at the start of this sprint to read back through our inception outputs and map our learnings for each hypothesis against what we thought we knew at the beginning.

We wanted specifically to see if there were any gaps that we needed to investigate for the rest of the alpha.

We found that the two sides of our initial problem statement – reducing the effort to produce funding statements vs. improving providers’ experience of funding communications – can’t be worked on by us at the same time. They needed to be addressed separately.

Both problems can be tackled over time, but we have to prioritise one in this alpha. We decided that our focus would be to reduce the effort required.

We already knew CFS did not have all the information needed to create the latest adult allocation statement designs. This meant it was going to be challenging to meet the following user needs:

• displaying funding calculations
• providing contextual information such as guidance
• giving users a customised view of their funding

To help us make the best use of limited time, we decided to organise a series of half-day workshops in the next sprint, one for each of the problematic user needs. We’re calling the workshops ideation spikes; a design history will have more details.

We’ve also begun work on a service journey map. This will help us locate allocation statements and other funding communications in the end-to-end journey and identify areas where we need to know more.