When designing a feature onboarding flow, remember to:
Create a new feature release timeline with clear parameters and an appropriate ramp down plan:
Don't forget to check coinciding feature releases on the same page.
Sequence tasks in a logical way to increase onboarding success. Clearly define when a user starts and successfully completes an onboarding flow.
Treat feature onboarding as a story or a journey with a beginning, middle, and end.
Use empty states or alert banners to call attention to a feature if users may discover the feature when starting a task.
Use teaching bubbles or other easily dismissable elements if users will discover the feature when they are completing another task.
Example of a checklist.
Example of a toast.
A teaching bubble is a popover that calls attention to a feature in a specific part of the page. Generally, teaching bubbles should be used to educate the user and enrich the task at hand.
Teaching bubble Figma sticker sheet.
|Generally, use a descriptive dismiss button over a close icon. "OK, got it" is the default dismissal button copy.
|Use a close icon for condensed messages. Remember to apply the correct tab order for screen readers to easily dismiss the teaching bubble at the end of the message.
|Invite the user to engage with the value proposition promised. Include dismiss as a secondary button as "OK, dismiss". Additional links that takes the user to a new page should be linked from the text and must open in a new tab or window to prevent losing the user’s context.
|Use emojis to inject personality into the message.
|Use pictograms to represent the feature.
|Illustrations and gifs
|Visually communicate or demonstrate a complex feature with illustrations and gifs to supplement a message.
Inline feature discovery is a way to highlight features without obscuring other parts of the page while a user may be performing an existing task.
Use page banners for announcements that are relevant to the core task on the current page. Remember to consider using other feature announcement patterns or marketing strategies instead of disturbing the user with multiple announcements.
Include a clear way for users to dismiss a page banner and clear campaign parameters.
Call out a major feature or change in a page with an invitation to engage and a clear way to dismiss.
Don't use a page banner to disproportionately highlight a small feature.
Use inline banners in a page with multiple steps or actions.
|Inline feature banner
A short introduction to the Wiki feature while configuring repository settings.
|Organization, repository, or user settings, where a feature is managed and customized, inline alert banners can highlight relevant features that may help better accomplish a user’s task.
Discovering the Profile Readme when creating a new repository.
|Sometimes features can be hidden for users to discover. Show a Primer alert at pivotal moments to signal the user they're on the right track and provide more information.
Use empty states as an integrated way to onboard users to new features. Read more about empty states.
For special occasions, a first time experience may be more unique than the typical blank state. Take a more branded approach to engage and guide the user through complex experiences. Be aware of how the experience will change once the first-time UI is no longer there.
GitHub Actions branded first-time user experience
The designated feature discovery areas are generally detached from where the feature actually lives and have a clear click-through for the user to try out the feature or to learn more.
The top of the right sidebar in a user’s dashboard (logged-in home) is a designated area for feature discovery. They take the user directly to the feature in the product or the relevant marketing page.
When using a dashboard feature bulletin:
An announcement about GitHub Teams in the feature preview bulletin leads to an off-platform marketing page.
Feature previews allow teams to test features in production with users who opt in. A feature under the beta preview will be added to the Feature Preview dialog, accessible through the user dropdown.
Note: Features in beta testing should have a comprehensive release and redaction plan. No feature should remain in beta for longer than 2 months unmonitored.
Labels are a softer way to accentuate new features without derailing the user from their primary task.
Consider using standalone labels for features that appear in a user’s current view but may navigate away from their current page to fully engage with the feature.
If the label is not part of a navigational item then it's important to include a
Give feedback or
Learn more link to collect info on how the changes are perceived by the user.
Depending on the size and impact of your ship you might only release to a fraction of users.
There are currently 4 main lifecycles:
Beta (Private | Public | Limited public),
General audience (GA) and
Alpha lifecycle is often referred to as a
Staff ship within GitHub.
|Required (unless navigation)
Give feedback link
|(Private, Limited, Public) Beta
|Internal and external
Give feedback link
Give feedback link
Learn more link
We recommend gathering feedback through a discussion to enable seamless follow-up with the user. This discussion should specify the changes made, providing clarity to the user about what's new. In case of deprecating a feature, it's crucial to provide additional information through our documentation. Note that features that were never promoted beyond the
Alpha lifecycle do not need to go through a deprecation lifecycle.
It's important to stick to the correct terminology and label color when referring to a lifecycle.
Use the correct label and link color
Don't change the label or link color