Role & Summary
Led the redesign of BookMyShow's Discovery architecture, consolidating 30-40 one-off widgets into 6-7 reusable, backend-powered components so new experiences could ship without an app release.
Business Context
As part of BookMyShow's 2019/20 mobile strategy, all pages were moving to native code from React Native and other frameworks, and any change made in React Native would eventually need rebuilding in native anyway. AdTech was also changing how ads rendered on the home page. Discovery (the home and listing experience) could only add or remove a widget by shipping a new app release, gating every new idea behind the app store's release cycle before it could even be tested.
Strategic Decision
Component Reuse vs. Widget Proliferation
Context: the team could keep designing bespoke widgets for each new idea, or invest in identifying which widgets were actually variations of the same pattern.
Options: (1) continue building purpose-specific widgets as ideas came up, or (2) audit the full widget catalog and rebuild around a small set of backend-powered, reusable components.
Trade-off: option 2 meant slower initial design and engineering work, and accepting that some widget-specific nuance would be lost to reuse.
Decision: rebuild around reusable components.
Why: of the 30–40 widgets identified, only 6–7 needed to exist as truly distinct components: the rest were transformations of the same card-plus-meta pattern. Investing in that smaller set removed the app-release dependency for every future variation.
Design Principles
1. Backend-Powered, Not Hardcoded: every component took its shape from values passed through the API, not code shipped with the app.
2. Fewer Components, More Configurations: prefer transforming an existing widget into a new configuration over designing one from scratch.
3. Artwork Over Metadata: for movie and event cards, let the poster 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.
Key Product Decisions
1. Consolidated 30–40 widgets into ~6–7 reusable components: each pulled title, subtitle, and meta info from the API and could be reconfigured without new code, removing the app-release dependency for adding or changing a widget.
2. Unified movie and event cards into one structure: a single artwork-forward format with one line of meta info and consistent tag placement, simplifying the card inventory and improving legibility on the smallest devices.
3. Repositioned and iterated Collections: moved to the second slot and redesigned across three visual versions to drive category awareness, though uneven category representation remained 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 movies.
Operations: adding, removing, or re-ranking a widget no longer required an app release, removing a recurring bottleneck.
Engineering: the discovery module became dynamic and configurable from the backend instead of requiring new native code per 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 felt like designing a large, varied system, but most were the same pattern wearing different configurations, and only 6–7 needed to exist as real, separate components. I'd audit for that shared structure earlier next time, before designing new widgets rather than after: we found the pattern by looking backward at what we'd already built, which cost us some one-off work we later had to fold into the reusable set.
The principle I still use: 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.
