Using Digital Skills to Transform Access to Education Data

1. Using Digital Skills to Transform Access to Education Data Iain Bradley, Head of Data Modernisation Division Department for Education www.compare-school-performance.service.gov.uk

2. Aims • To provide a very brief overview of agile and digital, and why we used them within a statistical output context. • To share some of the benefits we found as a result of constantly developing in partnership with users. • To share lessons learnt and reflections for those involved in statistical environments.

3. Background Department for Education • England remit • 8.5m pupils • 25k schools of varying type • A ‘school led’ system Quality of school is key • Ofsted inspect schools, but not always that often • Data used by public, governors and others to hold individual schools and ‘the system’ to account as well • “Performance Tables” are the flagship vehicle for that. A big fat dissemination tool alongside traditional SFRs etc.

4. Performance Tables : My view of their history. • ‘School League tables’ have been around since the mid-1990s • Website led by same contractor from the beginning • Transparency agenda across government 2005-2010 ish. To respond quickly, Perf Tables became a place to release data above and beyond what might classically be considered ‘performance related’. • Ministers come and go. New ideas get implemented, but generally ‘on top’ of what is there already rather than instead of. • The audience evolves. From parent focussed to being both parent focussed and very knowledgeable professional users as ‘accountability’ gained momentum. • Meanwhile – the technology used became dated, the analysts’ desire to be thorough created jargon, and the way people consumed the internet went from blue bar on a big PC screen to the smartphone.

5. In other words, we had an agile, digital project. What’s all that about? My attempt at defining the loosely defined…. Digital Agile 2. Using technology to improve a user experience of doing something. 1. Taking the best bits of how people used to work, alongside the best bits of how modern tech enables us to work 3. Taken together, they involve building in small steps, and being flexible so you can iterate based on very regular cycles of testing with users

6. Digital Service Standards : The most relevant ones for the GSS Like the statistical Code of Practice, but less formal, the digital world has a ‘guide to life’, termed the Digital Service Standard. It’s 18 statements of good practice. The most relevant ones for Statisticians to think about are: • Do ongoing user research • Iterate and improve frequently • Make source code & standards open • Collect performance data

7. To begin, let’s be really clear on the problem. (Discovery) • Did DfE really know what Performance Tables are for? • What are the priorities for the future? • If DfE thinks this thing is for parents, can parents really use it? • If DfE thinksthis thing is for schools, are they using it, what for and why? • What does the market offer already – can we add value? In short, parents found the thing far too difficult to use. A 3 minute video summary of them using the old website ‘landed’ the case for change far better than any written document. Key Lessons - Discovery is about admitting you don’t know stuff. Some people don’t feel comfortable admitting that. - Don’t sit in Whitehall and make assumptions about users. Work out problems, not solutions. - Pictures speak louder than words. A video of how someone uses your product can be a powerful tool.

8. Next, let’s start building things that help you know what you really want (Alpha) • Why build web pages when posters will do to get debate going? • Test out the areas that are most risky. Human nature is to put off the difficult tasks, but tackling them early means that if you fail, you fail fast. • Ongoing user research to observe and understand behaviour • Lab testing • Visits and online sessions • “Popup” research / “Guerrilla research” • Analytics data • Stakeholder interviews • Key Lessons • Mock ups were invaluable in terms of gaining a common vision of what good looks like without wasting effort. • For us, our headache was about the different routes in and reasons for visiting that parents Vs school leaders would have. How do we design for both? (Demo).

9. Building for Real : Private Beta • In beta, we are now building the things we think are needed long term. • You can’t predict the future in politics. But you can build to ensure you can respond to it. • Keep doing research with users. You will hit problems. Our pages became too long and clunky, but we could drop in alternatives and re-test quickly. • Share with stakeholders little and often. But educating them about what they should worry about can be tricky. • Key Lessons • Ensure you are ‘in control’ of what contractors are doing. Never let them create a black box you don’t understand. • Break things down commercially. Writing cheques little and often takes sting out of decision making. Saying ‘I can close all this down within 5 days notice if ever you need me to’ helps the top of the office commit. • Not all ministers are agile experts. It might be better to show a mock up, than a product half finished. • Language / content was a key. What analysts talk about, and what users understand, are very different. Huge lessons for statistics publications!

10. Building for Real : Public Beta Q. When can we switch a new digital service on? • Agile theory... As soon as it is useful. A. Reality in our world. Ask yourself ‘what must be true for the Senior Responsible Officer to feel confident exposing this in the real world?’ For a statistical presentation tool: • One error could be catastrophic. Credibility is soon lost. • Plan for a bumpy start. Have a plan B if you need to switch this thing off. • Key Lessons • ‘Bug fixing’ is a part of the process. But we let bugs build up too much. By definition, you don’t know how long it takes to fix a bug, so they create risk. Risk appetite with stats is very very low! • Techy people see past bugs, stakeholders less so. As you reach ‘deadline day’ they make everyone nervous. • Have a day one plan down to the minute, have your contingencies worked out and lines to take if things don’t go right. • Techies and project team want a very quiet launch. Press office and SpADs like to make a huge song and dance. Strive for balance.

11. Building for Real : Live The digital philosophy is that the iterative improvement never stops. And one day you can retire it when it’s not needed. Perhaps as statisticians we can learn lessons? Have you ever dusted off last year’s SFR, updated the numbers within the text and called it a day?! How often do we ‘retire’ SFRs or really peg them back / combine with others? Do we continue to demonstrate user need?

12. Summary • Discovery is great – be confident to say ‘you know what? I simply don’t know…and if you’re honest, neither do you ;-)’ • Users usersusers. • Touching base with those you are working for little and often keeps things on track and saves wasted effort. • Where you have users of mixed knowledge / background of the sector, even those who are ‘au fait’ with the jargon appreciate clear design and plain English too.