O1
Project Context
Where theming Lived
PROBLEM
What happens when every theming decision lives in someone's head?
The Problem
JioHotstar themes its app for events - IPL, Diwali, Bigg Boss launches. The interface responds to what's happening on the platform. That much already worked.
What didn't work was the decision-making behind it. No shared criteria decided which events qualified. No consistent rule decided which surfaces activated. No standard set how much visual change a moment earned. Every request got judged in isolation.
The Gap
leading to inconsistent experiences,
Surface overload,
No defensible way to say no to requests.
O2
The Solution
What did I build?
My Intent Was To Make App Theming Effortless
I Build a Consistent, org-wide system
that helps in making theming decisions
As a team of 2 product designers our goal was to build a
decision making framework for theming within 6 weeks
GOALS OF THIS FRAMEWORK
01
Does this event qualify for theming?
02
If yes, which surfaces should activate and why?
03
how do we ensure the experience is delightful without becoming intrusive.
Identified theming surfaces across the app that we designed
The intent was simple: the app should feel like it's in the day with the user, not asking them to celebrate it on the platform's behalf. Every themed surface is placed by function and capped by rule, so the moment lands across the app without ever competing with what a user came to do.
how do we ensure the experience is delightful without becoming intrusive.
Identified theming surfaces across the app that we designed
The intent was simple: the app should feel like it's in the day with the user, not asking them to celebrate it on the platform's behalf. Every themed surface is placed by function and capped by rule, so the moment lands across the app without ever competing with what a user came to do.
Theming decision Tool
Collapses what used to take a meeting into a decision anyone can make in 90 seconds.
Type an event. Rate five signals. Get a verdict - the tier, the duration, the exact surfaces to activate, and the engineering status of each. What used to take a meeting now takes 90 seconds, and returns the same answer no matter who's asking.
O3
Key Design Decisions
What went in?
My Intent Was To Make App Theming Effortless
Where is a user's attention actually free to spend?
The Problem
A themed surface only works if a user notices it. Placed where attention is already locked on a decision, the same theme reads as noise.
Approach
I traced how attention moves through the app — land, scan, decide, watch — and scored every surface against how much attention it holds at each stage.
Delight follows attention.
Surfaces for Theming
Outcome.
No themed surface in this system sits where a user is trying to decide what to watch.
A framework built around user intent
The user tells the framework when to show up.
I mapped four user journeys and annotated each by cognitive state at entry. Receptive users get the full moment; users with clear intent never have theming inserted into their path.
Outcome.
Theming's welcome depends on the user's state at entry, not on how big the event is. A passive-browse user gets the full moment. A user with clear intent never has theming inserted into their path.
Turning subjective biases into objective outcomes
How significant is this event, to make it worthy of theming
Because significance is what determines everything else. Whether it qualifies. Which tier it falls into. How many surfaces it unlocks.
But significance isn’t one-size-fits-all.
For content-led theming, it can mean viewership- how many people are coming to watch.
For festive moments, viewership tells us very little. People aren’t coming to Hotstar to watch Diwali
Three kinds of framework models that we built
Each testing a different way to turn significant from a feeling into a check. One ruler across every event broke on festive content. Maximum precision became unusable. The hybrid held, matching evidence to event type, staying simple enough for someone other than its author to run it.
Surface classification and allotment
Classify surfaces by the job they do, not by where they sit on screen.
The Problem
Knowing which tier an event landed in still didn't answer what a themed surface was supposed to do once it activated.
Two surfaces performing overlapping jobs inside the same journey produced repetition of meaning - "it's Diwali, it's Diwali, it's Diwali," by the third repetition the message had diminished, and that's not the kind of feeling we want our users to leave with
Stacked interruptions read as delight the first time and hostility the second, no matter how well either was designed alone.
Approach
Functional Classification of surfaces will help make the theming more consistent and rationale
That turned "this feels like too much" from a subjective sense into a checkable rule.
The final Mastertable
Outcome.
The framework turns months of reasoning into one clear reference. Instead of re-evaluating every event from scratch, the table gives teams a consistent answer:
what tier, duration and activation each event calls for.
O4
Impact
What Changed?
IMPACT
Where the framework stands today
Engineers build components against the framework. Design ships surfaces against it. The content ops team, whose job is to want everything themed, now gets a tier and a surface list instead of a fresh negotiation every cycle.
A request that misses the threshold gets a no with a number behind it. The same no lands every time, regardless of who's asking.
OWNERSHIP
Shared
Framework in use by design, PM, engineering, content ops no single author required in the room.
NEGOTIATIONS AVOIDED
Every Cycle
Content ops requests move through the master table lookup instead of re-negotiating each cycle.
DEFENSIBLE NO
Same Every Time
Requests below the threshold get a documented decline with a scoring rationale behind it.
O4
Impact
What I learned
IMPACT
My Reflections
STRATEGIC THINKING
Understanding the why before the what
Every version of the framework held longer once I stopped naming buckets and started asking what problem the buckets were meant to solve.
COMMUNICATION
Aligning people around a shared understanding
A framework only travels as far as the room agrees on the words inside it. Getting design, PM, and engineering to mean the same thing by significance mattered more than any single decision I made.
GROWTH
Staying comfortable with uncertainty
The framework collapsed three times. Each time, the answer wasn't in a faster fix, it was in sitting with not knowing yet, long enough for the right question to surface
