Our problem statement
As discussed in earlier design histories for this project, we’re looking at whether we can make it easier for education provider finance teams to manage their adult funding information. Currently this information is siloed and held in different formats. This results in providers having to:
- develop time-consuming processes to manage various systems
- process inconsistent data
This can lead to:
- wasted time and resources comparing their forecasted funding against what they were actually paid
- lower confidence in the accuracy of data
- providers needing more support and resources from funding service teams such as the Customer Help Portal and DfE account managers
Our starting points
The designers and user researchers in the team collated and reviewed previous research, to pull out the most relevant insights and identify any knowledge gaps.
These findings helped us to define a shared problem statement for the whole team. And draw up a short list of ‘how might we’ statements (HMWs).
These were:
- Primary HMWs
- improve consistency
- bring information together in a centralised location
- simplify the journey through payment information
- clearly show the relationship between funding streams and payments
- Secondary HMWs
- reduce the need for extra support
- ensure scalability
- improve transparency
- grow user confidence
Kicking off design
The HMWs gave us useful starting points for an ideation workshop. We wanted to use this time to explore potential design solutions by quickly visualising concepts and getting team alignment on possible solutions, before diving into detailed design.
We brought together colleagues from engineering, business analysis, research and product management as well as design, and used a crazy 8s approach to quickly generate ideas that ignored all constraints. We had found this approach worked well when we ran ideation spikes in alpha.
Several interesting themes and questions emerged from this session, including:
- approaches to information architecture and navigation
- how to visualise documents such as a payment schedule – as a download or on screen
- how to make a payment history more visible
- enabling users to make a clear link between their allocation statements and remittances
- whether the use of filters was feasible
- signposting users to historical funding information
We quickly realised we would need to watch out for scope creep, as there would not be enough time to look at all these problems in the time available.
Plugging the knowledge gaps
While the designers worked on prioritising design ideas, our user researchers were running sessions with end users to understand and map the as-is journey.
These sessions validated some of our assumptions about the high-level journey and enabled us to understand some new nuances. We could now see that:
- finance tasks are usually split across roles and therefore each role has different data needs
- those working in forecasting and planning need to see their allocation statement and payment schedule, for example to manage their yearly budget
- those managing cash flow and reconciliation activities will look at payment schedule and history data, to ensure the amounts promised are paid as expected, and want to pull this data into their own spreadsheets to check for discrepancies
- local authority finance teams do not currently receive remittance information directly (via email); bringing allocation and payment information together would benefit them too
We were now ready to begin ideation, prototyping and testing.