Redesigning a Public Portal to Reduce Request Volume 32%

The Problem: Drowning in Duplicate Requests

FOIA request volume had been climbing for years, and after 2020 it exploded — agencies that processed a thousand requests annually were seeing three thousand, staff levels stayed flat, and FOIA officers were drowning. Through my research with agencies Building a Strategic Design Function, I noticed two systemic problems:

Documents Already Released but Impossible to Find

Many requests were for documents already released to someone else. Agencies had "reading rooms" where they posted frequently requested documents, but nobody used them well, and when I pulled the data I found that 40-60% of requests at some agencies were for documents already available.

Requests Routed to Wrong Agencies

The public often didn't know which agency held the records they wanted — similar names, overlapping responsibilities — and when an agency received a request for records they didn't hold, they couldn't close it immediately but had to process it, determine they didn't have the records, and respond formally, wasting time that could have been spent on legitimate requests. Users knew what information they wanted, not who held it, and the old system assumed people would arrive from an agency's website when in fact many started at Google, where we weren't helping them find the right agency.

FOIA request volume trends: 90% increase since 2020, plus misrouting waste

The Hypothesis: Make Publishing Easier, Not Requesting Harder

We had a chance to rebuild our public FOIA portal from scratch — the old system was built in the early 2000s — and the easy path was to recreate what we had with modern components and call it done. I saw a different opportunity: what if we made it easier to not submit requests?

If we made proactive release easier for agencies and directed the public to search released documents first, we could help the public get information faster (immediately, rather than waiting the 20-90 day FOIA response window), help agencies reduce request volume by 10-30%, and differentiate our product in a market where every competitor was optimizing the same request-processing workflow.

This felt counterintuitive because our business model was per-user licensing based on request volume, and reducing requests could reduce revenue. But the logic was sound: agencies would pay more for a tool that reduced their workload than one that just managed it, and if we could prove a 20-30% reduction, we'd have a competitive advantage nobody else could match.

The Assignment vs. The Opportunity

The executive team asked for a redesign of our public FOIA portal. The directive was clear: modernize the interface, make it mobile-friendly, update the components. A safe, incremental improvement.

I delivered what they asked for — clean interface, modern components, responsive design, something that would have worked fine — but I also saw a bigger opportunity, one that required strategic risk-taking.

The Secret Second Design

On my own time, I designed a second approach that instead of just modernizing request submission, redesigned the entire experience around proactive disclosure with a search-first interface, topic-based navigation, and multiple request deflection strategies. This wasn't what they asked for — it was riskier, more ambitious, and challenged our business model — but the data showed it could reduce agency workload by 20-30%, and agencies would pay more for that.

The Presentation

I walked into the executive meeting with both designs ready. First, I showed them what they asked for: "Here's the safe redesign — it modernizes the interface, makes it mobile-friendly, fixes the obvious problems, and it would work." Then I showed them the alternative: "And here's what we could do instead. It's riskier, it challenges our business model, but if the data is right, this could reduce request volume 20-30%, and agencies would pay more for a tool that reduces their workload than one that just manages it."

The choice: Safe redesign (left) vs. innovative proactive disclosure strategy (right)

I showed them data proving 40-60% of requests were duplicates, research showing agencies care more about preventing work than processing it faster, mockups of the search-first interface and proactive release tools, and a pilot plan with a 15% reduction threshold. The side-by-side comparison made the case: the safe design was fine, but the innovative design solved a bigger problem, and they approved it.

The Design: Three Layers of Request Deflection

The redesign wasn't just a search bar bolted onto the old portal. I redesigned the entire information architecture with strategic interventions at different touchpoints, each one reducing the likelihood that someone would submit a request they didn't need to submit.

Layer 1: Agency Finder (Solving Misrouting)

For people arriving at the top-level portal, I designed an "agency finder" flow. Instead of forcing people to know which agency they needed, I asked: "What kind of information are you looking for?" The system presented topic categories — contracts, personnel records, environmental data, law enforcement — and guided users to the appropriate agency, solving misrouting and letting us scope the experience intelligently.

