Design history post first published: 21 May 2024.
Context
Project development grants (PDGs) are essentially grants for new free schools.
At first we did not know who was responsible for PDG data, or what they needed it for.
We knew that there were 74 data fields about PDG in Free Schools Store (FSS).
If the incorrect information is entered into these fields, it could lead to:
- delays in schools receiving the funding they need to open
- schools receiving the wrong amount of funding
Our approach
To help us understand more, our service designer looked at SharePoint guidance about PDG. They used this to map-out PDG processes on Lucidspark and suggest a design for our product.
We learnt that the Grant Management and Finance Unit (GMFU) are responsible for managing PDGs. However, the desk research did not include the 74 PDG fields in FSS.
To minimise the risk of not creating data fields that GMFU need, we spoke with them to understand their needs and what they use FSS for.
We learnt that:
- they are responsible for filling-in the majority of FSS PDG fields
- there are lots of PDG fields that they don't need
We initially thought that regional delivery officers were responsible for entering some PDG information, but this is not their responsibility.
New design
Based on what we learnt about PDG and the FSS fields, we sketched a new design on Lucidspark for GMFU to enter PDG data.
We followed a similar approach to other pages in our product, whereby we grouped related fields into Edit pages. For example, an Edit refunds page with fields about what refunds will be made and when.
We walked through the sketch with GMFU and used it to validate our PDG assumptions and hypotheses. We then used what we learnt to iterate the sketch.
We built what we had sketched, as we had confidence in the design after speaking with GMFU users about it. This included a 'landing page' with a set of summary cards, each including a Change link.
When users click a Change link, they are taken to a specific edit page where they can enter information. Once they have entered the information, they can click a button and the information is saved and played back to them on the landing page.
We played back some of the what we felt was the most important information in a Summary section at the top of the page. The content is not exclusive to this section, but is pulled from some of the summary cards on the page.
We linked to the PDG page from the task list in our system. This would mean that regional delivery officers (DOs) could also see and edit PDG information.
In hindsight, having a PDG task in the task list felt like a risk. It could mislead DOs to think they were responsible for entering this information, which if entered incorrectly could have significant consequences.
To mitigate this risk, we added inset text alongside the PDG task list task, to emphasise that GFMU are responsible for entering PDG information.
In future, we will move the PDG link to a separate tab from the task list. This should help DOs to focus on the tasks they need to complete.
We also created a read-only version of the PDG design, that all users except GMFU can see. In this version, we removed the Change links from the summary cards.
Where there is another page level down that DOs should see, we replaced the Change link with a View details link.
GMFU see the editable version mentioned previously.
'Presumption' projects, read-only view
'Central' projects, read-only view
User research
We have tested our editable PDG design with GMFU users. They told us that:
"It's better than what I've seen on KIM [Knowledge Information Management] and how KIM is used."
"It'd be a lot easier to drop someone in who has no knowledge and then be able to use it than the store by a mile."
We also tested the read-only version with delivery officers. Overall they did not mind having a read-only version, as long as the PDG data was kept up-to-date by the appropriate people.