Explain an update to people who know the old workflow

Existing users bring a model of how the product works. The important question is not simply what changed in the interface, but which expectation now needs adjustment. A new control can be easy to see while its consequences remain unclear.

Write one sentence beginning, “Previously, a user doing this task would expect…” and another beginning, “Now, at this point, the user should…” If the sentences describe the same action and result, the update may need a location cue rather than a detailed demonstration.

• Keep a familiar task label or object visible at the opening.
• Mark the changed step with its exact supplied name.
• Explain the new decision before showing its result.
• State a relevant unchanged behavior when it prevents a likely misunderstanding.

This is an illustrative update to a fictional project tool. Previously, duplicating a project copied each task's due date unchanged. In the fictional new version, the duplication dialog offers “Keep dates” or “Shift dates,” with a supplied rule for the shift. The change applies only to tasks in the new copy.

The old expectation is that a duplicate inherits the dates. The new decision is choosing whether to preserve or shift them during duplication. The proof is the new project's task dates matching the selected option. The original project's unchanged dates are a useful boundary because viewers may otherwise think the action reschedules both projects.

Do not invent the shifting rule. The release owner must supply how the new start date affects tasks and what happens to tasks without dates. Those facts determine the example and may change whether the sequence needs an extra explanation.

The following script scaffold is a planning example. Replace the date-shift wording only after the actual rule is approved. Exact labels are shown here solely to make the fictional example concrete.

• Familiar state: “Copying last month's project? Begin with Duplicate, as before.” Hold on the existing project and its title.
• Changed step: “The duplication dialog now lets you keep dates or shift them.” Show both options without selecting one before it has been explained.
• Decision: “Choose the option that matches the new project's schedule.” Add the verified shift explanation if it is needed to make that choice.
• New result: “Check the dates in the new copy before assigning the work.” Hold on the relevant tasks and their dates.
• Boundary: “The original project keeps its dates.” Show this only if confirmed by the release owner.

Use a short old-state reference when it helps viewers locate the change. A full side-by-side replay may waste time if most steps are identical. For the duplication example, one familiar opening followed by the new dialog is enough to establish continuity; the date result deserves more inspection time.

If the change removes or relocates an old action, a matched before-and-after view may be necessary. Preserve object names and sample data so viewers compare behavior rather than spend their attention reconciling different examples. Avoid animating an old control into a new location when that suggests an unverified transition inside the product.

Ask a reviewer to state what they should do differently and what remains the same. A vague answer such as “duplication is improved” means the explanation has not taught the decision. An answer that includes changing the original project's schedule reveals a misleading implication.

Keep the closing action narrow. Existing users do not need a general invitation to discover the whole product. They need to recognize the changed step the next time they perform the familiar task and know which result to check.