Prompt Associates with Appcues and materials and request them to engage, provide feedback, ask questions, and identify any gaps that may require additional demo videos from the product team before the release date.

Gauge the release and what it will change for the users.   See what templates best serve the release style   Get the flows and materials ready on each stage of the release journey.

Release Process

A release will affect users in ways we can't anticipate. The best we can do is try to prepare them enough and help them answer questions they might have and make them feel supported as they make the transition.
Even when the intention behind the release is to make the experience better for the users or improve efficiency, the users should have enough time to prepare before the actual release happens.
For users who use the platform for many hours a day, they will develop patterns and habits when they annotate, and so when there are updates and changes to the platform, they affect/change the rhythm of their habits. It is important to keep this cognitive effort it takes for the users to adjust and “account” for transition time.

REQUIREMENTS FROM GSD

The associates will be responsible for making sure they are well prepared for any releases we communicate directly to them.

• Read through the Appcues and not dismiss the content
• Watch the videos provided and leave comments, ask questions through the Team Leads.
• Be on alert on the day of release and follow the steps needed to help along with the transition. 
• Provide initial feedback on the release and support opportunities. 
• Ask for additional materials they would need to enable them to prepare for the release

REQUIREMENTS FROM THE PRODUCT SIDE

• Coordinate with Prod Ops during the release process
   
• Give feedback on the issues list from the teams.
  • Sort through the priority to decide what gets fixed (provide timelines for the fix)
    And what is not urgent for an immediate fix 
    • i.e if the users have a workaround and it's not interrupting their annotation flow.
       
• Gauge from feedback and interaction whether UXR will be needed for this round of release, and at what stage it will be required.
  • Are there some details/pieces that were missed during development that need refining?
  • Any aspects on the release that the users are finding a bit hard to get and would need more context and materials?
     
• Prepare release materials for the next phase and share with Ops for review.
   
• If all good to go, proceed with the release plan with the date agreed upon.
  • If there were blockers on the timelines, update the associates and tell them when the release will be executed.
     
• Highlight as a follow an analysis summary to the users. Could include;
  • Interaction metrics
  • Adoption rate
  • Pre and post-comparison analysis
  •  

TABLA

When the release involves a tool or Feature Flag;

Release stage

A release will affect users in ways we can't anticipate. The best we can do is try to prepare them enough and help them answer questions they might have and make them feel supported as they make the transition.
Even when the intention behind the release is to make the experience better for the users or improve efficiency, the users should have enough time to prepare before the actual release happens.
For users who use the platform for many hours a day, they will develop patterns and habits when they annotate, and so when there are updates and changes to the platform, they affect/change the rhythm of their habits. It is important to keep this cognitive effort it takes for the users to adjust and “account” for transition time.

TABLA

For all releases, a timeframe, with some materials(when necessary), is provided for the users to be prepared before they start interacting with the release.
Example:

Building the Appcues.
Copy the template flows that suit the type of release and tweak to fit the content type.
What to include in each?

• Release notes
  • For a more detailed description, since the flow will have highlights, and summary or teasers. PM writes the One Pager and drafts the release notes, and coordinate with Prod Ops to make it to the final version for the users.
• Gifs
  • They pull users in and make them want to find out more about the feature/release/change.
• Demo/walkthrough video <3 minutes.A mix-up of videos going over the feature.
  • For most cases, 1 video will not be enough to bring the users along the journey. Prod Ops will advise on how many are required and what angles/use cases to cover on the videos, and on what stages the videos will need to be ready.
• Release Timelines
  • Release timelines are necessary as they give the user an idea on how to prepare best and how they plan for the release on their end.
• The flows should give express to the users that they are getting some time before the release finally happens, and also communicate to when they should expect the release to happen.
• Connect with Prod Ops on the timelines and activations, and tracking (click throughs, feedback from teams…)
  While releasing
  • Analytics updates on each day of release
    • Connect with Prod Ops, give updates on the analytics, and what to expect or change for the next flow. (e.g, based on the user interaction, should we include a more direct messaging or add a flow/video focusing on something more specific?)

