Skip to main content

Progressing through alpha: putting user needs first

Posted by: , Posted on: - Categories: Data exchange

Categorising user needs

My name is Juliet Blomfield and I’m the content and communications manager for the data exchange project at the Department for Education (DfE).

The data exchange project aims to:

  • make it easier to move data from data providers into DfE and enable others to improve local data sharing
  • reduce the effort associated with validating and moving data, and allow data to move more frequently, where there is value in doing so
  • find solutions that are workable for both DfE and system suppliers to schools, colleges, local authorities and other data providers  

The alpha: getting it right

The project made great progress during discovery and early alpha stages – spending time looking at the technology available to DfE and data providers. Through this work we found that we should move data by building simple and easy-to-use APIs.

API: An application programme interface (API) is a set of commands and formatting of those commands that one programme or system sends to another. Systems connected with APIs can be given permission to talk to each other without the need for any user knowledge or intervention.

Following the initial alpha assessment in February, we’ve really focused on our users to make sure what we provide meets their needs, and is intuitive and simple to use.

Building our team

A lot has happened since I joined the project in April (including an election)! We’ve broadened our team, set up a dedicated project room and conducted research with DfE staff. After purdah (the pre-election period when government communications are restricted), we conducted research with school leaders and data administrators at a range of different schools. We wanted to find out what systems and processes they currently use, how they collect, prepare and send data to us, and where problems or pain points are.

We also met with software suppliers to find out more about how APIs might work in their systems, the effect this might have and what they’d need to make it work.

Start with user needs

To make sure we build services that are simple and intuitive, we have done a lot of user research. We have identified a number of user needs and pain points, for both schools and DfE staff, particularly around data validation, cleaning and quality.  

We found that:

  • data is not always of good enough quality when it first moves
  • collecting and validating data takes too long
  • there are inconsistencies between data in school systems and DfE systems
  • feedback and reports from data take too long to be of maximum use

In response to a need expressed by school leader:

“As a school leader, I want more timely feedback of my indicative funding amounts, so that I can budget more accurately.”

We mapped the funding data journey from school to DfE and back to school, and the pain points in the journey.

User journey mapping

And during alpha explored and developed prototypes:

  • providing a method for regular on-going data validation at the school end to help reduce the pressure on schools when data is collected
  • showing how school leaders can see their data set in context when they submit their pupil data – an indicative funding report

Testing the prototype

We’ve created an API to move relevant data (census data that is used to calculate funding) from a school’s system to the DfE automatically, as well as providing quicker validation feedback.  

To make sure our solution is right we’ve been testing our alpha prototype with schools.

Initial testing and feedback is that schools prefer automated validation, which would run overnight and produce validation reports in their system. We also tested the error messaging, making sure it’s clear, so that a user can update and correct errors at source more easily.

More testing

We completed further user testing and refined our prototypes based on feedback from our first rounds of user testing.

We also engaged with suppliers, checking that the proposed solution will work for them too. They were able to give us some helpful insight into error messaging based on their user feedback and their development plans.

What’s next?

We’ve now finished our alpha sprints and we’re preparing for the next GDS assessment. Once we have successfully passed this, we’ll hopefully get approval to move to beta development.

Most importantly we’ll continue to work with our users during beta, iterating the service we’re building to make sure we’re meeting their needs.

Watch this space!

If you want to get involved in the data exchange project or find out more about what we’re doing we’d love to hear from you:

Sharing and comments

Share this page