Using a prototype as a proof of concept for Ofsted

The current system isn’t user friendly, valuable time is being lost and users have quite low confidence in their tools

We recently worked with Ofsted on a discovery/alpha project where we designed and prototyped a new inspection management service. For us, prototyping and testing with users is a crucial step before committing to building software.

Aims of the project

Ofsted uses an inspection management system to manage all aspects of their work when inspecting schools and other institutions. The system manages all the documents and details of inspections for Ofsted staff, inspectors, and the institutions being inspected. 

The current inspection management system isn’t as user friendly as it could be. Users need extensive training on how to use it and often use workarounds to complete their tasks. Valuable time is being lost and users have quite low confidence in their tools.

Our aim was to understand the user needs each user group has for an inspection management service. We then wanted to show how those needs could be most effectively met. We did this through a mix of primary research and extensive prototyping.

Ofsted’s Initial Teacher Education (ITE) was the remit for this project. ITE inspections are for institutions that train people to become teachers. School inspections have a different structure to ITE inspections but one of our aims was to come up with concepts for an improved inspection process that could be applied to school inspections too. We started with the smaller ITE remit to learn fast and move quickly.

What we wanted to do with the prototype

After establishing user needs in discovery, we designed and developed a prototype in alpha to demonstrate how an improved service could work for users.

For every inspection, there are a number of activities that need to happen before, during, and after the inspection. Using the GOV.UK prototype kit, we built a prototype to look at the process of managing inspections from start to finish.

One of the issues we wanted to solve was building something that would be intuitive so that staff wouldn’t need training to use it. The GOV.UK prototype kit was a really useful tool for this. Especially as the Government Digital Service (GDS) have built and researched design systems and patterns that can be applied to public sector online services. This meant that we could prototype quickly by using the good work that GDS have already done.

The other aspect we focused on was reducing manual workarounds and providing greater clarity about why certain tasks need to happen. So we created a linear, task based approach which has clear status updates. We also drafted some improvements to the notifications that are sent in support of an inspection to notify users what they need to do and why they need to do it.

Designing for humans

We spoke to several people at Ofsted who do different jobs around inspections and it’s always fascinating to see how people respond to prototypes. Something that we learned a lot about during this project was the need for people in inspection teams to be able to communicate with each other synchronously and understand what activities had been done.

We also had to think about the institutions that were being inspected. How did they fit into this process and what could it look like from their perspective? One of our research findings showed that users often wanted reassurance before sending confirmation letters and emails to institutions.

By using a prototype, we could show users what we understood about how they work and the inspection process. The staff we spoke to were invaluable to this process. Thanks to their input, we built a viable prototype that can help improve the management of inspections.