Agency finder: topic-first navigation replacing agency-first navigation

Layer 2: Topic-Scoped Homepage (Strategic Guidance)

Once someone arrived at an agency's portal, the old design showed: "Click here to submit a request," reinforcing that FOIA was about submitting requests, not finding information. I redesigned the homepage to ask "What kind of information are you looking for?" with each topic linking directly to the reading room, pre-filtered to relevant documents. I also added the ability to feature categories of public importance — agencies get surges when things happen in the news, and we could surface those documents before requests came in.

Homepage redesign: de-emphasizing request submission, emphasizing information discovery

Layer 3: Reading Room as Discovery Engine

The reading room needed to support browsing, not just searching, so I added full-text search across OCR'd content, Google indexing (making documents discoverable via Google for the first time), shareable links instead of forced downloads, contextual recommendations based on topic similarity, rich filtering by date and topic and document type, and preview capability for large PDFs.

Reading room designed for browsing and discovery, not just compliance

Working with the product manager, we prioritized features based on pilot analytics. When usage data showed people abandoning multi-step filters, I redesigned to surface popular categories upfront — a change the PM fast-tracked based on data.

Layer 4: Intelligent Request Interception

Even with these improvements, some people would go straight to the request form. One final intervention: when someone types a description and hits submit, the system searches the reading room in the background, and if it finds matching documents, it interrupts with "We found some released documents that seem to match what you're looking for. Do you want to check them out first?" The user sees three to five relevant documents with preview and can either find what they need or continue submitting.

Intelligent interception: suggesting released documents before request submission

Layer 5: Simplified Request Workflow

For people who still needed to submit, I fixed the form. The old system was one long intimidating page with everything visible at once, creating cognitive overload. I broke it into wizard steps — What kind of records? Tell us about yourself. Describe what you need. Review and submit. — with different logic for individuals, journalists, and commercial requesters, and contextual help based on previous answers. This progressive disclosure reduced cognitive load on each screen, showed conditional logic only when relevant, and educated requesters about FOIA as they progressed. For frequent requesters like journalists, I kept a "Quick Request" mode that showed the full form for experienced users.

Wizard workflow with progressive disclosure and quick mode for power users

Layer 6: Friction-Free Proactive Release (Agency Side)

All of this required agencies to actually release documents, which I made trivial with one button in FOIAXpress that says "Release to Public Portal" — the document uses existing redactions, extracts metadata from the FOIA request, publishes with full-text search enabled, and notifies stakeholders, all with no downloading, no FTP, no manual metadata entry, just one click.

Testing with FOIA Officers and Public Users

I tested with two groups: FOIA officers who would use proactive release, and members of the public who would search and submit.

Testing with FOIA Officers

I ran moderated sessions with six agencies, showing them the one-click release flow, which they loved. But I uncovered three concerns that shaped the final design: agencies worried about accidentally releasing something that shouldn't be public, so I added a confirmation dialog showing exactly what would be released and required second approval for sensitive topics; leadership at some agencies wouldn't allow release without approval, so I added an optional approval workflow that could be enabled per agency; and officers needed to track what they'd released for their annual reports, so I added a report export showing all proactive releases by date, topic, and requester type.

Testing with the Public

I recruited twelve people who had submitted FOIA requests before and asked them to find specific documents using the search interface. People expected search to work like Google — full-text, natural language — not like government websites with exact filename matching. The "submit a request" button needed to be visible, not hidden, because people got frustrated when they couldn't find it even if they didn't need it. And preview capability turned out to be critical: people wanted to confirm they found the right document before downloading a 200-page PDF. I iterated on the design, making search more prominent and improving the filter interface based on this feedback.

Document viewer in reading room with preview and download capabilities

Results: 32% Reduction in Request Volume

We launched with a pilot group of eight agencies in January 2024. I worked closely with each one to train their FOIA officers on the new proactive release workflow and helped them strategize which documents to release first.

