Intelligent Redactions

As disclosure obligations grew, departments had to release more records while still protecting sensitive information. With a multidisciplinary team, I explored an AI-assisted product that could coordinate requests, find likely redactions, support human review, and keep a clear audit trail from intake to public release.

As the junior UX designer, I owned the experience from discovery through validation: customer research, requirements gathering, service flows, interface design, prototype testing, and design mobbing with engineers as the concept evolved.

Freedom of Information Act requests were rising, and departments had strict deadlines for releasing documents to journalists, citizens, and other third parties. The people doing the redaction worked under enormous pressure: one missed name, address, or officer identifier could put someone at risk, such as a person who had stepped in during an incident or an officer working undercover.

Teams relied on a mix of Laserfiche and third-party tools. The process was disjointed, error-prone, and often customized for each department. A single configuration could take hundreds of hours and stretch across weeks, and handoffs between people were hard to track.

Our design and product group ran two “How Might We” workshops with the director of product design, the product managers, and the designers on the product. The format turns a challenge into an open question, which leaves room for several solutions instead of assuming the first idea is right.

We sorted the questions into thirteen themes. They covered how to make full use of the available AI, how the interface could prevent mistakes during handoffs and public release, how the product might adapt to law enforcement, financial services, and the military, and how pricing decisions would shape the design and its goals.

That gave the team a shared map of the system and made it easier to separate what the workflow truly needed from assumptions about what the AI could do.

With other designers and Laserfiche’s industry marketing group, I interviewed police personnel about their department’s needs and the daily work of the people preparing records. Those conversations gave us perspectives we couldn’t have recreated inside the company.

Our goal was to simplify, modernize, and improve the process for police departments. No existing product solved the whole problem, so I studied adjacent public-records and redaction tools for patterns worth borrowing.

NextRequest showed reviewers document details and a log of what had been redacted, and it supported assigned tasks. Redacted.ai listed the redacted information, offered the list as a CSV download along with a final PDF, and previewed the finished document.

I mapped user flows to find the screens we would need and organized the work around four roles. Boxes are actions; diamonds are questions that can branch the path.

The requester received a records request, found the relevant documents, and handed them to a redactor. The redactor reviewed what the AI found and corrected anything it missed. A reviewer added another layer of security before the records were published, while a manager assigned and prioritized the work.

The flows exposed decision points, parallel work, and every moment ownership moved from one person to another. They became the foundation for task states, permissions, dashboards, notifications, and the information architecture.

The service flows became interface designs that engineers used to build an MVP prototype. It gave us something concrete to put in front of users before the company committed to a full implementation.

A redactor worked from a task holding duplicate copies of the documents to review. The manager or requester created and managed that task folder, and the redactor could update its status and leave comments as the work moved along.

Requesters had to search and filter across repositories for the documents that answered a public-records request. The design balanced powerful filters with a simple results view, so people could gather the right set without visiting each repository.

I used online user testing to learn what law-enforcement teams needed and to find the parts of the experience that caused confusion. The research sharpened the terminology, the responsibilities of each role, the navigation, and the relationship between automated and manual work.

Once the concept was developed, leadership moved in another direction and saved the designs for possible future implementation. The project didn’t ship, so this case study focuses on the clarity we created around the problem, the workflow, and a viable product direction, not an invented launch result.

Find the Harbor Park reports as Jen and start a redaction task. As Tom, decide on the suggestions the AI wasn’t sure about and catch the nickname it missed. Then release the records as John and watch the process close on Dana’s dashboard. It’s a clickable prototype of the flows above, the records are invented, and nothing you type leaves this page.