Requests for things already public
Request volume had climbed for years and jumped after 2020. Agencies that had processed a thousand requests a year were receiving three thousand, with the same staff.
Agencies had public reading rooms, but they had been built to satisfy a requirement and worked like filing cabinets. Documents went into folders where nobody could find them, and people filed requests for records that had already been released. At some agencies 40 to 60% of requests were of that kind.
People also did not know which agency held what they wanted, because agency names are similar and their mandates overlap. Most people began their search at Google, and none of the released documents could be found there. Some requesters, journalists especially, had come to believe that agencies were hiding records that were in fact public and only hard to find.
The assignment
I was to move the legacy portal onto the new design system and a newer technical architecture, make it responsive, and add a short list of planned improvements. The system had been made for case processors, so I added to it for the public, among other things a tile button with a large touch target that makes the next step plain.
The data I had been collecting showed which incoming requests would never produce a document: those sent to the wrong office, duplicated many times over after a news event, written too vaguely to search on, or asking for records the agency had already released. Each one still had to be read, logged, searched, and formally answered, and it sat in the queue ahead of requests that would produce records.
A second design
After finishing the requested redesign I built a second version, organized around the reading room so that a visitor would reach the published documents before the request form. I had been working out in the design system how search should behave across our products, with results on the screen before any filter is chosen, and I came to treat a request as a search. A requester wants documents that an agency holds. The request form is the set of questions that stands before the results, and the searching is done by people. A portal that prevented 30% of requests would be worth more to an agency than one that sped up every request by 10%.
I drew it first, then spent about two weeks building it as a prototype in code with Claude. I started as a front-end developer, so I could read what it produced and make corrections, and working code let people use the design. The second design changed the architecture as much as the screens, so as I worked I checked it with my closest partner in engineering, who told me how to keep it within the realm of the possible. I brought both versions to the same review.
The executive team had already seen the figures, at the company town hall and at the sales kickoff in the months before, and the review could be spent on the design. The CTO, my partner’s manager, asked a lot of questions, and the work we had done together meant I could answer them. He became one of the design’s strongest supporters.
The objection was that a portal that reduces requests reduces the work our product is bought to handle. I had worked through that with revenue operations before the review. The requests this design would remove were mostly ones that produced nothing. The reading room would also be sold as an add-on, and an agency that bought it would have committed to publishing, which the design depends on. The executive team approved the second design for a six-month pilot with eight agencies, and we agreed on a floor: if requests had fallen by less than 15% at the end, the feature would be dropped.
The design
An agency finder asks what kind of information a person is after and routes them to the office that holds it, so nobody has to know an agency’s name in advance.
The home page, which used to say “submit a request,” asks what the visitor is looking for, and each topic links into the reading room already filtered. An agency can feature a category during a news surge, ahead of the requests.
The reading room had to support browsing, because most people knew the topic they wanted and not the document. It has full-text search across OCR’d documents, filters for date and type, and previews for large PDFs. Every released record has its own address, which put the records on Google for the first time and lets one requester send a document to another.
In moderated tests, twelve people who had filed requests before expected the search to behave like Google. They also wanted the submit button visible even when they did not need it, because a hidden one felt like the agency was hiding something.
The request form, which had been one long page, became a sequence of steps that differs for individuals, journalists, and commercial requesters, with a shorter path for people who file often. When someone describes what they want and submits, the system searches the reading room and shows any matches before the request is filed.
How hard to interrupt
We argued over that interruption longer than over anything else on the project. A hard stop, where a request could not be submitted until the person had looked at the matches, would have deflected more requests than the version we shipped, but it would have stood between a person and a statutory right.
I interviewed frequent requesters, several of them at major news organizations. They took the portal for an extension of the agency, and said that anything placed between them and a filed request would be read as the agency protecting itself.
The version we shipped interrupts once, shows what it found, and blocks nothing. It lists three to five results, because people stop reading after five. It shows no confidence score to the public, though officers see one on their side, because a percentage is useful to someone who processes requests for a living and means little to someone who wants a document. Each result shows the words it matched and opens in the reading room in a new tab, leaving the request where it was. The primary button reads Continue with my request, so that the statutory route never looks like the discouraged one.
On the agency side, releasing a document became a single action. It publishes the record with its existing redactions, takes the metadata from the request, and makes the text searchable, with no download, FTP upload, or manual tagging.
Designing around a probability
The intake system flags likely duplicates by comparing the text of a new request with everything already in the queue, and returns a score. If two requests that only look alike are merged, someone receives an answer to a question they did not ask, and the agency is out of compliance.
The officer decides
I left the merge to the officer, though automating it would have been simpler to build. The flag is the interruption from the request form, by then a pattern in the design system and used here for officers. A match appears with its score, the overlapping language highlighted, and both requests side by side. Merging it or ignoring it takes one click and can be undone, and the queue moves on to the next request.
When the content of a request suggests that another agency holds the records, the interface says so and offers the transfer, and it never moves a request on its own. Requests too vague to act on are raised for clarification before anyone spends a week searching.
Release is the one action that cannot be undone, and a wrong redaction is a disclosure incident, so it does not use the standard confirmation dialog. It shows everything that is about to be published, with the redactions rendered as the public will see them, and the confirm button stays disabled until the preview has been scrolled through. After the click the release is held for a few seconds, as a sent email is, and the officer can cancel it before the record goes out.
Between satisfying and silly
FOIA software has a reputation for being boring, and it does not have to be. Once the work an officer had to do was clear, I wanted it to be satisfying to complete. Closing a request ends with an animated checkmark. Each way of resolving one in the intake queue has an animation of its own, such as a transfer when the officer sends it to the office the system has flagged. Small actions, like completing a step or a form, got minor improvements.
We spent the time on the new features, which we needed people to have positive associations with, and on release. Posting a document to the public portal had to be easy and feel good, because the design depends on agencies publishing. This is a serious government system with serious people using it, so the motion confirms an action and stops short of celebrating it. Scores on our UX-Lite survey rose 10 to 20% after the animations shipped.
Results
We launched to the eight pilot agencies in January 2024, about a year after the research began. In the first month request volume fell 8 to 12%, against the 20 to 30% I had projected. Agencies were publishing documents only after they had processed the requests for them.
I ran workshops with each pilot agency and built a release plan from its own request history. One agency received dozens of requests a year for the same contract, and published it ahead of the next one. Another kept getting requests for emails from a single period, and released redacted batches before the requests arrived. By the sixth month the pilot agencies averaged 32% fewer requests than in the same period a year earlier, and some reached 45%.
What I learned
Identify what matters and let it shine
The portal had been built around the request form, and I put the released records ahead of it. The requests this would remove were mostly ones that never produced a document. Processing them was work our product is sold to do, so I went through the cost with revenue operations before the review.
Positive conflict is essential
The executive team objected, then approved a pilot with a floor we agreed on: if requests fell by less than 15%, the feature would be dropped. We argued longest over how hard to interrupt a requester, and shipped the version that blocks nothing.
Build the thing and learn from how it performs
The request data was enough to tell me that putting the reading room ahead of the request form would reduce volume. The first month of the pilot showed that agencies had no routine for publishing a record before people asked for it. I had left that to onboarding, and would now design it along with the product.