Helping 350M+ users find something worth watching faster

SonyLIV serves 350M+ users across movies, TV shows, originals, live sports, and regional content. As the catalogue grew, so did the surface area where search could fail. A user who cannot find what they are looking for does not stay on the platform. They leave.

The business case for search improvement was straightforward: reduce the drop-off between search intent and content found. Every successful search is a session that continues. Every abandoned search is a session that ends.

Live sports content changes by the minute. Match schedules, scores, and availability shift constantly, and search results for sports needed to reflect that without the team having to manually update anything.

The existing search ranking and indexing system was not in scope for this project. Any redesign had to work with the current backend, not require a new one.

SonyLIV's user base spans a wide range of Android devices, including low-end hardware with limited processing power. Autocomplete and suggestions had to be designed to perform consistently, not just on flagships.

Users search in multiple languages and often with inconsistent spelling, partial titles, or actor names instead of show titles. The experience had to handle imperfect input without dead ends.

The catalogue includes content with inconsistent metadata quality. Some titles had rich information, others did not. The design had to degrade gracefully when metadata was thin.

I reviewed Play Store reviews filtered for search-related complaints, which gave an unfiltered picture of where users were hitting walls: spelling mistakes returning nothing, sports content invisible unless you knew the exact fixture name, and no way to recover from a failed search without starting again.

I looked at internal analytics to understand where in the search flow users were dropping off. The signal was clearest at two points: immediately after typing a query that returned weak results, and when users had to choose between many similarly-presented results with no visual differentiation.

I benchmarked against Netflix, Prime Video, Hotstar, and YouTube to understand how the market was handling the same tensions between retrieval and discovery. The consistent pattern in the stronger experiences was that they treated search as the start of a conversation, not a one-shot lookup.

I also spoke with the customer support team about the most common search-related tickets, which surfaced a category I had not prioritised initially: repeat searches. A meaningful portion of users searched for the same content across multiple sessions, which pointed to a simple fix with high return.

I went into this project assuming the core problem was relevance: the algorithm was surfacing the wrong results, and improving ranking would fix search.

The research contradicted that. Users were not failing because results were irrelevant. They were failing before they got to results at all. Partial titles returned nothing. A misspelling killed the query. Users who did not know a title had no way to browse toward what they wanted.

The problem was not that search was finding the wrong things. It was that search required users to already know what they were looking for. That shifted the entire brief from improving retrieval to enabling discovery.

The most significant shift was in how I understood the problem. I started the project expecting to improve search relevance. The research showed that relevance was not where users were failing.

Users were failing before they got to results at all. The barrier was not that results were wrong, it was that the experience required users to already know exactly what they were looking for. A partial title returned nothing. A misspelling killed the query. That is not a ranking problem. That is a design problem.

Reframing the brief from improving retrieval to enabling discovery changed almost every decision that followed. Autocomplete, suggestions, rich results, and the empty state were all consequences of that single shift in understanding.

The patterns that came out of this project, forgiving input handling, visual recognition over text reading, surfacing context before the user asks for it, are not specific to the search screen.

The same principles apply to any content discovery surface on SonyLIV: the home screen, category pages, and recommendation surfaces. Framing search as a discovery tool rather than a retrieval tool opened up a way of thinking about the whole product that the team carried forward.

The most useful thing this project taught me was to question what problem I was actually solving before designing anything. My initial diagnosis was wrong. The research corrected it. That correction was worth more than any individual design decision that followed.

If I were doing this again, I would involve the engineering team in the constraints conversation earlier. Understanding the limits of what the backend could surface in real time would have let me scope the autocomplete work more accurately from the start, rather than discovering some constraints mid-exploration.

I would also have pushed harder to instrument the search flow before starting design work, so that post-launch we had a clear baseline to measure against. The absence of pre-redesign benchmarks made it harder to quantify exactly what changed.