How we understand the current landscape
To gain deeper insights into the existing funding statement process, the design team conducted a series of interviews with product owners and developers responsible for creating these statements.
The interviews sought to uncover the underlying reasons for the cost and complexity of the process that could inform solutions to prototype and test.
Key findings from interviews
The interviews revealed several key challenges:
- multiple teams handle funding statements with varying approaches, leading to inconsistencies
- the process involves numerous quality assurance checks, adding complexity and potential bottlenecks
- technical architecture, including legacy systems and intricate integrations, contribute to the high maintenance costs and difficulties in streamlining the process
- statements contain an overwhelming amount of data, with no clear understanding of what data users need or how they use it
- data from CFS does not follow a standard format, making it hard to create a single automated process
- data structure is basic without any clear connections, making it difficult to understand where it belongs or how it relates to the statement headings
- data structure only allows for very simple statements, it cannot calculate totals automatically or organise statements in a coherent way
- statement structure depends on instructions that change frequently and are implemented by manually coding them into the system, not by using the data itself
Essentially, the data is not well-organised or consistent, making it very difficult to automate statements. It requires a lot of manual work and is prone to errors.
Design decisions
Based on these findings, the team made several key design decisions:
Prioritise top-level information
To combat data overload, the team decided to focus on presenting only the most essential top-level information for the service users. This includes the total funding amount, issue date, funding source, main allocations, and key adjustments.
Downloadable raw data
Recognising that some users may require access to the complete dataset, the team opted to provide an option for downloading the raw data. However, they acknowledged that this data is complex and challenging to interpret for users - and the data itself may not be available.
Future iterations
The team also recognise the need to explore and document alternative formats, such as Excel or interactive dashboards, to improve data accessibility and usability in future iterations.
Next steps
The next steps involve prototyping the proposed solutions.