Case study 02 · Growth · Dainik Bhaskar

Discovery for readers who came to leave

RoleProduct designer — subscriptions & growth
ScopeStory rings · native widgets · games surfaces
Timeline2022 – 2026
PlatformAndroid · iOS
9%
CTR on the story-ring widget — legacy widgets did 1–2%
15–25%
CTR on the native-format feed widget, by placement
Default
launch surface for every new feature the app introduces

Context

Dainik Bhaskar's readers have one of the strongest single-intent behaviors in consumer apps: a notification arrives, they open the app, read the top news, and leave. Even the most loyal daily users follow the loop. Meanwhile the app kept growing beyond news — word games, horoscopes, interactives, quizzes — and none of it could find an audience, because the audience wasn't looking.

The problem — a graveyard of widgets

Before my work, the app had tried discovery many times: widget after widget for non-news content, including placements directly on the home feed — prime real estate. Every attempt ended the same way, with CTRs of 1–2%. The comfortable conclusion would have been "users don't want non-news content." I didn't buy it. People play word games and read horoscopes constantly — just not in our app.

The real diagnosis: every failed widget made the same demand of the user — develop a new intent. A reader mid-scroll toward the news has no reason to stop for an unfamiliar box asking them to want something else. It doesn't matter where you put that box. A widget demanding new intent is, functionally, an ad — and readers treat it like one.

The insight: discovery doesn't fail because of placement. It fails when it asks users to develop a new intent. The fix wasn't a better widget — it was borrowing intent users already had.

What I did — two borrowed intents

1 · Story rings: borrowed muscle memory

Instagram trained half of India to tap circles at the top of a feed. That behavior is free — no teaching, no convincing. I placed a story-ring bar at the top of the home feed: circular, colorful, tappable rings carrying games, horoscopes, trending topics, and news itself, mixed together so the bar always has a reason to be tapped. It's vertically shallow, so it takes almost nothing from the news feed below it.

Against the 1–2% CTR of every discovery widget before it, the story bar hit 9% — a 4–9× improvement.

2 · The native-format widget: borrowed reading behavior

The second surface goes the opposite direction: instead of standing out, it disappears. A feed widget built to the exact format of our article previews — same layout, same typography, same rhythm — but carrying non-news content, marked with its own category chip. Readers scanning headlines don't register it as an interruption; it rides the scanning behavior they came with. CTR: 15–25%, varying with feed position.

3 · Dedicated games surfaces

For games specifically, I designed promotional discovery surfaces — full-screen showcases presenting the game catalog with strong visual identity and a single play action — giving new games a launch moment rather than a quiet appearance in a menu.

Story rings · 9% CTRDainik Bhaskar home feed with story-ring widget at top: circular rings for Wordmala, horoscope, Wordkhoj and trending topics above the news feed
Native-format widgetFeed widget styled identically to article previews, carrying games content with its own category chip, placed between news stories
Two opposite strategies, one principle: the rings borrow Instagram's muscle memory; the native widget borrows the reader's own headline-scanning habit.
Games showcaseFull-screen games discovery surface showing a carousel of Dainik Bhaskar games including quiz and puzzle titles
Game spotlightSingle-game promotional screen for the spot-the-difference game with a prominent play call to action
Games got launch moments, not menu entries.

Decisions & tradeoffs

Winning space by needing less of it

The home feed is editorial territory, and editorial had every reason to guard it — I'd already fought that battle once on the subscription widget. The story bar was designed to win politically by design: vertically shallow, sitting above the feed rather than inside it, taking almost nothing from the news. The least disruptive surface turned out to be the highest-performing one — which is not a coincidence. Surfaces that respect the core experience get to stay, and surfaces that stay get to compound.

Mixing news into the rings

A purist version of the story bar would carry only non-news — it's a discovery surface, after all. I mixed news in deliberately. News is why readers are there; news in the rings keeps the tap habit alive daily, and every tap teaches the reader that the circles are worth tapping. Non-news content then rides a habit that news maintains. The discovery surface works because it isn't purely a discovery surface.

Native format, honestly labeled

A widget that perfectly mimics article previews raises an obvious question: is that deceptive? The line I held: match the format, mark the content. The widget carries its own category chip, exactly as sports or national news stories carry theirs. It reads as "another kind of story in your feed" — which is true — not as a disguised ad.

Outcome

The story bar and native-format widget didn't just outperform every previous discovery attempt — they became infrastructure. The content team curates what flows through them day to day, and they're now the default launch surface for anything new the app ships: new games, interactives, features. Discovery stopped being a series of one-off widget experiments and became a permanent, operated system.

What I'd do differently

Personalization is the unbuilt second half. The rings and widgets are editorially curated — the same set for everyone. The behavioral data now exists to order rings per user, and the next version of this system should learn: a reader who taps the horoscope daily should never have to look for it in fourth position. I'd also standardize measurement earlier — when a surface performs at several times the previous baseline, the first serious question is "measured how?", and I want that answer defined in the design doc, not reconstructed afterwards.