In-app "What’s new" widgets: patterns that inform without annoying

A changelog page only works for people who visit it. Most of your users never will — they live inside your product, not on your website. The in-app "what's new" widget exists to close that gap: a small indicator in your UI that says something shipped, and a panel that shows what, without anyone leaving the screen they were on. Done well, it's the highest-leverage distribution your changelog will ever get. Done badly, it's one more thing users learn to ignore — or resent.

Why in-app beats every other channel for reach

Compare the audiences. Your changelog page reaches people curious enough to seek it out. Your RSS feed reaches the handful who subscribe. An email blast reaches everyone and annoys most of them. The widget reaches every active user, exactly at the moment they're using the product — which is the only moment "we improved the thing you're holding" is actually relevant. That timing is the whole value: announcements about the product, inside the product, shown to people currently using the product.

It also has the honest metric on its side: users who clicked a what's-new dot chose to look. Nobody chooses to open a marketing email titled "We've been busy! 🚀".

The anatomy that became a standard

Nearly every implementation (Headway popularized it; Intercom, Beamer, and a hundred in-house versions converged on the same shape) has three parts:

  • The indicator. A small dot or count badge attached to something users already look at — a bell icon, the word "What's new" in a footer or help menu, the app logo. It appears only when there are entries the user hasn't seen.
  • The panel. Clicking opens a compact list of recent entries — title, tag, date, a sentence or two — in a popover or slide-out. Not a modal. Never a modal.
  • The seen-state. Opening the panel clears the indicator. The user is in control of the loop: notice, glance, dismiss, back to work in five seconds.

That shape survived a decade of product design because it respects a boundary: the indicator may interrupt (mildly, passively); the content may not.

Placement: attach it to attention you already have

The widget works by borrowing glances at UI users already check — which is why the classic placements are the navbar bell, the help menu, and the logo corner. Two rules:

  • Visible on the main working screen, not buried on a settings page. The point is ambient awareness; a widget nobody's eyes pass over is a changelog page with extra steps.
  • Not adjacent to critical actions. A "new stuff!" dot next to the save button trains users to associate your announcements with almost-misclicks.

What content belongs in the widget

Shorter and fewer than the changelog page. The panel is a headline surface: lead with the title and tag, keep bodies to a sentence or two, link out to the full entry for detail. Curate harder than you do on the page — the page can absorb a weekly "small fixes" batch entry; the widget showing "Fixed typo in error message" trains users that the dot means nothing.

A good filter: would an active user change how they work today because of this? New capability, changed behavior, fixed bug they might have hit — yes. Dependency bumps, internal refactors, marketing milestones — no.

The anti-patterns that get widgets ignored

  • Auto-opening the panel. The user came to do a task. A panel that opens itself on login is a popup ad wearing a changelog costume. The dot announces; the user decides.
  • Perma-badging. If the dot is always lit — because you count every entry ever, or reset seen-state too aggressively — it stops carrying information. A dot that's always on is a dot that's always ignored.
  • Marketing creep. The widget earned attention by being useful. The first "Upgrade to Pro! 🎉" entry spends that trust; the third one ends it. Announcements about pricing and webinars belong elsewhere.
  • Notification inflation. Badging the indicator with "12" because the user was on vacation for two weeks. Cap the count display, or just show a dot — the message is "there's news", not "you owe us twelve reads".
  • Blocking the product. Heavy scripts, layout shift, a widget that loads before your app does. The widget is a guest in your UI; guests load last and tread lightly.

Build vs embed

An in-house widget is a real project: seen-state per user, a feed to drive it, rendering, theming, and the discipline to maintain all of it forever. That's justified at Slack's scale. For most products the pragmatic answer is a drop-in: one script tag pointed at your hosted changelog, seen-state in localStorage, popover rendered from your existing feed. You keep writing entries in one place; the widget inherits them.

If you'd rather own the UI entirely, the middle path is a JSON feed: fetch your changelog as data and render your own panel — you own the pixels, the feed stays the single source of truth.

Where Wakelog fits

Wakelog ships this out of the box, free: one script tag adds the dot + popover to any site (data-wakelog="your-project"), themes for light/dark/auto, seen-state handled, no cookies. Prefer your own UI? Every project exposes widget.json and a JSON Feed to render from. Entries come from wherever you already post — the web form, one curl in CI, or release webhooks — and the same entries also feed your public page and RSS.

Add a what's-new widget free   See the widget docs

Related guides

Last updated 2026-07-26 · All guides