Requests for things already public
Request volume had climbed for years and jumped after 2020. Agencies that processed a thousand requests a year were seeing three thousand, with the same staff.
Two patterns showed up in the research. Agencies had public reading rooms, but they were built to satisfy a requirement, so they worked like filing cabinets. Documents went into folders, nobody could find them, and people filed a request anyway. At some agencies 40 to 60% of requests were for documents already released.
People also did not know which agency held what they wanted, since names are similar and mandates overlap. A misrouted request still had to be processed, searched, and formally answered before it could be closed. Most people started at Google, where we had no presence at all.
Make publishing easier
The mandate was modernization. Move the legacy portal onto the new design system, better frameworks, better technical architecture, with a short list of planned improvements alongside it.
The navigation data I had been collecting said the problem was somewhere else. Requests were arriving faster than agencies could staff for, and a large share of them were never going to produce a document: misrouted to the wrong office, duplicated en masse after a news event, too vague for a processor to find anything responsive, or asking for records the agency had already released. Every one of those still had to be read, logged, searched, and formally answered before it could be closed, and they sat in the queue ahead of the requests that mattered.
Modernizing the form those requests arrived on would not change any of that.
Agencies care more about having less work than about doing the work faster. A tool that prevents 30% of requests beats one that speeds up all of them by 10%.
So I argued for a reading-room-first model: still modern, still on the new architecture, but restructured so the public lands on released documents before they land on a form. It needed development hours nobody had budgeted, which is why I built the case before I asked for them.
The assignment, and the second design
The executive team asked for a redesign: modernize the interface, make it responsive, update the components. I built that, and it would have worked.
Nobody asked for a second option. I built one anyway over about two weeks alongside the requested work, which was only possible because I prototyped it in working code with Claude instead of drawing every state. It restructured the whole experience around proactive disclosure, and I brought both designs to the same meeting.
The executive team was skeptical, which is the correct response to a designer proposing the company sell less of what it sells. What made it survivable was that the numbers underneath it were not new to anyone in the room. The duplication data had been in front of them for months by then, in the town hall, at the sales kickoff, in the biweekly report. I was not asking them to accept a finding and a proposal in the same hour.
The revenue objection
We billed on requests processed, so fewer requests sounds like less revenue. That reading is wrong in two ways, and I needed both of them in the room.
The requests this removed were mostly ones that never got processed anyway. Misrouted, unanswerably vague, or asking for something already public, they still had to be opened, logged, and formally closed, and they sat ahead of thousands of real requests agencies could be billed for. Clearing them accelerates the billable backlog instead of shrinking it.
The reading room also shipped as a paid add-on. Agencies that wanted the capability bought it, and buying it committed them to publishing, which is the behavior the whole model depends on.
The pilot handled the rest: eight agencies, six months, and a 15% floor below which we would kill the feature.
.webp)
They approved the second one.
Six layers of deflection
Each layer cut the odds that someone files a request they did not need to file.
- 01Agency finderInstead of requiring people to know which agency they needed, the flow asks what kind of information they are after and routes from there.
- 02Topic-scoped homepageThe old homepage said “submit a request.” The new one asks what you are looking for, with each topic linking into the reading room pre-filtered. Agencies can feature categories during news surges, ahead of the requests.
- 03Reading roomFull-text search across OCR’d content, Google indexing for the first time, shareable links instead of forced downloads, filtering by date and type, and preview for large PDFs.
- 04Request interceptionWhen someone describes what they want and submits, the system searches the reading room in the background and interrupts with matches before the request is filed.
- 05Simplified workflowThe old form was one long page. I broke it into steps with logic that differs for individuals, journalists, and commercial requesters, plus a quick mode for experienced users.
- 06One-click releaseOn the agency side, a single button that publishes with existing redactions, pulls metadata from the request, and enables full-text search. No downloading, no FTP, no manual tagging.
How hard to interrupt
The fourth layer was the longest argument on the project. A hard stop, where the request could not be submitted until someone had looked at the matches, would have deflected far more than what we shipped.
The question went through product, legal, and the executive team, and what settled it came out of research. I had interviewed frequent requesters at several major news organizations, and they were blunt about it: anything sitting between them and a filed request would be read as the agency protecting itself. A FOIA conference that year made the same point at higher volume and less politely. We were designing for people who already assumed obstruction.
The version we shipped interrupts once, shows what it found, and blocks nothing.
That modal took longer than the rest of the flow, because every choice inside it was small and consequential. Three to five results, not ten, since past five people stop reading and start scrolling and a scroll here looks like a wall. No confidence scores for the public, though officers see them on their side, because a percentage means something to a person who processes requests for a living and nothing to a person who wants a document.
The buttons carry the most weight. The primary action is Continue with my request, because the statutory route should never look like the discouraged one. The second button, the one we actually want, says I found what I’m looking for. That phrasing puts the outcome in the requester’s hands instead of the system’s. Nobody abandons a request in that flow. They find what they came for and stop.
The reading room
The reading room had to support browsing. Most people did not know the document they wanted, only the topic.
Testing with twelve people who had filed requests before, the pattern held: they expected search to behave like Google, and they wanted the submit button visible even when they did not need it, since a hidden one felt like the agency was hiding something.
Designing around a probability
On the agency side, the intake system flagged likely duplicates by comparing the text of a new request against everything already in the queue. It worked, which created the design problem: the model returns a score, not an answer.
A FOIA request is a statutory right. Merging two requests that only look alike means someone gets a response to a question they did not ask, and the agency is out of compliance. Automating the merge would have been easy and wrong.
The model proposes, the officer decides, and the interface makes it easier to check than to accept.
The match surfaces with its score and the overlapping language highlighted, both requests side by side. Merging and dismissing are both one click, and the default is to dismiss.
The same rule governed misrouting. When the content suggested another agency held the records, the interface said so and offered the transfer, but never moved anything on its own.
Officers trusted the flags because the flags never took anything away from them. Requests that arrived too vague to action got the same treatment, surfaced for clarification before anyone spent a week searching for records that were never specified.
The same reasoning shaped release itself, which is the one action in the product that cannot be undone. Once a record is public it is public, and a wrong redaction is a disclosure incident instead of a bug. So release is the only destructive action in the suite that does not use the standard confirmation dialog. It restates what is about to go out, in full, with the redactions rendered as the public will see them, and the confirm button stays disabled until the preview has actually been scrolled. It is deliberately slower than everything around it, and officers told us it was the first time the software felt like it understood what they were risking.
32% fewer requests
First research to eight pilot agencies took about a year. We launched in January 2024.
Month one
Volume dropped 8 to 12%, short of the 20 to 30% I had projected. The data showed why: agencies were publishing documents only after processing the requests for them, which is the opposite of the order that saves work.
I ran workshops with each agency to build release strategies from their own request history. One agency received dozens of requests a year for the same contract, so we published it preemptively. Another kept getting requests for emails from one period, so we released redacted batches ahead of demand. The change was cultural more than technical.
By month six, pilot agencies averaged a 32% reduction against the same period the prior year. Some saw 45%.
What I took from it
Build the alternative instead of pitching it
I had two weeks and a choice between writing a case for the reading-room model or prototyping it. Prototyping cost less than the three meetings it would have taken to describe the same idea, and it changed the question in the room from whether the concept was sound to whether the execution was right. I have not written a proposal for anything I could build instead since.
The rollout was the part I got wrong
I projected a 20 to 30% reduction and month one came back at 8 to 12%. The product worked. What I had not designed was the change in how agencies decided what to publish, and I spent the next two months running workshops to install a habit that should have been part of onboarding. I now treat “what has to change about how they work” as part of the design, not as adoption’s problem.