CHECK THE PROMISE, NOT JUST THE PROSE
The checklist does not make a note good on its own. It does help a team pause before publishing and make sure the useful context has not been lost along the way.
For a paper copy, use your browser’s print command. Navigation and decorative elements are hidden in print view.
1. The change
- The opening says what is newly possible or more reliable.
- The wording refers to a visible behaviour, not an internal task.
- The title and body describe the same thing.
2. The person
- The benefit connects to a real task or moment.
- The relevant audience is not assumed to be everyone.
- The note works when read without a screenshot.
3. The next move
- Any action is specific and genuinely useful.
- Settings are named exactly as they appear in the app.
- “No action needed” is used when that is the honest instruction.
4. The conditions
- Rollout timing sits near the promise.
- Device, region or account requirements are clear.
- Known limitations are described without hiding them in a footnote.
5. The language
- Short sentences carry one main idea at a time.
- Jargon and project names have been removed or explained.
- The first sentence makes sense when read aloud.
6. The handover
- Support has seen the final public wording.
- Owners know where the detailed internal changelog lives.
- A copy is saved for the team’s reference library.
A 30-second final check
Ask: could a person who has never heard the internal project name tell what will be different for them? If the answer is no, simplify the first line before the update goes live.
For fuller context, read the field guide or return to the interactive notebook check.