The traditional approach to user onboarding
When software companies reference user onboarding, they are typically referring to the user’s initial experience in the application. The concept took shape around mobile apps, but as more and more business software moved to a SaaS, “self-service” model, vendors began to introduce distinct onboarding experiences for a user’s first visit. These experiences are designed to introduce the user to key features and functions of the application and walk them through some sort of setup or training flow.
These simple onboarding experiences can be helpful, but they typically do not end up being a priority for the product management team for a couple of reasons. First, the onboarding experience is often treated separately from the overall user experience. It’s considered a ‘one-off’ and any updates or refinements often end up de-prioritized on the roadmap. Second, onboarding initiatives are often championed by sales or customer success teams within the organization. Although product management will lead the implementation, they may not feel the same level of ownership or accountability as they do for other features in the product.
As a result, user onboarding doesn’t necessarily get the attention it deserves. The same trends that are driving self-service delivery of business applications are dramatically reducing switching costs for customers. If they don’t realize value quickly or feel that the application is delivering against their expectations, they will churn. Regardless of the breadth of functionality that is available, if users can’t learn it quickly, the product won’t be successful.
A better definition of onboarding
Part of the challenge stems from the fact that onboarding has a very narrow definition for most companies. Rather than thinking about onboarding as the initial user experience in the application, companies should be thinking about it as the process by which users become proficient in the application. This definition is helpful for a couple of reasons. First, it opens the aperture beyond just the in-application experience to understand that onboarding also includes any hands-on help, account setup, and training. Secondly, and most importantly it helps to clarify that onboarding doesn’t just refer to a user’s initial experience in the application.
Tweet This:
“A better definition of user onboarding: The process by which users become proficient in the app.”
It’s definitely true that users will churn if they don’t realize value quickly, but it’s just as true that users will churn if they don’t receive ongoing value. The SaaS business model is built on the idea of recurring revenue. Customers must renew and expand their usage for a product to succeed in the long run. This means that product managers must consider how they deliver additional capabilities at a velocity that meets customer expectations for both actual and perceived value.
Implications for the user onboarding experience
Along with all this ongoing capability delivery, products must also be able to provide ongoing onboarding delivery. Added functionality is of limited value if users are unable to discover, and learn how to use it. This means that product managers must think through how to add more flexibility to the onboarding experience. Taking over the UX for an introduction and initial walk-through is fine (if not ideal) for the user’s first experience, but it definitely isn’t a workable approach for every new capability that is introduced. Also, if onboarding truly doesn’t end, product teams need to address how to handle the volume of onboarding content. Adding too much guidance or training to the user experience can add clutter and ultimately degrade the customer experience.
An effective approach is one that customizes both the onboarding content and the delivery to the user’s context and learning style. User context includes behavioral and demographic information such as:
- Time spent in the application
- Features used
- Previous onboarding/guidance viewed
- Functional job role
- Application role (i.e. admin vs regular user)
This information can be used to target onboarding content to the users that it’s most relevant for. As a simple example, you probably wouldn’t want to offer help about a particular feature to a user that has already used that feature several times. The offer would merely be intrusive. This same principle applies to content a user may not have access to. If their plan level or role in the application prevents them from accessing a feature, any help for that feature should be hidden from them as well. By limiting content like this, product managers can ensure that their onboarding experience is as relevant as possible, and doesn’t unnecessarily clutter the user experience.
Supporting different learning styles is often addressed by offering content in a couple of different formats. For example, onboarding content can be delivered as:
- In-application walkthroughs
- Instructional videos
- Written documentation
- Training classes
All of the methods might be preferred by different segments of users. Once a base set of onboarding content is developed, it’s not a significant burden to surface it in a couple of different formats. Product teams can test several different formats or combinations of formats to see which ones are consumed the most by users.
Considerations for the product roadmap
How should the need for continuous/constant onboarding influence the product roadmap? Ideally, onboarding requirements and measurements should be included with every item on the roadmap. That way, when the product team is prioritizing and scoping features, they can consider the time and effort involved in training users about the feature. It also ensures that a feature is not considered complete if the content and the approach for “onboarding” users into that feature has not been developed as well.
Tweet This:
“Onboarding requirements and measurements should be included with every item on the roadmap.”
Metrics around onboarding should live with the overall feature metrics. Often, usage goals will overlap with onboarding outcomes – i.e. a successful feature and successful onboarding will result in a high-level of feature usages and possible increases in user satisfaction. The key is that the onboarding experience should be evaluated alongside the feature itself. This allows the product team to constantly measure not only the pick-up of the feature but the engagement with the relevant onboarding content as a part of their retrospective process.
Embracing onboarding as an ongoing process
It’s easy to treat user onboarding as a one-off experience that doesn’t need continued investment, design, and attention; but in today’s world of SaaS and recurring revenue business models, product managers do so at their own peril. The reality is that in order for applications to be successful, their users must realize value quickly and continuously. The only way to support this is through ongoing user onboarding. Product teams that embrace onboarding requirements and measurement as part of their roadmaps, and who work to customize onboarding content to user context and learning styles, will come out ahead.
About the Guest Author
Michael Peach is the Head of Product Marketing for Pendo, where he leads messaging, positioning, and launch activities for Pendo’s product success platform. Prior to joining Pendo, Michael was the marketing program director at IBM where he led marketing and demand generation initiatives for their mobile, application integration and business process management portfolios. He has also held product management and business development roles for several small and early-stage technology companies.
