Unified Cards
A Scalable Component Library for BookMyShow
Role
Business Context
As part of BookMyShow's 2019/20 mobile strategy, all pages were moving to native code from React Native and other frameworks. At the same time, AdTech was changing how ads rendered on the home page, and any change made in React Native would eventually need rebuilding in native anyway. Discovery — the home and listing experience — could only add or remove a widget by shipping a new app release, which meant every new idea was gated behind the app store's release cycle, throttling adoption of anything new before it could even be tested.
Strategic Decision
**Component Reuse vs. Widget Proliferation**
Context: the team could keep designing bespoke widgets for each new discovery idea, or invest in identifying which widgets were actually variations of the same underlying pattern.
Options: (1) continue building new, purpose-specific widgets as ideas came up, or (2) audit the full widget catalog, identify the common shape beneath most of them, and rebuild around a small set of backend-powered, reusable components.
Trade-off: option 2 meant slower initial design and engineering work to build genuinely flexible components, and accepting that some widget-specific nuance would be lost in the name of reuse.
Decision: rebuild around reusable components.
Why: of the 30–40 widgets identified, only 6–7 turned out to need to exist as truly distinct components — the rest were transformations of the same underlying card-plus-meta pattern. Investing in that smaller set paid for itself by removing the app-release dependency for every future variation.
Design Principles
1. **Backend-Powered, Not Hardcoded** — every reusable component took its shape from values passed through the API, not from code that shipped with the app.
2. **Fewer Components, More Configurations** — prefer transforming an existing widget into a new configuration over designing a new one from scratch.
3. **Artwork Over Metadata** — for movie and event cards specifically, let the poster or artwork carry the communication load instead of layering on text.
4. **Category Awareness Before Conversion** — widgets like Collections exist to build awareness of what's on the platform before asking users to act, not to drive an immediate transaction.
Key Product Decisions
**1. Reusable widget architecture**
Problem: 30–40 candidate widgets, each requiring its own design and engineering effort and an app release to ship.
Options explored: keep building bespoke widgets per use case, vs. identify the shared structure across widgets and consolidate into reusable, backend-powered components.
Decision: consolidate into ~6–7 reusable components.
Solution: each component took a title, subtitle, and meta info from the API and could be reconfigured into different widget types without new code.
Business impact: removed the app-release dependency for adding, removing, or re-ranking a widget, and saved substantial design and engineering time versus building each widget individually.
**2. Unifying movie and event cards**
Problem: movie and event cards looked and behaved differently, the card ratio didn't match industry standards (~1:1.5) or the design system's 8px grid, and cards leaned on metadata more than artwork.
Options explored: keep the two card types separate and improve each independently, vs. unify them into one card structure with a single shared meta field (rating for movies, date for events).
Decision: unify into one card structure.
Solution: a single card format for both movies and events, artwork-forward, with one line of meta info and a consistent top-right tag placement so artwork never got cropped.
Business impact: simplified the design system's card inventory and made artwork — which the graphics team invested real effort in — legible even on the smallest devices in the user base.
**3. Repositioning and redesigning Collections**
Problem: category awareness was a real, user-reported problem — before someone can express interest in a category, they need to know it exists — and the original Collections widget didn't create that awareness effectively.
Options explored: leave Collections lower in the page hierarchy, vs. reposition it as the second widget immediately after the primary movie widget.
Decision: reposition Collections higher, and iterate its visual design across three versions.
Solution: Collections moved to the second slot on the page; the visual treatment evolved from photo tiles (1.0) to line-icon illustrations (2.0, which didn't resonate with a tier-1-to-tier-2-city user base) to a bold color-block-plus-photo hybrid (3.0) that better matched BookMyShow's brand energy.
Business impact: repositioning gave Collections the visibility needed to drive category awareness, though the team identified follow-on issues (static cards regardless of real-time supply, uneven category representation) as the next problem to solve.
Outcomes
**Business:** reduced the design and engineering cost of Discovery by consolidating 30–40 candidate widgets into 6–7 reusable, backend-powered components.
**Customer:** movie and event cards became visually consistent and more legible, and Collections were repositioned to build category awareness beyond BookMyShow's traditional movies association.
**Operations:** adding, removing, or re-ranking a widget no longer required an app release, removing a recurring release-cycle bottleneck.
**Engineering:** the discovery module became dynamic and configurable from the backend instead of requiring new native code for each widget.
**Support:** no support-specific data was available for this feature.
Reflection
The biggest surprise was how few genuinely distinct components we actually needed. Looking at 30–40 widgets, it felt like we were designing a large, varied system — but most of them were the same underlying pattern wearing different configurations, and only 6–7 needed to exist as real, separate components.
If I were doing this again, I'd audit for that shared structure earlier, before designing new widgets rather than after. We found the reusable pattern by looking backward at what we'd already built; finding it earlier would have saved some of the one-off work we later had to fold into the reusable set.
The principle I still use from this project: before designing something new, ask whether it's really a new thing, or a new configuration of something that already exists. Most "new" requirements are the second kind.