Hackney FOI/SAR Discovery Project
January 2018
This document is intended as a brief summary of mySociety’s understanding of and approach to the
Hackney Freedom of Information (FOI) and Subject Access Request (SAR) discovery project. It outlines
the relevant background, the purpose of the project, the different research questions we will try and
answer and how we plan to approach answering them, including a proposed timeline.
Our intention is that following this first Discovery process we shall make recommendations for taking
forward aspects of our proposed solutions towards an additional Public Beta development project
before the summer.
Background
This document has been created following introductory meetings with
and
that explained how our work fits into a larger set of activities and where we can contribute
most value.
Hackney Council receives around 1,800 FOI and EIR requests per year and about 150 subject access
requests. These requests (which are distributed unevenly across the Council’s services) are of variable
quality. Some are for information that has already been published and some require back and forth
communication before it is clear what information is being sought.
Hackney Council are already working to improve the internal process of managing a FOI request and
are in the process of procuring a new piece of commercial off-the-shelf (COTS) software to support
this.
Project objective
The purpose of this discovery and prototyping project is to explore the potential to create a new
digital service for Hackney Council to help members of the public find the information they are
looking for when attempting to submit a FOI or SAR request and subsequently, when a request is
complete, have the ability to publish non-personal requests and responses.
From our discussions we are assuming that the process of creating a response is beyond the scope of
this project as the COTS solution you select will cater for this
More specifically, we should explore how the service can:
● help users to submit clear and valid requests
● integrate the submission form with other sources of information (including with a disclosure
log) to try and prevent unnecessary requests
● integrate with a new case management system to enable automatic submission of new
requests into the system, and automatic publishing to a disclosure log after a response is sent
to a requestor
● 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).
Success criteria
Together with the implementation of the system that we are scoping, this work is aiming to meet the
following success criteria.
For FOI requests, we are aiming to:
●
increase the quality of FOI requests submitted through the website
●
reduce the number of duplicate or unnecessary requests submitted through the website
For subject access requests, we are aiming to:
●
increase the quality of SARs, in particular to reduce the back and forth needed at the start of
the process to establish identity and consent.
Research questions
Organisational goals and drivers
● What do different stakeholders think the project should accomplish?
● What do different stakeholders think the drivers of this part of the FOI/SAR project are?
Request submission
● What different kinds of people are there who submit a formal request for information?
● What proportion of people start off knowing they need to submit a formal request, as opposed
to just knowing they want information?
● For those that aren’t aware of the formal processes, what language do they use and where do
they go to ask?
● Are people any good at describing what they’re looking for?
● What proportion of FOI requests are for information that is already available? Are there any
patterns to these requests?
●
Are there particular requests that are asked repeatedly?
● What other common issues are there with the quality of the initial submission and the
clarification process?
Data sources
● What other council data sources are available (registers, lists, open data portal, publication
scheme)?
● What formats are they in and can they be searched easily?
Initial allocation
● What proportion of requests arrive via each of the different available channels?
● How are requests currently allocated to services and what are the issues with this?
Current website
● How well do the current web-based submission forms perform?
● How do people find their way to the page?
● What other FOI-related pages to people read/interact with?
Technical
● Can this be SaaS? If not, where does it need to be deployed?
● What is the most effective way to reuse styles from Hackney Council’s website?
● What coding/technical/security standards will we need to comply with?
● What integration capabilities does the intended new case management system provide?
● What other services, such as Verify for SARs, might we need to integrate with?
Activities
In order to answer the questions above, we are planning to conduct the following activities, organised
into five phases.
Data review
●
Review web stats: look at available analytics on data protection / FOI pages and request
forms to understand usage, traffic sources and effectiveness of current forms.
●
Review FOI stats: look at available aggregate data on FOI requests to understand distribution
across services, common types of request, commonly repeated requests and distribution
across channels.
●
Review FOI sample: look at a representative sample of FOI requests to understand the types
of request people make, where they come from and the language they use.
●
Analysis and write-up: write a brief document summarising findings.
Interviews and observation
●
Stakeholder interviews: interviews with 3-4 key people with responsibility for or interest in
the project to understand what they think the purpose, drivers, opportunities and potential
pitfalls of the project are.
●
Workshop with IG team: a one-day workshop with the IG team to map out the process of
receiving and allocating FOI requests and SARs, what common problems they encounter in
this work, what different types of user there are and where they think the opportunities for
improvement are.
●
Champion interviews: interviews with 2-3 people who manage the FOI response process
within a service to understand how requests are received, reviewed and allocated, what
different types of user they think there are and how the submission process could be
improved.
●
Observation and interview with IG team member: 2-3 hour interview and observation with
one member of the IG team to observe how they receive, review and allocate new requests
and to ask any detailed follow-up questions following the previous interviews and workshop.
●
Master data team meeting: brief meeting with the master data team to understand what
other structured information assets Hackney Council has that could be made use of within the
service.
●
Web team meeting: an initial discussion with your web and IT teams to determine the broad
outline of hosting and web standards that may need to be followed.
●
Analysis and write-up: write up notes and findings from the interviews and meetings.
Initial design and prototyping
●
Review of other approaches: a brief review of how other councils approach FOI/SAR.
●
Design workshop: a full-day workshop with key staff from Hackney Council to review the
findings to date, present any interesting ideas of how other councils approach this problem,
and then collaboratively explore design ideas for a new submission form and possibly
disclosure log.
●
Prototyping: create a first set of prototypes building on the work done in the workshop.
●
Integration: discussions with COTS supplier for integration with case management service.
●
Presentation and iteration: present prototypes to Hackney Council staff, gather feedback
and make any necessary changes.
Testing and iteration
●
Usability testing: test prototypes with up to 6 representative users who have previously
submitted FOI requests to understand whether users can successfully interact with them and
to identify improvements in structure, design or language.
●
Revise prototypes: make changes to the prototype in light of findings from the usability
testing.
[Potentially repeat this step ^^ for a further iteration to improve prototypes and increase fidelity]
Reporting
●
Write discovery report: write a report summarising the work done, findings from the
research and presenting the prototypes and suggested next steps.
●
Presentation and discussion: meet with key staff from Hackney Council to discuss the report
and next steps.
●
Recommendations: for next steps towards a Public Beta development phase.
Indicative Timeline
●
W/B 22nd January: project kick off and data review
●
W/B 29th January: finish data review, run first workshop and start interviews
●
W/B 5th February: finish interviews and run design workshop
●
W/B 12th February: -- break for half term ? --
●
W/B 19th February: prototyping
●
W/B 26th February: testing and iteration
●
W/B 5th March: reporting
●
W/B 12th March: final presentation and report delivered
Costings
The delivery of this proposal will require 40 days at a day rate of £600 per person.
A total fixed fee of
£24,000 + VAT.
This will include;
5 days:
Initial research into existing processes, challenges and expectations
15 days:
Co-design process (user research → prototype → user research → iterate and
repeat)
10 days:
Internal integrations investigation and recommendations
5 days:
Final prototypes, documentation and recommendations
5 days:
Contingency and presentation
This process would result in clear recommendations on which tasks need to be carried out in which
order going forward and enough detail to begin a series of sprints to deliver the key
recommendations.