Over the last few months, we’ve been working with Hackney Council to design and make a Freedom of Information management system, imaginatively named FOI For Councils — and last time we left you with our pre-development thoughts. Well, now it’s up and running.
With this project, we had two main aims:
- first, to make the process really slick and easy to use for citizens;
- second, to reduce the quantity of FOI requests submitted, relieving some pressure on the Information Officers at the receiving end.
The solution we came up with achieves both those aims, and there’s one feature in particular that we’re super-excited about.
Case Management Integration
One of the development decisions taken early on was for the system to be a very lightweight layer, largely powered by the new Infreemation case management system that Hackney were in the process of commissioning.
Infreemation is targeted primarily at Information Officers, so there was no use in reinventing the wheel and building a heavy backend for our own FOI for Councils software.
Instead we built the FOI request process, using our experience in designing for citizens, and submitted the data directly to Infreemation using their API. This means that every request goes straight in to the case management system used by Information Officers, with no need for double entry; a set-up we’re very familiar with from our work integrating council systems with FixMyStreet.
Information Officers respond to the FOI request through Infreemation, and when they publish the response to Infreemation’s disclosure log, FOI for Councils can pull that response into its innovative suggestions engine, which we’ll discuss shortly.
All this means that Information Officers get to use the tools that are designed directly with them in mind, but citizens get the best experience possible for the process at hand, rather than trying to battle the typical generic forms offered by one-size-fits-all solutions.
On the user side of things we managed to reduce the process to a maximum of 6 screens for the entire process.
Throughout the whole user journey we ask for only three details: name; email address and then the actual request for information.
Each screen provides contextual help along the way, maximising the chances that the FOI request will be well-formed by the time it gets submitted.
Making the process intuitive for the people using it is a key factor in building citizens’ trust in an authority. Too often we see complex forms with terrible usability that almost seem designed to put people off exercising their rights.
So far, so good. But for us, the most interesting piece of the process is the suggestions step.
Before the citizen submits their request to the authority, we scan the text for keywords to see if anything matches the pool of already-published information.
If we find any matches, we show the top three to the citizen to hopefully answer their question before they submit it to the authority. This helps the citizen avoid a 20-day wait for information that they might be able to access immediately. If the suggestions don’t answer their question, the citizen can easily continue with their request.
Suggestions also benefit the authority, by reducing workload when requests can be answered by existing public information.
We’ve tried to make this suggestions step as unobtrusive as possible, while still adding value for the citizen and the authority.
The suggestions system is driven by two sources:
- Manually curated links to existing information
- The published answers to previous FOI requests
The curated links can be added to the suggestions pool by Information Officers where they spot patterns in the information most commonly requested, or perhaps in response to current events.
The intelligent part of the system though, is the automated suggestions.
As FOI for Councils integrates with the Infreemation case management system, we can feed the suggestion pool with the anonymised responses to previous requests where the authority has published them to the disclosure log.
By doing this the authority is making each FOI response work a little harder for them. Over time this automatic suggestion pool should help to reduce duplicate FOI requests.
FOI for Councils also analyses the number of times each suggestion is shown, clicked, and even whether the suggestion has prevented any additional FOI requests being made.
This allows Information Officers to see which information is being asked for, but where existing resources aren’t providing the information necessary to the citizen.
We’ll be keeping a keen eye on how this works out for Hackney, and we’ll be sure to report back with any insights.
As you’ll know if you read our first blog post from this project, we did originally envision a platform that would process Subject Access Requests as well as FOI. In the end this proved beyond the resources we had available for this phase of work.
For us, this has been a really instructive piece of work in showing how authorities can commission process-specific services that connect together to give everyone a better user experience.
As with most mySociety projects, FOI for Councils is open source which improves its transparency, flexibility and accountability.
If you’re responsible for managing FOI requests or data protection in your own public sector body and you’d like to talk about project in more detail, please get in touch at email@example.com.
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.
Catching up on the work we’re doing with @mySociety to see how we can make freedom of information and subject access requests better for users. pic.twitter.com/BbZDljBL3C
— 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 firstname.lastname@example.org.
Image: Sarah Palmer-Edwards
We’re in the process of conducting a discovery and prototyping exercise to understand how Hackney Council currently respond to FOI requests — and also Subject Access Requests (SAR) — ahead of the new General Data Protection Regulation (GDPR), coming into force in May 2018.
The aim is to explore how we can help members of the public find the information they are looking for when attempting to submit an FOI or SAR request and subsequently, when a request is complete, making it easier to publish the non-personal responses to requests through a searchable public disclosure log.
Information should be free
When someone makes a Freedom of Information request to a public body, we like to think that the information provided, often at a not insignificant cost, should be available freely to everyone, in public.
That’s the basis of our Alaveteli software which runs in at least 28 countries, and WhatDoTheyKnow in the UK which has grown to become a vast database approaching half a million FOI requests and responses over the last 10 years, from almost 19,000 public bodies.
From our own research we know that at least 15% of all FOI requests made in the UK pass through WhatDoTheyKnow, and that rises to over 30% of all requests to some central government departments. That still leaves somewhere over 70% of all requests that feasibly could be made available to the public.
What usually happens instead is that these individual requests remain hidden away in private mailboxes and probably won’t ever see the light of day.
Our FOI strategy
In response to this we’re on a mission to expand the share of FOI requests that are catalogued and released in public through WhatDoTheyKnow. This requires us to have an understanding of the nature and source of these other requests.
Broadly speaking around one third of these remaining requests are made by commercial businesses seeking contractual information from councils, NHS trusts and the like. About a fifth are from journalists researching for stories, another slice come from students or academics, and the remainder from individuals who are often making just a single request.
Our overall strategy is pretty simple: expand the scope of WhatDoTheyKnow where we can to capture more requests directly, and create new services to cater to specific user needs.
This thinking is what led to our service for journalists and campaigners, WhatDoTheyKnow Pro. (So far we’ve been reluctant to directly cater to FOI requests made by commercial businesses, although on balance it would be better if these requests did eventually make it into the public domain.)
Working with Hackney
Through WhatDoTheyKnow we’ve been pretty firmly focused on helping citizens make good FOI requests. Some readers may remember our previous forays into this area, with WhatDoTheyKnow for Councils (since retired). We found issues with that: specifically, the assumption of immediate publication in particular placed us in position as both poacher and gamekeeper, creating a conflict of interest we weren’t comfortable with.
However when we consider the full lifecycle of creating a response to an FOI request we still believe that we can use our experience of FOI to help public bodies support better drafting of initial requests and aid the management of responding to these requests.
Which brings us back to our new collaboration with Hackney.
More specifically, we are working with Hackney to explore how we can:
- help users better submit clear and valid requests
- integrate this request form with other sources of information (including with a disclosure log) to try and help users find what they need more quickly and conveniently
- integrate with case management services so that queries are answered quickly and information published openly wherever possible
- use information from previous requests to speed the allocation of a particular request to a specific council service
- support compliance with current legislation, and pre-empt forthcoming changes (GDPR).
We’re just at the beginning of this process but we’ll be blogging and sharing more updates over the next couple of months. We will also be speaking to other public sector bodies, councils in particular, about how they manage the process of responding to FOI requests, the challenges they face, and the opportunities this offers them to proactively release more publicly available data.
Hackney are a great partner to work with. As you might be already aware they have been very active in adopting user-centred, agile methods to develop new services, they are comfortable and vocal talking about their work in public (check out the HackIT blog here) and they are especially focused on bringing their staff along with them as they evolve their approach.
We’ve got a lot to learn from them, and hopefully they can benefit from some of our experience representing the needs of citizens.
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.
Update: See part 2 of this blog post here.
Image: Simon Blackley CC BY-ND 2.0