Sprint 4:
Our goals for this sprint were to:
- continue iterating our prototype and get a design critique from the wider DfE design community
- make progress with our technical proof of concept
- begin primary research
- run ideation spikes for calculations and contextual information
- add to and iterate our service map
Building and iterating our code-driven prototype
Now that we had a suite of components for allocation statements, we could build a code-driven prototype as an early technical proof of concept. We used the GOV.UK prototyping kit and added our components by copying example code from the GOV.UK Design System. The prototype is hosted on Azure.
We also built a minimum viable product (MVP) application programming interface (API). This serves the Calculate Funding Service (CFS) data we mapped during sprint 3 into the prototype. It also transforms the data in the prototype to make it more human-readable by following rules outlined in the API’s data translation mapping.
For testing, these rules determine how the prototype displays:
- funding stream IDs
- funding period IDs
- funding lines with an associated “fundingLineCode”
- distribution periods
- funding totals
- version and last updated data
Getting early feedback from the design community
Ahead of our first round of research, we joined a design community crit session to show them the page template and worked examples of the following adult allocation statements:
- Adult skills fund
- Advanced learner loans
- a wild card design that would use an expanding table component currently used within CFS
Their feedback was generally positive and helped us to identify some potential content iterations, including:
- more specific table headings
- use of active language in sub-headings, to align them better with the GDS content style guide
Once the adult statements were ready for testing with users, we moved on to apply the page template to a range of pre-16 allocation statements. These currently show large variations in the way they’re designed, and we wanted to see whether our template could produce something viable for testing with a second group of users.
We prototyped the following pre-16 statements:
- PE and sport premium grant
- Universal infant free school meals
- Dedicated schools grant
- 16 to 19
We also iterated the API design to ensure it would reflect any design changes we were making.
Moving into primary research
The user researchers on the team used this sprint to get ready to research our statement designs with a range of users.
In round 1, which began towards the end of this sprint, the team tested the adult allocation statements with 8 users.
We’ll be conducting round 2 of research in sprint 5.
Creating data documentation
At the same time, we began the important work of documenting the data that we’ve been working with. This sits in a data dictionary, which documents all the available content fields for published allocation statements in CFS. It includes the:
- sources
- data types
- examples
- descriptions
We’ve also mapped out all the funding lines available in CFS, including the:
- funding line type
- first and last entry for each
This has already been used by the team, to help us:
- map funding lines to grants
- find new fields which could potentially be added to the user interface
- identify grants that would be suitable for prototyping
Ideation spikes
Now we were past the mid-way point in this alpha, we also realised we were getting stuck while trying to solve too many user needs at the same time.
The problem areas were:
- explaining how amounts were arrived at, or ‘calculations’
- integrating relevant information about funding lines and the overall funding, or ‘contextual information’
- later, we identified a need for internal users to tailor data-driven statements to communicate complex allocations, or ‘customisation’
We decided to schedule a workshop for each area and called them ideation spikes. We structured each one to answer a ‘how might we’ question and used timeboxing to ensure there were prioritised ideas that could be worked into design concepts by the end of each one.
In this sprint, we worked on the ‘calculations’ and ‘contextual information’ problems. Our ‘customisation’ spike is planned for sprint 5.
To find out more, take a look at our ideation spikes design history.
Iterating our service map
Several service maps already existed in the funding service; they included high-level views of the statement preparation process and analysing data feeds. These would be valuable sources of information, but we first needed to decide:
- what do we need to understand?
- who is the map for?
- what type of map do we need right now?
See our approach to visualising our service if you’d like to know more.