The First Month

Results were promising but modest — agencies were releasing documents and the public was finding them, but request volume dropped only 8-12%, well short of the 20-30% I had projected. I dug into the data and found the problem: agencies were releasing documents only after they processed FOIA requests, not proactively releasing documents that might be requested in the future. They were using the feature reactively, not proactively.

The Strategic Shift

I ran workshops with each pilot agency to help them develop proactive release strategies. We looked at their most common request topics and identified documents they could release preemptively — one agency got dozens of requests every year for the same contract, so we released it proactively and posted it on their main website; another got repeated requests for emails from a specific time period, so we worked with them to release redacted email batches. This required convincing agencies to change their mindset from "we'll release it if someone asks" to "we'll release it before they ask," which was as much a cultural shift as a product one.

The Results

By month six, pilot agencies saw an average 32% reduction in FOIA request volume compared to the same period the previous year, with some agencies seeing drops as high as 45%.

The analytics dashboard showed 8,000 searches per month across pilot agencies, 4,200 document downloads, and an estimated 850 FOIA requests avoided based on search-to-download conversion.

Request deflection strategy: Portal self-service + intelligent intake routing reduced volume and accelerated closures

Beyond Deflection: Intelligent Request Routing

The sankey diagram shows two sources of request reduction: portal deflection (people finding information themselves) and intelligent intake routing (helping agencies close requests faster). Reducing inbound volume was crucial, but equally important was helping agencies clear their backlog — the number one thing that mattered to our customers wasn't fewer requests alone but getting to done faster.

I designed an intelligent intake and triage system that identified four common closure opportunities at the point of intake:

Intelligent intake system analyzing requests for quick-close opportunities

When a new request arrived, the system analyzed existing requests using text similarity algorithms and, if it found a likely duplicate, flagged the match and suggested merging.

Duplicate detection: ML-powered similarity analysis identified potential duplicates at intake

The system also analyzed request content and recipient agency to identify requests sent to the wrong agency, so that instead of processing a request they couldn't fulfill, agencies could quickly route it to the correct destination.

Misrouting prevention: System identified requests likely sent to wrong agency

Beyond exact duplicates, the system identified similar requests that could be processed together, reducing redundant research and document collection. And requests that lacked necessary specificity were flagged immediately, allowing agencies to request clarification before starting the search.

These features addressed the reality of FOIA work: agencies weren't drowning in legitimate requests so much as in processing overhead. By helping them identify quick wins at intake, we reduced time to closure and freed up capacity for substantive requests. The combination of portal deflection and intelligent routing created a complete backlog reduction strategy — not just fewer requests coming in, but faster resolution of the ones that did.

Key Lessons

Counterintuitive Solutions Require Extra Selling

The idea of reducing request volume felt wrong to stakeholders — it seemed like we were working against our business model. I had to reframe it as "increasing customer value per seat" rather than "reducing activity," and while data helped, the side-by-side comparison of the two designs is what finally made the case.

Behavior Change Is Harder Than Feature Adoption

The feature was easy to use, but getting agencies to think proactively required workshops, training, and ongoing support. The best-designed feature in the world won't work if users don't change how they approach the problem it solves.

Dual Stakeholder Design Is Complex but Rewarding

I had to design for two very different users — FOIA officers who wanted to reduce work and members of the public who wanted information. Their needs aligned, but their contexts were fundamentally different, and testing with both groups was essential to getting the experience right for either.

Prove Value Early and Often

The analytics dashboard was as important as the portal itself. It gave FOIA officers ammunition to advocate internally and gave me data to prove the concept worked. Without it, adoption would have been much slower.

What I'd Do Differently

I would have built the strategic workshops into the product from day one. Instead of launching the feature and then training agencies on proactive strategies, I should have made "proactive release planning" part of the onboarding flow. The feature worked, but agencies needed help thinking differently about their job, and that help should have been built in rather than bolted on.