Designing Conversational Search
End-to-End Entertainment Experience from Search to Watch at IMDb
Voice, Search, Conversation & the Moment of Watch
Amazon · IMDb
Senior UX Design Lead — Search & API · Identity & Engagement · Watch
Role
iOS · Android · Mobile Web · Fire TV · Voice (Alexa / AWS Lex)
Platform
Amazon Search · Alexa · Graphiq · Prime Video · Fire TV · IMDb Product & Engineering · Business Intelligence
Partners
Natural language search, conversational UX, voice interaction architecture, watch experience design, Universal Watchlist, identity & engagement
Scope
The Problem
IMDb had a search problem — and a completion problem. Both mattered. Only one was visible.
For years, IMDb was the default destination for entertainment questions: who directed that, when was she born, what else has he been in. The product was built for those questions and was very good at them. Then Google built the Knowledge Graph — and began surfacing basic entertainment answers directly on the search results page. Users never had to click through to IMDb.
In Q2 2016, IMDb experienced year-over-year declines in daily active users for the first time in its history. The cause was unambiguous: a 17.3% YoY drop in inbound external search traffic. Over 90% of the y/y decline was directly attributable to Google
But the deeper problem wasn't Google. It was that IMDb had optimized for a question — "Who's that actor?" — when the more valuable question, the one no one had solved, was "What should I watch tonight?"
That distinction was the organizing idea behind everything. The internal framing made it explicit: IMDb needed to shift from a reference product to a decision destination. And a decision destination has to do something a reference product doesn't — it has to get users all the way to watching.
That was the design problem. Not just search. Not just voice. The full arc: Discover → Decide → Watch.
Over 90% of y/y traffic decline was directly attributable to declining search traffic.
The Opportunity
20.1M daily searches. 5% return nothing. Answer questions Google can't. Bridge from discovery to watch.
My Role
I led UX across three Virtual Product Teams (VPTs) simultaneously: Search & API, Identity & Engagement, and Watch. Each had its own PM, engineering lead, and roadmap. Each had its own metrics it was accountable to, and each was genuinely dependent on the others.
A user who couldn't find what they were looking for wouldn't engage with watch features. A user who found something but couldn't easily get to where it was streaming would abandon. A registered user had personalization signals that made search better and recommendations more relevant. The work was deeply interconnected, which meant the design decisions in each program had to be made with the other two in view.
The Search Problem
What Natural Language Actually Required
Text search is a solved interaction problem. You type, results appear. The interface's job is to surface results quickly and rank them well.
Natural language search is different in kind, not degree. The interface has to understand intent — not just match strings. And intent is ambiguous, contextual, multi-layered, and frequently unstated.
IMDb's existing architecture couldn't handle it. Users had to pre-select a search type — Title, Name, Character, Quote, Bio — before entering a query. A user asking "Who played the lawyer in Philadelphia?" returned nothing. Not because IMDb didn't have the answer. Because the question didn't map to the search architecture.
The scale of the problem: IMDb supported 20.1 million daily searches worldwide, with 55% on mobile. Null result rate was 5% of all searches. The 2018 goal was to drive it below 1% — an 80% reduction — through natural language intent modeling and expanded index coverage.
Intent Taxonomy
An analysis of how users were already asking entertainment questions through Alexa illustrated the intent space clearly: 72.3% of questions were simple biographical queries ("How old is...?"). The remaining 27.7% were distributed across comparative questions, availability questions, recommendation requests, and multi-turn contextual follow-ups ("What else has she been in?"). IMDb couldn't answer any of them well. That was the opportunity.
Ask IMDb
The Conversational Search System
The feature we designed was called Ask IMDb — a natural language search interface appearing in the search bar and as a widget on the IMDb app home page, powered by a partnership with Alexa and Graphiq for NLP, built on ElasticSearch.
Working with the Search & API engineering team and the Alexa/Graphiq NLP teams, I mapped the full intent space for entertainment queries — from high-confidence direct questions to ambiguous exploratory requests. The intent taxonomy determined which query types the system would answer directly, which would return a blended result, and which would surface search results with a graceful acknowledgment of partial coverage.
The Voice Foundation
Parallel to Ask IMDb, I contributed to the underlying voice infrastructure that would become IMDb's Voice Assistant — built on AWS Lex for speech recognition and NLU, AWS Lambda for search handling, and ElasticSearch for the query engine.
The strategic sequencing was explicit and deliberate: deliver natural language search first, then build voice on top of that foundation. You cannot build a credible voice interface without first solving for intent at the text layer. The Alpha validated the architecture: a text-based conversational prototype capable of direct questions ("Who starred in Passengers?") and contextual follow-ups ("How old is she?"). An early proof-of-concept on the same framework — MovieBot, a conversational Alexa skill — completed 23,543 dialog turns with 1,672 unique users in its first three months.
My voice UX contribution focused on the multimodal layer: what happens when a voice query returns results on a screen. IMDb's voice experience was never audio-only. It lived across Alexa, the iOS and Android apps, and the mobile web.
The interaction design challenge
Defining how intent is expressed in audio maps to structured visual results — how the system hands back control to the user, and how it handles the specific failure modes of voice that screens can't paper over.
The Watch Problem
Where Search Ends and Decision Begins
Search answers "what." Watch answers "now what."
Those are not the same question, and most entertainment products treated them as if they were — returning results and leaving users to figure out the rest. The gap between finding a title and actually watching it was where IMDb was losing users. Closing that gap was the Watch VPT's design problem.
The 2020 Vision document the leadership team was building toward named it directly: there was no equivalent of TV Guide for the new video world. With the explosion of OTT services — Amazon, Netflix, Hulu, and dozens of others competing for attention — users weren't struggling to find content. They were struggling to decide. And IMDb, with its depth of ratings, reviews, cast data, and trust, was uniquely positioned to be the decision layer. But only if the experience got users all the way to watching, not just all the way to a result.
What the research revealed about watch decisions
A qualitative study I ran with 19 participants on the IMDb Fire TV app experience surfaced a four-part decision model that shaped the watch interaction design:
What do I feel like watching right now?
Mood
Do I want something quick and familiar, or am I ready to invest in something new?
Time
Am I watching alone, with a partner, with family?
Viewership
What can I actually watch right now, on services I have, for free?
Availability
The customer experience outcomes framework was ingested from Amazon Video and incorporated into the UXR program by UXR Lead Libby Garrett. It was the result of a year-long research effort by the Amazon Video team.
The strategic tension
The hardest constraint in the Watch work wasn't technical.
It was the misalignment between IMDb's role as a neutral entertainment authority and Amazon's commercial interests. IMDb couldn't promote OTT providers that competed with Amazon Video — which meant the "where to watch" surface was structurally incomplete. A product that couldn't tell users the full truth about where to find content risked the brand trust that made it valuable in the first place. That tension was a live design constraint, not a background condition, and every "where to watch" interaction decision had to navigate it.
Targets
The work was built to move
Goal
Baseline
Target
Change
Daily average search volume
9.7M
12.1M
+25%
Search DAU % (all platforms)
24.6%
30.7%
+25%
−80%
Null search result rate
5%
<1%
App 1-week retention
13.5%
20.0%
+650bps
Watchlist median DAUs/week
1.22MM
1.28MM
+5%
+950bps
Registered app DAUs
40.5%
50.0%
Retention as the integration metric
Search → Watch activation
Identity → Personalization → Relevance
The metric that tied all three programs (Search, Watch, and Identity) together was app 1-week retention — the proxy for whether a user found the experience valuable enough to return.
The goal was to grow it from 13.5% to 20.0%, a 650bps improvement. That wasn't a search metric or a watch metric. It was a whole-experience metric. And the retention attribution modeling the BI team built — analyzing feature engagement and frequency across 160 regression models spanning 184 features — showed clearly that features driving deep engagement (Watchlist, ratings, meaningful search results) were the ones moving retention.
The design implication was direct: depth of completion mattered more than breadth of surface area.
What This Work Was Really About
The strategic question IMDb was trying to answer in 2017–2018 was: Can a product that people trust for information become a product that people trust for decisions?
That is not a search optimization question. It's not a watch experience question. It's a question about the full arc of a user's relationship with a product — the moment a question forms, through the process of finding an answer, through the decision that answer enables, all the way to the action that decision produces.
Designing these experiences coherently — across three programs, five partner teams, two major platform partnerships, and a set of commercial constraints that were genuinely in tension with user needs — is a direct analog in my work to the design problems that AI-powered products are facing now.
The specific challenge of making a system's knowledge legible, helping users understand what the system knows and doesn't know, and building a clear path from information to action: that work is not new. It's just more urgent.
Reflection
There's a moment in every search interaction where the system has to decide whether it's done. Results appeared. Did the user get what they needed? Most interfaces don't ask. They just stop.
What this work taught me — across search, voice, and watch — is that the real interaction design challenge isn't the moment of answer. It's the moment after. What does the user do with this? Where do they go from here? Is the system still on their side?
Designing for those questions — not just the query, but the completion — is what I've been working on ever since. The platforms have changed. The underlying problem hasn't.