Many authorities keep a disclosure log, where they publish answers to previous Freedom Of Information requests. If requests are repeatedly made for the same type of information, it makes sense for the authority to publish the data regularly so that everyone can access it — because of course, the majority of FOI requests made in this country are sent directly rather than via WhatDoTheyKnow, and won’t otherwise be published online in any other form.
But a disclosure log is only useful if people know it’s there. Our FOI For Councils service, which came out of work with Hackney council increases the likelihood that the information in the disclosure log is actually seen, and by those who need it most: it automatically checks whether the request resembles any information which is already available online, then points the requester to it. If the match is correct, the user doesn’t have to progress any further with their request, and can access the information immediately. This saves everyone time — requesters and staff alike.
There’s another handy aspect to FOI for Councils, too: it can also provide staff with data on what type of requests are made the most often. As we explained in that introductory blog post:
FOI for Councils analyses the number of times each suggestion is shown, clicked, and even whether the suggestion has prevented any additional FOI requests being made.
This analysis allows Information Officers to understand which information is being asked for, that existing resources aren’t providing.
A sensible use of this is to analyse the most frequent requests and publish the data they’re asking for proactively.
Authorities don’t necessarily need FOI for Councils to do this, though: a regular analysis of internal records, or even public requests on WhatDoTheyKnow (despite only making up a proportion of requests made by any means — people may also make requests by direct email, letter, phone or even a tweet in some cases — they still provide a good sample set) would allow any authority to manually generate a broad picture.
Disclosure logs can get out of date quickly: a glance at the BBC’s, for example, seems to indicate an initial enthusiasm in 2014 which quickly dried up, perhaps because a keen employee moved on, or resources were channeled elsewhere. Yet many of the topics of information — annual transport costs for example — will quickly date and may be of interest again in subsequent years.
It makes sense for authorities to plan a publication cycle for such data, because it’s common for requests to relate to ongoing or changing information such as annual statistics or contract renewals.
It seems to be quite a widespread issue that an authority starts a disclosure log with the best of intentions, but then lets it go into disuse; additionally, the WhatDoTheyKnow team note that very few disclosure logs are comprehensive; it’s much more common for authorities to pick and choose what to release, which may not be in line with which data is most useful to the public.
Publishing frequently requested information in a proactive fashion may well cost authorities less than having to retrieve the information each time it’s asked for — and to provide the information to a sole request-maker (assuming it’s not through WhatDoTheyKnow, where the response is published online) is less efficient than simply putting it out publicly where everyone who needs it can find it. This removes some of the burden on FOI officers.
Early indicators from our work with Hackney Council show that pointing users towards material already published has prevented around 4% of the requests started by users. This should grow over time, as the council analyses popular requests and starts to add the information to their publication schedule, and more and more users will then experience this invitation to find the material elsewhere.
A legal requirement
There is one type of information which authorities are required to proactively publish, thanks to Section 19 subsection 2a of the Freedom of Information Act — datasets:
A publication scheme must, in particular, include a requirement for the public authority concerned—
(a) to publish—
(i) any dataset held by the authority in relation to which a person makes a request for information to the authority, and
(ii) any up-dated version held by the authority of such a dataset, unless the authority is satisfied that it is not appropriate for the dataset to be published
The WhatDoTheyKnow team have called for this requirement to apply to all material requested under Freedom of Information, not just datasets: it seems desirable that if a certain piece of information is frequently requested, there is a requirement to publish, unless it’s not reasonable or practical to do so (which, as the team points out, may point to a problem with the way the material is being managed internally, for example adherence to paper records that would benefit from a switch to digital).
We’re in favour
We’ve often advocated for proactive publication, including in our response to a consultation on the FOI Code of Practice last year, and we’ve even said that we’d rather people didn’t have to make FOI requests at all because all information was being published by default.
Others have made the case that there is so much data being published in the world today that it’s hard to make sense of it or to find what’s useful — but proactive publication based on proven demand like this is a good approach to ensuring that authorities are releasing what is genuinely needed.
Image: Roman Kraft
This is part II in a series of blog posts about our work with Hackney Council to conduct a discovery and prototyping project to improve the public-facing parts of information request processes. Read the first part here.
With our experience of running WhatDoTheyKnow and Alaveteli, we’re big believers in the importance of information transparency laws in our democratic system. But at the same time, we understand the operational challenges of meeting the statutory requirements of these laws for public bodies.
The challenges of dealing with information requests
While many local authorities have dedicated information governance staff whose job it is to manage requests, finding and compiling the information is often done by hard-pressed staff within services, fitting in information-related work around their core responsibilities.
Requesters sometimes have the expectation that information is all carefully organised in a few databases, ready to be aggregated and extracted at the click of a button. In reality, the degree to which information is well-organised varies a lot between services in a council and between different councils, often because of procurement decisions and departmental priorities stretching back many years.
Working with Hackney Council
We’re part way through our project with Hackney Council that Mark wrote about a few weeks ago, helping them redesign the public-facing parts of their FOI and Subject Access Request (SAR) services, so we’ve seen these challenges up close. We’ve also seen how they can be made even trickier by legacy IT systems that are no longer fit for purpose.
— Rob Miller (@RobMiller31) February 28, 2018
At our ‘show and tell’ last week with Hackney, we shared findings from some of the research we’ve done, along with early prototypes of potential new FOI and SAR submission forms, both created collaboratively with Hackney Council staff.
Prototyping with the GDS toolkit
We decided to go straight from sketches to HTML-based prototypes for this project. We thought that moving in-browser with real interactive elements would make it easier to test out some of the more complicated interactions and conditional workflow of the SAR process in particular.
Prototyping is about quickly testing hypotheses, and not getting bogged down in implementation details. So it was a pleasure to use the GDS frontend toolkit to build our prototypes. Not only did the GOV.UK toolkit help us build something relatively rich in just a few days, but it also meant we benefited from GDS’s previous work on design patterns developed for exactly this kind of context.
Using public information to reduce FOI requests
When submitting a request via WhatDoTheyKnow, users are automatically shown previously submitted requests that might answer their question, and we know that almost 10% of requesters have a look at these suggestions in more detail.
As you can see here, we took this pattern from WhatDoTheyKnow, and enhanced it further in our FOI prototype.
Now, as well as prompting with previous FOI responses from a disclosure log that we’re hoping to build, we also want to include relevant links to other topical or frequently requested information, drawn from other data sources within the council.
If we can get this to work well, we think it could have a number of benefits:
- Helping the person submitting the FOI get their answer more quickly
- Reducing the number of requests that would otherwise have been sent to the council
- Encouraging more proactive, structured publishing of data by the council.
It’s this last point which we’re really interested in, longer term. We think using a common sense technology approach to highlight possible answers to FOI requests before they are made will get people answers more quickly, reduce the burden on responders, and reinforce efforts to proactively release commonly requested data leading to real transparency benefits.
We’ve been doing usability testing of these prototypes over the last few days, and will be looking very closely at whether our assumptions here stand up to scrutiny.
Reducing back and forth around SARs
Given our background, we’re inevitably very interested in the FOI component of this project, but the Subject Access Request component is no less important. And while there’s none of the same opportunity for pre-emptively answering people’s requests, there’s plenty of scope for making the submission process a lot smoother.
A valid FOI is just a written request and some contact details, but the information needed for a SAR to be valid is much greater and more complicated. For example, along with the specifics of the request, a solicitor asking for personal information on behalf of a parent and their 16-year old child would have to provide proof of ID and address for both family members, a letter of consent from the child, and a letter of authority from the parent, confirming that the solicitor is acting for them. Even the most straightforward SAR calls for the handling of personal data and confirmation of the requestor’s identity and address.
Given all this complexity, it’s easy for there to be a lot of back and forth at the start of a SAR: clarifying a request, asking for documents, arranging receipt of documents, and so on.
We’re hoping to build something that makes it much clearer to the person making the request what they’ll need to do, thereby taking some of that responsibility off the shoulders of the team managing the requests.
The sketch above was our first crack at something that could handle (most of) this complexity, and we’ve made a number of changes since then as our understanding of it all has increased.
Recruiting representative users to test SAR submission has proved challenging and wasn’t helped by the Beast from the East rearing its snow-covered head. But we changed tack and successfully ran some guerilla testing in Hackney’s service centre last week, and we’re hoping to do further testing later in the project that has more chance of benefiting from contacts cultivated by individual services.
Changing the conversation
The conversation around information requests often focuses on the burden of responding. And although the number of information requests local authorities receive is unlikely to decrease any time soon, we’re hoping that through our collaboration with Hackney, we can make handling them a whole lot easier.
If we do it well, we think we could eliminate a lot of the process issues created by poorly-designed legacy systems, while baking in a fundamentally more open and transparent way of operating that has the potential to benefit both citizen and state alike.
If you’re responsible for managing FOI requests or data protection in your own public sector body and you’d like to follow this project in more detail—or if you’d like to participate in some of the discovery work—then please get in touch at email@example.com.
Image: Sarah Palmer-Edwards