← Back to portfolio

Designing for Trust with AI-Assisted Filtering

Eligibility criteria in clinical trials can mean the difference between a viable drug and just noise. This feature lets biopharma researchers quickly map the landscape without spending weeks reading through raw trial data, and without writing a single line of code.

Hero visual

Decision-making data couldn't be used effectively to power strategic bets.

The problem

When eligibility criteria data from ClinicalTrials.gov was added to Table Builder, it unlocked 20,000+ trial entries that researchers had never been able to systematically search. The catch: this data was raw and unstructured. Our existing filters relied on normalized data and couldn't touch it. The only way to filter it was Lucene syntax — essentially a form of code, similar to SQL.

Our users were scientists, not coders. Many worked at large pharmaceutical companies that actively restricted AI tool usage. There was genuine skepticism about AI-generated outputs, and a heavy aversion to anything code-related. A misread of this data could cost millions. The design challenge wasn't just “make Lucene syntax accessible.” It was designing an AI feature our users would trust in an environment where getting it wrong has million-dollar consequences.

How might we

Make it feel easy for low-code users to filter raw data with complex queries.

Guiding principles

Ensure users could trust their results

Support users who were overwhelmed by coding

Be transparent and establish trust for AI-wary users

The process

Collaborating with internal scientists, engineering, and the product team, we explored potential solutions to help our non-code users feel confident filtering through this data.

  • Deeply understood the users — collaborated with engineering and scientist teams to learn the data and the problem, and sifted through hours of user calls to hear their needs firsthand.
  • Validated early ideas with engineering — a proof of concept to test internally with stakeholders, plus early prototypes to pressure-test the experience and requirements.
  • Explored multiple directions — faceted filters that build the query through the interface, options with in-line help and interactivity, and a mode offering AI through plain-language inputs.
Interactive prototype

The key insight

Initial testing with internal stakeholders proved none of these were the solution — but they illuminated what mattered most.

Early validation taught us that, above all, the user needed a single source of truth. Whether they wrote the query themselves or used the AI assist, there had to be one obvious place that reflected their search. This was essential to full transparency across their entire search.

The solution

A single input field, where users can type Lucene syntax directly or use Smart Search to generate a query from plain language.

When AI generates a query, it appears in the input field for the user to review and edit before applying — it is never applied automatically. It was essential that users always had help when they needed it, and clear feedback. I accomplished this through:

  • Syntax highlighting for immediate feedback when a query is valid
  • Placeholder copy written specifically for eligibility-criteria data, to support the user's mental model
  • Query Tips — a side panel with Lucene examples drawn from the actual data — for users who need extra help
  • Content strategy developed closely with a content designer, for a user base that reads carefully and skips nothing

The filter was later rolled out across 8 other columns of raw data.

Smart Search input
Generated query, editable

The outcome

Enabled users to filter trials based on eligibility criteria — helping them spot gaps that signal new partnership or acquisition opportunities.

HotJar session recordings showed users successfully filtering through eligibility criteria within their first session.