How to introduce new features without disrupting existing work
Choose feature announcements around task relevance, permissions, and the consequence of the change. Measure useful adoption and effects on existing work.
In this article
Introduce a new feature where someone can understand and use it in their current task. Check eligibility, explain the consequence of trying it, and keep the original work available. Moved controls and retiring workflows need their own guidance. Respect dismissal, provide a route back to help, and measure successful use alongside any disruption to the existing task.
An optional comparison view, a moved export button, and a retiring workflow are all product changes. They make very different demands on the person using the product. The first can wait until it is useful. The second needs to be findable today. The third may require time to move existing work.
Decide what the user needs to know before choosing the format
Start with the consequence of the release. If nothing breaks and the person can keep working normally, an optional introduction is usually a reasonable starting point. If a familiar action has moved, they need help finding it. If a workflow is being removed, a dismissible tip cannot carry the entire migration.
| Release | The communication problem | A suitable place to start |
|---|---|---|
| Optional new comparison view | Help people recognize when it is useful | Explanation near the report’s date controls |
| Export control moved | Preserve a familiar task route | Guidance at the previous location and clear new labeling |
| New account-wide automation | Explain what enabling it will do | A setup and confirmation flow before activation |
| Existing behavior removed | Help people finish affected work another way | Advance notice and migration help in that workflow |
| Feature restricted to another role | Explain eligibility without offering a dead end | A clear access explanation or supported request route |
These formats can coexist with release notes. Release notes provide a durable record for people deliberately looking for changes. Contextual instruction helps someone act now. Expecting one modal to do both jobs puts too much pressure on an interruption people may close immediately.
Nielsen Norman Group’s comparison of onboarding tutorials and contextual help describes the problems with instructions presented away from the task: users may skip them or forget them before they need the information. It recommends help that people can access in context and retrieve later. That is a useful basis for introducing features to experienced users too.
Make the first use possible before inviting it
Consider a hypothetical reporting tool adding a period-comparison view. “Try comparisons” should not appear simply because the account has logged in since launch. The person needs permission to use it and a report with suitable data. Someone currently fixing a failed connection has a more urgent task.
Define that eligibility before writing the announcement. If the feature is unavailable in the current state, choose between withholding the introduction and explaining what would make it available. Do not send the user through an exciting invitation only to end at a disabled control with no explanation.
Then choose the moment. Opening a report is closer to the comparison task than logging in. Opening the date selector is closer still, though waiting that long may make discovery too narrow. The right placement depends on how people reach the task; it is something to observe, not a universal trigger to copy.
A stable control with a short “New” label may be enough. A small explanation can answer what the feature does without covering the report. If the interaction is unfamiliar, an optional example may help. The amount of teaching should follow the difficulty of using the capability.
Show the consequence in the invitation
For the reporting example, proposed copy could read:
Compare this report with an earlier period. Choose a second date range to see the change beside each result.
The action, “Add comparison,” should lead into that operation. If the comparison only changes the current view, say so when people might worry about altering a saved report. If it updates a shared report, explain that consequence before they save. The wording must describe the actual product behavior.
Once the user chooses a period, keep the selection visible and editable. Handle a period with no data explicitly; empty data and a measured zero are different situations. A feature introduction that gets someone to a misleading result has failed even if every tour step was completed.
Avoid turning “Next” into a consequential action. Moving through a lesson should not quietly enable scheduled emails, publish content, or change a whole account. Separate demonstration from activation. Let the user review what will happen at the point where they commit.
Decide when the introduction ends
A dismissal can mean “not now.” It can also mean “I understood,” “I already know about this,” or “this is irrelevant.” You rarely have enough information to distinguish those meanings from the close event alone.
Respect the dismissal and keep a route back to help. Do not reopen the same tip on every login because the adoption event has not fired. Where another reminder is justified, give it a reason and a limit rather than treating absence of use as consent to repeat the campaign.
Successful use should usually stop the introductory prompt for that person. In shared products, be deliberate about whether the state belongs to the individual or the workspace. One administrator enabling an automation may complete account setup; it does not teach every teammate how to inspect its output.
Use consistent names across the interface and help. NN/G’s usability heuristics emphasize consistency, user control, and recognition rather than recall. A person should be able to find “Compare periods” next month without remembering that the launch announcement called it “Time insights.”
Count what happened to the original task
Measure exposure, attempts, and successful use separately. A click on “Try it” is an attempt. A completed comparison is a stronger result. For a capability intended to be used repeatedly, later use can tell you more than a single exploratory session.
Keep the eligible audience clear. Including users without the necessary permission or data in the denominator can make a useful feature look unsuccessful. Excluding people whose original work was interrupted can hide the cost of the announcement.
For the reporting example, inspect whether people still obtain the report they came for. Track failed comparisons and canceled attempts, but also observe task time and completion around the existing report workflow. A launch can create more feature clicks while making ordinary reporting harder.
Where you need to establish the effect of an introduction, use an appropriate controlled comparison. A rise in use after release may reflect the feature itself, another campaign, or a change in the audience. The announcement is only one possible cause.
After the launch period, remove temporary badges and stale prompts. The feature should have a durable place in navigation, usable labels, and help that remains available. A successful introduction eventually makes its own campaign unnecessary.
When a new capability exposes work to other people, show the audience before the first share or publish action as part of introducing that capability.
Sources
- Nielsen Norman Group: Onboarding Tutorials vs. Contextual Help.
- Nielsen Norman Group: 10 Usability Heuristics for User Interface Design.