Releases will use the templates available, depending on the type/nature of the release.Here are a few templates that can be tweaked for any type of release, so that a PM doesn't have to prepare everything from scratch, or at least have some reference point while preparing for a release.

Single Flows

Some releases that happen within the platform do not disrupt the annotation flow of the user in a big scale, like how an icon looks or adding a timer to the task TPT.
 

We can achieve this through a single follow with a strong messaging that tell the user what is coming, and when. A single Flow can have 1 or multiple steps, depending on the amount and style of content needed.
 

A few templates here are:
This template doesn't require much action from the user, just for them to be aware of the change so they are not caught by surprise.
This template includes a GIF for the user to follow and see what the change will entail, and the exact dates the release is expected. The user knows there's a functionality they use a lot that is going to move,and where it will be moving to.
This template is great for when we need to take the user through steps, or guide them along so they can understand the feature even better as they read along the flow.

example; A gif showing the journey and what the change would change for the User, and the timelines for release.
 

Another example was the release of 3D cursors to help users instantly recognize which mode they're in—whether it's cuboid creation, translation, or others—making the annotation process clearer and more intuitive.
 

This didn’t require the users to do much preparation, they got the announcement 3 days before the release. This gives them enough time to know the release is coming in 3 days.

 

The goal is not to ambush users with a release that they feel is too sudden.
 

 

 

Multiple stage Appcues Flows

For releases that change things around and carry a considerable amount of cognitive load on the users, giving the users more time to prepare and adjust ensures a smooth transition and for Product to look at analytics to have find out if there are areas of support required even before the release happens.
Preparing the materials for the users in advance and giving them time to get familiar without the pressure to interact with the feature only after release eases the users' mindset.

Example below is a second flow with 2 steps, which also linked a practice project and walkthrough videos

Flow 1 was displayed on the production page, a summary of the release no gifs or visuals ,

 

 

 

 

 

 

 

 

 

 

Flow 2 was displayed on the dashboard page. It had 2 steps, with 1st step non-dismissible to ensure users get to the 2nd step. The 2nd step had materials linked that opened on a different tab. Flow 2 was also non-dismissble.

Flow 3 was displayed on the production page, as a banner, reminding the users of the release date, and a document with all relevant materials for the users to reference at any point. It was non-dismissible, subtle enough that it wasn't getting in the way of any production work, but present through the day to stay fresh on the user's mind so they appreciate the importance of the release.

Mixing the flow styles and targeting helps make the relevance content and the likelihood for the users to keep interacting with the flows and content displayed there, which is what we are aiming for.

 

 

 

Tooltips for user journey 

This template is helps guide the user along the flow, they can follow the steps as they read along the content and take the actions laid out in the steps. Tooltips are a great way to make sure the user doesn't miss steps that might be important in the navigation journey of a feature, or a change that will happen following a release.
Making the tooltips non-dismissable ensures that the user stays along the journey.

 

 

 

Banners Flows

Banners are a great way display a message that is not too wordy, especially when the flow doesn't need visuals or steps for the user to follow.
An example is when announcing that task rejections will affect FRS and once a task has been rejected, shape count will not show up if task goes to another user. The banner can stay up for as long as we want, and link all materials necessary to support the release.
Banners are also a good way to supplement a flow, they can be used as the last flow in a multi stage release to remind users of the release date and enable users to refer back to materials they might need just before the window closes.
 

 

 

Targeting.
Deciding where to display the release preparation material plays an important part in user engagement. Targeting needs to be done on pages that users will interact with the most and spend the most time on.
If a change is happening on the archives page, targeting a message specifically on the archives page might sound ideal but users will only navigate to the archives page when a need arises, therefore prompting the information in the tasks page where users spend more time on will have a wider reach, and there is a likelihood that they will open up the archives page to take a look, in this way they will be interacting with the page at a lesser “urgent” state, and they can consume the content better.
Combining the targeting styles for maximized interactions with analytics from the flows can provide insights on areas that need more content or additional material as the release date nears.
Other communication Channels, like Slack, emails, and individual stakeholders, help promote the content and prepare users for the release.
At the end of the day, the goal is to reach the users, a release should utilise all the resources available to make the release process as collaborative as possible.