Developing potential ideas
To get started, we wireframed 6 of the strongest ideas generated in our ideation workshop and asked for input from non-designers in the team. Our colleagues gave us valuable feedback on:
- technical feasibility
- data availability
- user needs
- the constraints of the service that will host our built solution
Now that we had this information, we saw that we could develop 2 distinct design approaches, which we refer to as ‘hub and spoke’, and ‘all-in-one’.
Settling on a design approach
To help us choose between the 2 approaches, we took them to operations colleagues and the user-centred design community in DfE’s funding service. There was a clear preference for the ‘hub and spoke’ approach. It was felt that this offered:
- different user groups access to information at the right time for their roles
- from a technical perspective, an easier path to implementation
- a foundation to build on
In contrast, the ‘all-in-one’ approach was felt to present significant challenges when this was interpreted as ‘all on one page’. Our colleagues felt this would:
- overwhelm users and lead them to miss information
- be counter-productive as the documentation we planned to bring together is used by different finance roles
- introduce complexities when displaying data for funding streams with calculations
- increase complexity when scaling the design to work for other funding streams
Using a coded prototype to uncover user needs and behaviours
Our next step was to get our ‘hub and spoke’ approach in front of providers and understand how well it met the needs of our 2 primary user groups. Their activities can be summarised as:
- planning and forecasting funding for the year
- managing day-to-day cashflow and spend, including reconciliation
These are distinct finance roles, although there can be crossover, especially in smaller organisations.
We wanted to see if our approach worked for 2 main provider types:
- those paid on profile, which means their overall funding for the year is based on data provided in the previous academic or financial year
- those paid on actuals, whose funding is calculated monthly based on current delivery
We did this by building a coded prototype using the GOV.UK prototype kit. This enabled users to view and explore 3 important sets of data for a sample funding stream, which can appear at different times in the funding year.
From the hub page, users could navigate to their:
- allocation statement
- payment schedule (which currently forms part of the contract)
- payment history, which provides a record of payments made by DfE (this is also provided in their remittance advice documentation)
Our research objectives
We were now ready to conduct a round of research with the prototype, to help us to understand whether:
- users understand the functionality offered by the hub and spoke approach
- displaying inactive cards on the hub page causes confusion
- a CSV download would meet the needs of users who need access to the payment schedule
- our suggested approach to displaying the payment history makes it easier for users to check or reconcile amounts paid by DfE
- we are adding value overall
What users said
Users responded very positively to the new design, and told us they:
- found the ‘hub and spoke’ journeys easy to navigate
- understood where updates or changes to information had been made
A participant said:
“it looks like it’s gonna be an easier thing to navigate.”
While another added:
“I like the fact that you’ve got an original (payment schedule) and its replacement. You haven’t just overwritten one with the other. That’s better.”
Users who plan and forecast funding did feel more could be done to show information on screen, rather than having it only available in a download. As one of them said:
“you don’t always want to download information immediately; you just want to see what it looks like in the first instance.”
On the other hand, users who managed cashflow and spend found the CSV download of a payment schedule useful. A participant explained:
“seeing the amount which is going to be paid to us over the 12-month period is good. It makes my life easier as I can easily import the data into my spreadsheets. I don’t have to look for it in the contract, which contains a lot of other information.”
However, we still need to refine formatting of the CSV downloads. Participants told us they wanted:
- the payment schedule download to align with the allocation statement, by listing each funding line as a value in its own right
- the payment history download to group payments made on a monthly basis, if this is what they saw in the digital version
What happens next?
We are now using these insights to update the designs, so they form part of our first release.
They will also help to ensure we build a robust and scalable funding communications pattern, which can be used for other funding streams - and perhaps more widely in DfE.