Multi-Language Trailers
Unlocking Video Engagement at BookMyShow
Role
Business Context
More movies were releasing in multiple languages, and production houses were supplying BookMyShow with a steady daily inventory of trailers, teasers, songs, and dialogue promos for each one. But the synopsis page could only show a single trailer in a single language. Customers who didn't speak the primary language listed couldn't watch a trailer on BookMyShow at all — they had to leave for another platform to do it. The business was sitting on video inventory it already had rights to and simply wasn't surfacing.
Strategic Decision
**Redesign the Widget vs. Redesign the Page**
Context: solving multi-language trailers properly could have meant rethinking the synopsis page's layout to make room for a dedicated video section.
Options: (1) redesign the broader synopsis page to carve out more space for video, or (2) constrain the solution to the existing trailer widget's footprint and solve it through interaction design instead of layout.
Trade-off: redesigning the page could unlock more room long-term, but it meant a bigger, slower project riding on a page redesign that wasn't otherwise scheduled. Working within the existing widget was faster to ship but harder — it meant solving multi-language, multi-count video browsing in a single, already-small space.
Decision: work within the existing widget's footprint first, and treat a fuller video library as a later phase once the new synopsis page shipped anyway.
Why: the video inventory problem was urgent and the fix didn't need to wait on an unscheduled page redesign. Sequencing it this way delivered the core value (users can actually watch the trailer in their language) fast, while leaving room for a proper video library once the synopsis page was redesigned for other reasons.
Design Principles
1. **Solve Within the Space You Have** — the fix had to work inside the existing widget footprint, not require a page redesign to ship.
2. **Every Option Gets Prototyped, Not Argued** — two genuinely different interaction models were built and evaluated before choosing a direction.
3. **Script Discipline in Language Labels** — never render an entire label in a foreign script; pair a native-script letter with the English language name so it stays legible to people who can't read that script.
4. **Design for Reuse** — the eventual gallery component was built to be dropped into other parts of the app, not just the synopsis page.
Key Product Decisions
**1. Choosing the trailer-switching interaction**
Problem: fit multi-language, multi-video browsing into the existing single-trailer widget slot.
Options explored: Option A, a stacked-card UI where each card had a language-switching overlay (visually distinctive but not intuitive or direct); Option B, straightforward language filter chips overlaid on the video (one click fewer than A, but gave no sense of how many videos were in the queue).
Decision: neither A nor B alone — merge them into a third option.
Solution: a standard carousel video widget with a visible video count and language filter chips, combining Option B's directness with a queue indicator Option A and B both lacked individually.
Business impact: shipped a solution that tested as more intuitive than either original option, inside the same widget footprint the team started with.
**2. Script handling for language labels**
Problem: labeling trailers by language script (rendering "Hindi" in Devanagari, for example) made the label unreadable to users who couldn't read that script.
Options explored: render the full language name in its native script, vs. pair a single native-script letter with the language name spelled in English.
Decision: native-script letter plus English name.
Solution: language filter chips used a recognizable native-script initial alongside the English language name, so the label stayed legible regardless of which scripts a given user could read.
Business impact: avoided a language-selection UI that would have excluded the very users it was meant to serve.
**3. Evolving into a reusable video gallery**
Problem: the widget-constrained solution met the immediate goal, but the actual ambition was a full video library experience, which the original widget footprint couldn't support.
Options explored: stop at the widget-level fix, vs. build a fuller gallery mode once the synopsis page itself was being redesigned.
Decision: build the fuller gallery as a follow-on phase tied to the new synopsis page.
Solution: a dedicated video gallery mode, grouping all available videos by language, built as a reusable component intended for use elsewhere in the app, not just this one page.
Business impact: turned a single-page fix into a reusable pattern the business could apply anywhere it had multi-language video inventory.
Outcomes
**Business:** recovered engagement value from video inventory BookMyShow already had rights to but wasn't surfacing, reducing the number of users who left the app to watch trailers on other platforms.
**Customer:** users could now watch a movie's trailer in their own language directly on BookMyShow, without switching platforms.
**Operations:** the shipped solution fit inside the existing widget footprint, avoiding a dependency on an unscheduled page redesign to deliver value.
**Engineering:** the eventual gallery mode was built as a reusable component intended for reuse elsewhere in the app.
**Support:** no support-specific data was available for this feature.
Reflection
The biggest surprise was that neither of our two first options was the right answer — the right answer was a specific combination of both. It's a small reminder that "pick one of the options you designed" isn't always the job; sometimes the job is noticing what each option is missing and merging the parts that work.
If I were doing this again, I'd have flagged the video-library ambition earlier and sequenced toward it more deliberately, instead of treating it as a stretch goal that only became real once an unrelated page redesign created the space for it.
The principle I still use: a script-rendering detail — never spelling out a full word in a script your user might not read — is exactly the kind of small decision that determines whether a feature actually serves the audience it was built for, or just looks like it does.