Source: https://asterly.co/resources/blog/release-notes-to-help-articles [Blog](https://asterly.co/resources/blog) # Release Notes Say What Changed. Help Articles Say How to Use It 4 November 2026 ![A long changelog list card on the left connected by a curved line to two help article page cards on the right, on a soft plum wash.](https://asterly.co/resources/blog/images/release-notes-to-help-articles/featured-hifi.png) Release notes and help articles often come from the same team, in the same week, for very different readers. The catch: most teams publish the release note and assume the help center will catch up. It usually doesn't. So how do you convert release notes into help articles? Take each change that alters what a user does, rename it as the task they'd search for, then write the steps by doing the task in the app, not by rewording the note. Skip changes that don't change anyone's clicks. Split notes that hide two tasks. In this post, we'll take three real entries from an open-source changelog and turn each one into a help article. ## Why a Release Note Isn't a Help Article I've spent more than a decade in product marketing, so I've written my share of release notes. A release note answers "what's new?" It's written once, read once and pushed down the page by next month's release. A help article answers "how do I...?" It's found through search, months later, by someone stuck halfway through a task. Same feature. Different question. That's why pasting the note into the help center doesn't work. ## The Changelog We're Using For real examples, we picked the public release notes of Actual Budget, an open-source personal finance app. Their notes are user-facing and grouped by release, which makes them a good test. Source: [Actual Budget release notes](https://actualbudget.org/docs/releases) We'll run three entries through the same four questions: 1. **Does this change what a user does?** If not, no article. 2. **What would the user search for?** That's the title. 3. **Is this one task or two?** One article per task. 4. **What does the note leave out?** That's where the steps come from. ## Example 1: Renaming a Tag [![Flow from a real release note entry about renaming a tag, through four questions (does it change what a user does, what would they search for, one task or two, what does the note leave out) to a help article titled Rename a tag.](https://asterly.co/resources/blog/images/release-notes-to-help-articles/four-questions.png)](https://asterly.co/resources/blog/images/release-notes-to-help-articles/four-questions.png) Four questions for every entry. Example entry quoted from the Actual Budget 26.9.0 release notes. The 26.9.0 notes include this entry: > "Rename a tag from the Tags page, updating the hashtag in every transaction note that uses it" That's already close to a task. Nice. **The search phrase:** nobody searches "tag rename support." They search "how do I rename a tag." **The article title:** Rename a tag **What the note leaves out:** how to get to the Tags page, and what the reader should check afterwards. The note does hand you the "did it work?" line for free: notes that used the old hashtag now show the new one. So the outline looks like this: - **Title:** Rename a tag. - **When to use it:** you want a tag's new name to show everywhere it's used. - **Steps:** open the Tags page, pick the tag, rename it. Write these by doing it in the app, with exact labels in bold. - **Check it worked:** open a transaction that used the old tag and read its note. ## Example 2: The New Schedule Button Also from 26.9.0: > "A new Schedule button lets you schedule future-dated transactions, replacing the "Convert to Schedule" prompt" This one is trickier. Why? Because it changes an existing habit. Some readers know the old prompt and will go looking for it. **The search phrases:** "how to schedule a future transaction," and the old name, "convert to schedule." **The article title:** Schedule a future-dated transaction **What the note leaves out:** the detailed entry in the same release has a useful heads-up. The button "asks for confirmation only when the scheduled date falls beyond your upcoming length setting." It also mentions a keyboard shortcut. So the article gets two extras: - **A "what changed" line at the top:** "The Convert to Schedule prompt is now a Schedule button." - **A heads-up on the confirm step:** say when the confirmation appears, so nobody thinks something broke. For example, a reader who searched the old prompt name lands here, reads the first line and knows exactly where it went (one less confused forum post). ## Example 3: One Note, Two Articles [![A single release note entry about the sidebar and start page splitting into two help articles: Customise the sidebar, and Choose your start page.](https://asterly.co/resources/blog/images/release-notes-to-help-articles/one-note-two-articles.png)](https://asterly.co/resources/blog/images/release-notes-to-help-articles/one-note-two-articles.png) One note, two jobs, two articles. Entry quoted from the Actual Budget 26.11.0 release notes. From 26.11.0: > "Show, hide, and reorder sidebar pages, and choose your start page" Read it again. That's two different jobs. - **Customise the sidebar:** show, hide and reorder pages. - **Choose your start page:** pick the page the app opens on. People want these for different reasons. Someone tidying their sidebar isn't thinking about their start page, and the reverse. So it becomes two short articles, each titled as its task, each linking to the other. A single "Sidebar settings" article would bury the second task under the first. ## What Doesn't Get an Article [![Three lanes for sorting release note entries: New article for a new task, Update an article for a changed or replaced flow, and Skip for speed, fixes and maintenance with no new clicks.](https://asterly.co/resources/blog/images/release-notes-to-help-articles/triage.png)](https://asterly.co/resources/blog/images/release-notes-to-help-articles/triage.png) Mark every entry before you write. If a user's clicks don't change, the help center doesn't either. Not every line deserves a page. The same notes list plenty of changes that don't alter what a user does, like faster loading for large budgets or internal maintenance. Those stay in the changelog. The test is simple: if a user's clicks don't change, the help center doesn't either. At most, an existing troubleshooting article gets a one-line update. ## A Simple Routine for Every Release What does this look like release to release? 1. **Read the notes while they're drafted,** not after launch. 2. **Mark each entry:** new article, update an existing one, or skip. 3. **Write the title as the search phrase.** 4. **Do the task in the app** and write the steps from what you see. 5. **Add a "what changed" line** to any article that covers a replaced flow. 6. **Link the article from the release note,** so both readers land in the right place. I'll be honest: the launch post always feels like the main event. The help article is the part people still read next year. ## The Wrap-Up Release notes tell people what changed. Help articles show them how to use it. Turn each user-facing change into a task, title it the way people search and write the steps by doing them. Ship the note. Then ship the how. _Written by the Asterly team._ [All posts](https://asterly.co/resources/blog)