Release notes
Ship the news inside your product. Announce launches with a banner or modal, point users at what's new with a tooltip, and target exactly who should hear about each change.
How teams use Wakeline for this.
Banner the news
Pin an announcement banner with a link to learn more.
Make it a moment
Use a modal for major launches so it really lands.
Point at the change
A tooltip takes users straight to the new feature.
Live in three steps.
Write the announcement
A banner or a modal — your call.
Target the audience
Everyone, or just the right segment.
Publish instantly
It goes live in seconds.
Shipping one release to three audiences.
A release rarely matters equally to everyone. The mature pattern is one launch, three intensities — each audience hearing it at the volume it deserves.
The headline: a modal for the affected
The API rate-limit change gets a modal — but only for a segment with api_calls_30d greater than 0. It is a full stop for the users it affects and silence for everyone else.
The general news: a banner
The redesigned dashboard gets a top banner for all logged-in users, push-content-down enabled, one "See what changed" button, frequency once. Informative, skippable, gone tomorrow.
The detail: a tooltip on arrival
A tooltip on the moved export button targets users on their first visit to the new dashboard: "Export lives here now." It advances on the real click and never shows again.
The record: the changelog
Everything lands in your changelog page for the users who read release notes on purpose. Guides carry the news; the changelog keeps the archive.
What to expect: Nobody misses what affects them; nobody wades through what does not. Click actions per surface show which audience engaged — and dismissal rates tell you when you have pitched an announcement at the wrong intensity.
When not to use this play.
No pattern fits every job. Here’s where we’d point you at something else — sometimes ours, sometimes not.
Every minor release as an announcement
Weekly "we shipped improvements" modals train users to close without reading — the announcement equivalent of crying wolf. Reserve in-app guides for changes users will notice; batch the rest into the changelog.
Breaking changes as a banner
A change that breaks workflows deserves a modal with lead time and a migration path, targeted at affected users — not a dismissible one-liner. Match the surface's gravity to the change's.
Marketing campaigns dressed as release notes
Users grant announcements attention because they expect product information. Spending that trust on promos degrades the channel — keep upsell in its own targeted plays.
Modal, banner, or tooltip for an announcement?
By blast radius: a modal for changes that alter how affected users work (targeted at exactly those users), a banner for general news everyone may skim, a tooltip pinned to the change itself for wayfinding. The discipline of choosing is what keeps each surface potent.
How do I announce only to the users a change affects?
Segments on usage traits: API users for API changes, admins for permission changes, heavy filter users for filter changes. One release can run three guides with three segments — same news, no collateral noise.
How long should an announcement run?
Banners: until the news is stale — days, not weeks — then unpublish. Modals: frequency once, live for a week or two to catch returning users. Tooltips on moved UI: a few weeks, until the muscle memory of your regulars has caught up.
Do users actually read in-app release notes?
They read relevance. Targeted announcements with one clear action routinely see strong engagement in click actions; broadcast everything-modals see reflexive dismissal. The data will teach you quickly which one you are shipping.
Put this to work.
Ship your first guide in minutes. Free to start — no credit card.