The little bell icon in the corner of an app. The dot badge that appears when something changed. The popover that slides open showing the last three product updates.
That's a "What's New" widget, and if your SaaS product doesn't have one, you're leaving user engagement on the table.
This is the complete guide: what they are, why they work, how to implement one, and how to use it effectively.
What is a What's New widget?
A What's New widget is an embedded UI element in your app that surfaces your changelog to users in context. It typically looks like one of these:
- A notification bell or icon in the navigation bar, with a numbered badge when there are new entries
- A floating button (usually bottom-right) labelled "What's New" or "Updates"
- A sidebar panel that slides open on click
When users click the trigger, they see a list of recent updates, usually the last 5-10 entries, with title, date, and a short description. Clicking an entry expands it or links to the full post.
Why do they work better than other announcement formats?
The alternatives are all worse for regular product updates:
Email newsletters: High unsubscribe rates, low open rates for product updates specifically (people sign up to use the product, not to read about it). Good for major releases, not continuous small improvements.
In-app modals: Disruptive. Users click dismiss immediately. Best for critical notices only.
Blog posts: Users have to seek them out. Most don't.
Social media: Fine for acquisition, almost zero existing user engagement.
A widget embedded in the app has three advantages the others don't:
- Context: Users are already in the product when they see it. The mental distance between "I see this feature exists" and "I click into it" is tiny.
- Discovery without interruption: The badge signals something is new. Users notice it without being forced to stop what they're doing.
- Persistence: Unlike a modal that dismisses after first view, the widget is always there. Users who miss an update this week will find it next week.
Before you build: use a hosted widget
Unless your team has a lot of spare engineering time, don't build this from scratch. A changelog widget seems simple but has non-trivial details:
- Storing read/unread state per user (localStorage or server-side)
- Displaying a badge count that reflects unread items
- Handling the feed update cycle
- Styling that doesn't clash with your app's design system
- Mobile responsiveness
- Performance (the script can't block your app's load)
Hosted solutions handle all of this and take 10 minutes to implement. Patchlog is free to start. Beamer, Headway, and AnnounceKit are other options (see our Beamer alternatives guide and Headway alternatives guide for full comparisons).
How to implement Patchlog's widget (step by step)
1. Create a project
Sign up at patchlog.io and create a project. Choose a name and slug. The slug becomes your public URL (patchlog.io/c/your-slug) and the widget identifier.
2. Add the script to your app
Copy the embed snippet from your project settings:
<script
src="https://patchlog.io/widget.js"
data-project="YOUR_PROJECT_ID"
async>
</script>
Add it before the closing </body> tag. The async attribute means it won't block your app loading.
React (via useEffect):
useEffect(() => {
const script = document.createElement('script');
script.src = 'https://patchlog.io/widget.js';
script.setAttribute('data-project', 'your-slug');
script.async = true;
document.body.appendChild(script);
return () => document.body.removeChild(script);
}, []);
Vue 3 (via onMounted):
<script setup>
import { onMounted, onUnmounted } from 'vue';
let script;
onMounted(() => {
script = document.createElement('script');
script.src = 'https://patchlog.io/widget.js';
script.setAttribute('data-project', 'your-slug');
script.async = true;
document.body.appendChild(script);
});
onUnmounted(() => script?.remove());
</script>
Laravel Blade / plain HTML:
<script
src="https://patchlog.io/widget.js"
data-project="your-slug"
async>
</script>
3. Publish your first entry
Back in Patchlog, create a changelog entry. The widget will automatically display it with a notification badge the next time any user loads your app.
That's the implementation. Total time: about 10 minutes.
Placement: where should the widget trigger go?
This is more important than most teams realise. Bad placement → nobody clicks it → waste of time.
The best placements:
-
Top navigation bar, near user avatar/account menu. Users look here naturally for account-related context. A notification bell here has established UX expectations (everyone's used Slack, Gmail, GitHub, so it is a known pattern).
-
Bottom-right floating button. Works well for consumer products. More visible, but slightly more intrusive. Avoid if your app already has a chat widget in the bottom-right corner.
-
Sidebar (in a vertical nav layout). A "What's New" menu item with a badge indicator. Works for dashboard-style apps where users spend long sessions in a sidebar navigation.
What to avoid:
- Bottom-left: Competes with cookie notices / chat widgets
- Hidden in settings: Users who want to know what's new aren't looking in settings
- Homepage/marketing site only: Your existing users aren't on the marketing site. Put it inside the product.
What to write in the widget (and what not to)
The widget entry needs to be shorter than a full blog post changelog entry. You have about 2-3 lines before users lose interest.
Format that works:
**Bulk CSV export**
You can now export all your contacts to CSV in one click.
Go to Contacts → Export → Download CSV.
- Bold title (the feature name or the user benefit)
- One sentence: what changed
- One sentence (optional): how to access it
What to avoid:
- Internal jargon users won't understand
- Passive voice ("A new feature has been added")
- Describing the technical implementation ("Refactored the export pipeline")
- Entries that aren't user-facing ("Updated dependencies")
How often should you post?
There's no universal right answer, but here's a working framework:
- Weekly or more: Good for developer tools and power-user products. These audiences want to know every detail.
- Bi-weekly: Works for most B2B products. Frequent enough to feel alive, not so frequent that users start ignoring it.
- Monthly: Minimum viable cadence. Works for slower-moving products with complex features. Below monthly, you lose the "active development" signal.
The worst cadence is irregular. Three posts in January, nothing in February, one post in March creates the opposite of momentum. Set a minimum. Hold yourself to it.
Tracking whether it's working
Two simple metrics tell you most of what you need to know:
-
Widget open rate: what percentage of active users click the widget at all. Even 15-20% is healthy. Below 5% suggests placement or entry quality problems.
-
Support ticket volume on announced features: if you announce a feature in the widget and support tickets about "how do I do X" drop within a week, the widget is doing its job.
Most hosted widget tools track open rates. Start there.
The one-minute summary
- A What's New widget is an in-app changelog feed with a notification badge
- It outperforms email and modals for regular product updates
- Add it with 2 lines of HTML (or use a hosted tool like Patchlog, free)
- Place it in the top nav or as a bottom-right float
- Write 2-3 lines per entry, user-benefit focused
- Post at minimum once a month, ideally more