What other product folks said about user onboarding

Over the last few months, I asked different people who work on products in services, in a variety of industries, to share their perspectives on user onboarding. While I’ve heard from many people over the years, I wanted to ask a few pointed questions. Via questionnaires and interviews, 48 people* shared with me the challenges they faced in trying to create a good user onboarding experience, the goals they felt user onboarding needed to achieve, and how they defined the scope of it. My goal was to understand the range of perspectives different people have about user onboarding, and find common themes. In the spirit of sharing, this post is a lightweight recap of what stuck out most from these conversations (and I’d love to hear if your perspective is similar or different!).

There were multiple definitions of user onboarding

I asked people to describe what user onboarding meant to them, to get an understanding if everyone holds a similar view. Definitions included:

An introductory sequence of screens, a video, or a tutorial during first use is the description that dominated responses. From a UX designer in the edutech sector: “To me it’s that clickthrough sequence of screens. That’s what I think of when I think of onboarding.” But it was also cited that “too many people say to just make a video.”

Human help also came up a handful of times, but not necessarily in a positive light. One product professional who worked on an enterprise suite of products said their company relies on sales and client services for onboarding: “[There’s] legacy thinking around the company that you can get around ‘good [in product] onboarding’ by relying on human solutions.” Another person said you “can’t rely on humans to do this; if it’s important, make it obvious.” On the other hand, someone pointed out that a conversation is what onboarding should be like, which tends to only happen in more human-based interactions. No one likes a “wave” of information that isn’t relevant to them at the time.

Informational content embedded into existing product flows. A few saw onboarding as present in the core product design. “I think I’m loosely interpreting onboarding […],” said a designer who works in the government and social good sector, “We’re using our contact form as a way to introduce folks to our brand and set expectations, which feels a little like onboarding.”

People assigned different types of goals to user onboarding

I also asked folks what the goals of onboarding were for their product or service. This provided another way to gauge how narrowly or broadly folks defined the role of user onboarding. These clustered around 4 major themes:

User trust and achievement goals: The most common set of goals cited (perhaps influenced by the strong representation of UX designers in the folks I spoke with) were those around making it easier for users to achieve their immediate goals when they first came to a product. Some felt this would mean the goal of onboarding would be to learn and adapt to a new user’s needs, and building their trust.

“Orientation”-related goals made up the second-most cited group of goals, which included aspects of teaching users about the interface or increasing awareness of features. One person described this as instilling “confidence” in their users’s abilities to pick the right tool for the job they needed to do. But it was also described as just getting people to use a feature that the product team wanted people to be using more.

Goals around meeting business metrics made up the third most-cited group, with increasing user acquisition leading the pack followed by improving product satisfaction, reduction of customer support costs, and increasing user activation.

Notably, goals around common setup-related logistics (like creating a profile, setting up functionality, or gathering consent or permissions) weren’t heavily cited, even though these kinds of things tend to be present in many of the first run experiences that comprise part of user onboarding.

In general, responses reaffirmed what I knew about onboarding’s goals needing to be tailored to the product and user, instead of being generic. For example, a developer of a prepaid game said, “My success criteria is ‘do users know how to play the game’,” which they sought to learn by checking app feedback for gaps in satisfaction or issues. Meanwhile developers of freemium games might expect onboarding to increase upgrades to paid offerings. And onboarding goals might vary based on the state of the user, such as onboarding new users to a product vs. onboarding existing users to a new version of it.

Many said their product’s current onboarding experience wasn’t as effective as it could be

Although most people said user trust and achievement were the top goals for user onboarding, in practice they said their onboarding experiences over-emphasized product orientation activities, like showing people the interface, raising awareness of features in the product, and teaching people how to interact with it.

Few of the folks I spoke with thought their product was effective at either helping users meet their goals, or in meeting long-term business metrics like retaining users. There was a gap between the goals they held for user onboarding and the approaches they used to address it. The over-emphasis on product orientation activities might be explained by many people holding a too-shallow definition of onboarding, in making an assumption that raising awareness of features is enough to drive engagement or retention, or on other challenges, which I asked about next.

3 types of challenges were cited as barriers to effective user onboarding

So I asked people what challenges prevented them from building an effective onboarding experience, or reduced the efficacy of a design. Everyone cited multiple challenges, and the majority of these responses fell into 3 themes:

Prioritization-related challenges were the most selected (in questionnaires) and the most provided, unprompted, in conversations. These included things like:

  • Stakeholders not prioritizing user onboarding
  • Competing requirements
  • And, likely because of those two factors, “not enough time” for the team to build it well 

Complexity-related challenges made up the second group of challenges. These included issues like: 

  • An onboarding design being too hard to customize for different users
  • An ideal onboarding design being too hard to maintain
  • Not having the kind of technology they felt they needed to implement the onboarding they’d envisioned

Complexity-related challenges also came in the form of lack of decent integration with their products. Only about a fifth of people I talked to felt that their product’s onboarding experience was well-integrated into the rest of their product. A poorly integrated onboarding experience can not only be disruptive and off-putting to new users, but can make an onboarding experience harder to scale over time.

Expectation- and evaluation-related challenges comprised the third most cited group, which included issues like: 

  • Not being able to effectively research onboarding
  • Getting unclear goals from stakeholders
  • Not having a unified definition or measure of success

Takeaways

Even in a small group of those who work on products and services, there were different definitions of user onboarding, different perspectives on what it should achieve, and different ways of thinking of it as successful. Several of the challenges people said they’ve faced in designing better onboarding can be avoided by aligning your team before you begin. 

  • Get a sense of where the key members of your team stand today by asking how they define user onboarding, what goals they have for it, and how they’d define success. 
  • From there, build a broader, shared definition of user onboarding that focuses on longer-term business and user goals: check out this article on building onboarding for the long term for an overview. 
  • Align on how you’ll evaluate its success. This way, you can make tradeoff decisions early, instead of leaving a half-finished design on the table late into product development.
  • And don’t just reuse a technique you saw in another product or service, because you don’t know if that team held the same goals for user onboarding that you hold for yours.

*Notes

The people I heard from: Primarily, I heard from UX designers, Product Managers, and UX researchers; they made up approximately 3/4 of the respondents. The remainder included developers and marketing professionals. The folks I heard from worked in a wide range of industries, including: consumer apps and websites; consumer hardware; social good and government; education services; enterprise products; and gaming. I heard from people via a questionnaire, as well as conversations and interviews. Some folks chose to respond only via a questionnaire, some folks I only spoke to in person, and some people participated in both.

This wasn’t a quantitative research study so responses will not be presented in quant terms. Also bear in mind that a selection of 48 respondents, even from a range of industries and countries, is unlikely to contain the full breadth of perspectives on something as big as user onboarding, especially since participation was self selected. Instead, take away from this that there *are* a range of interpretations as to what user onboarding means even in a sampled group, and that you, too, might be facing wide variance in how people interpret the task of building user onboarding for your product.