Write a feature announcement around the new action

Write the plain sequence before polishing the opening: when you have this input, take this action, then check this result. Add why the task matters only after those facts are clear. This keeps “powerful,” “seamless” and similar adjectives from taking the place of product explanation.

The spine is also a production worksheet. Beside every sentence, name the visual that makes it believable. If no visual can support the line, decide whether it needs qualified narration, a source note or removal.

• Input condition: what must already exist?
• Action: what can the user choose or change?
• Result: what visibly confirms the action?
• Boundary: which cases or audiences are excluded?
• Next step: what should the intended viewer do with this information?

Consider a fictional task tool that now lets project editors save a checklist as a personal preset. The example below is illustrative. The supplied facts allow reuse within new tasks but do not include shared presets or automatic updates to existing tasks.

A weak announcement would say, “Revolutionize planning with powerful new presets.” It gives the producer no specific action or evidence to show. The revised script supplies both.

• “Repeating the same checklist?” Show a task with three named illustrative steps.
• “Save it as a personal preset.” Show the verified preset action and naming step.
• “Choose the preset when creating another task.” Show the approved selection path.
• “Check the copied steps before saving.” Hold on the new task with matching step names.
• “Personal presets apply to new tasks.” Keep the supplied scope visible; do not imply existing tasks update.

The second task must remain connected to the saved preset. Reusing the same checklist title or ordered steps gives the viewer evidence of continuity. Jumping from the save button to a full project dashboard would lose the specific result.

If the preset requires a permission the viewer may not have, move that condition toward the action: “Project editors can save…” Do not reveal a disqualifying condition only after inviting every viewer to try the feature.

On the truth pass, trace each line to the approved release record. On the workload pass, identify how many things the viewer must read, compare or remember at once. Shorten repeated context before removing a condition or proof hold.

When a line needs too much detail, split the communication into a concise announcement and a linked how-to. The announcement still needs an accurate action, scope and outcome; the supporting guide can carry exceptions and detailed setup.