Good Questions, Bad Asks: The UX Of Questions In User Onboarding

There are two parts to questions in user onboarding: what questions you ask and how you ask them.

A good question does not equal a good ask.

Let me explain.

As we continue to figure out Chargebee’s user onboarding flow, there are three conditions at play in every discussion (like most B2B SaaS):

• we have a complex problem to solve,
• our solution is built for teams, and
• it impacts (and relies on, to some extent) the intricate tech ecosystem of a growing business.

What these conditions mean is that we have to work questions into our user onboarding flow, no two ways about it.

Whether we want to customize our app, sound more human, or just understand who’s coming to Chargebee a little better, we need user information. More information than a first name and an email id—we need vertical, function, team size, and intent.

We’re talking to people—users, customers, mentors, each other—to figure out how to make sure these questions are good questions.

What makes them good asks, though, will depend on how we work them into our onboarding flow—from how much we can make them matter to users to how comfortable we can make users feel about answering them.  

TL;DR: This isn’t a post about how to ask better questions. It’s a post about how to ask questions better.

Why does a good ask matter in user onboarding?

Mobile applications are best equipped to answer this question.

And this has to do with the precarious position that creating a native experience puts them in.

Here’s Brendan Mulligan, the co-founder of Cluster, explaining why:

“When creating a web app, you’re just building a page a user visits. But when creating a native experience, you’re not only asking them to download something but also probably asking them to give you access to their location or personal data. It’s a completely different relationship.”

Download and access. Two big asks that mobile apps can’t get around.

They’re a given in mobile user onboarding.

No surprise, then, that they are the biggest drop off points a mobile app can face.  

In 2015, an e-marketer study posited that as many as 25% of app users open an app once and never return.

At the 2017 Chrome Dev Summit, Chris Wilson revealed that 90% of permissions in Chrome and Android are ignored.

It was happening to Cluster too. When the product hit the tarmac in 2013, their asks for permission looked like everyone else’s:

And 60% of their users dropped off at the permission screen and didn’t grant them access to their cameras and locations.

Looking back, Brendan says he knew the ‘initial blitzkrieg approach’ of asking for permission wasn’t working and something needed to change.

Here’s why he believed this approach to asking a user for something wasn’t working. When the ask occurred, users had:

• no reason to trust them,  
• no context of why the ask was being made (which made it come across a little too strong), and
• nothing to ease the transition from onboarding flow to ask and back.  

Addressing these conditions brought Cluster’s drop-off rate from 60% to under 5%.

Cluster learned that how you ask matters as much as (if not more than) what you’re asking for.

Here’s what they figured out.

#1 When a visitor becomes a user

When does a visitor become a user?

Upon sign-up? Upon entering an onboarding flow? Upon finishing it?  

Each potential answer is insufficient in its own way.

Sign-up forms and onboarding flows can’t operate as proxies for engaged users.

Josh Dies and Joshua Porter understand this. Here’s a picture from their book called Designing For The Social Web. What they’re trying to drive home is that interaction with a sign-up framework (what user onboarding was called back in 2008) doesn’t necessarily equal engaged.

 

 

Luke Wroblewski references this idea of theirs in his book, Web Form Design. In it, he digs into what a satisfying answer might be.

This is what he concludes: a visitor becomes a user when she knows how your product works and why she should care enough to use it.

In the context of better asking, working with this definition gives us two premises that lend themselves to a strong conclusion:

Premise 1: It’s rarely the case that a sign-up flow successfully converts visitors to users.

Premise 2: A user is more likely to answer a question than a visitor.

Conclusion: So, it doesn’t make sense to ask questions immediately after sign-up.

What’s better, Wroblewski argues, is to gradually introduce your app and engage with visitors until they’re invested enough to give you the information you’re looking for.

Example time.

This is the first screen I see upon signing up for Zendesk:

This is the screen I see before I finish signing up for Intercom:

What Intercom and Zendesk are missing, in my opinion, is an opportunity to engage. An opportunity to turn a visitor into a user before the questions come raining down.

Comparatively, the first time Cluster asks me a question, it’s for permission, and it’s a long time after I’ve signed up, a long time after I’ve turned into a user (or understood how Cluster works and why I should care).

Their request to access my contacts comes after I’ve entered the app, chosen to create a group, and am thinking about whom I should invite to be a part of it.

Luke summarizes: “With gradual engagement, we can communicate what our mobile apps do and why people should care by actually allowing people to interact with them right away.

We can capitalize on all the hard work it takes to get a download instead of turning 75% of our potential audience away with sign-up requirements.”

#2 When a question is helpful

“If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry

Permissions put mobile apps in a tricky territory in more ways than one:

• They make an onboarding flow longer,  
• They break user experience, and
• Most importantly, they’re incredibly hard to undo. If a user says no to an app accessing contacts and then changes her mind, there’s a complicated process of undoing it.  

Getting access the first time they ask for it is critical.

And this means mobile apps like Cluster have to work extra hard to make sure it happens.

The strategy they use to do it: permission priming.

Essentially, permission priming is the process of explaining to a user:

• why an ask needs to be made and
• how responding to it will benefit him.

The hope is that the explanation builds a little comfort (achieved by communicating why) and provides a little motivation (achieved by communicating the benefit).

Here’s Cluster once again, showing us how permission priming can turn an ugly question into a thoughtful request:

Comparatively, here’s Xero’s ask for information:

The questions come out of nowhere.

There are no educational cues to help me understand how telling Xero when my financial year ends or what accounting software I’ve used in the past will influence how successful I am with the app.

And most importantly, the form makes me uncomfortable because I don’t know why Xero is collecting this information.

Is Xero trying to customize my in-app experience? If so, I would love a heads up and I would gladly help out. Is Xero collecting this information so they can sell to me better, on the other hand? If so, I’d like to skip this step for now so I can start engaging with the app.

A question is helpful when it is accompanied with a prime—here’s why we need it, here’s how it will help you.

For another example, here’s Shopify:

For reasons just like Xero, all I’m thinking when Shopify asks me to fill out this form is ‘why does Shopify need to know what my current revenue is?’

It might be that they have great reasons for asking. Without the clue in, though, the question just leaves me troubled.

#3 How to build trust in those first few interactions

Here’s the thing: a question (in user onboarding) can tick box #1 and box #2 and still break the trust you’re trying to build with a user.

This section is about how this might happen and what to do to make sure it never does.

User onboarding is meant to deliver value by either educating, showcasing features, or driving action.

A question can either help deliver this value or get in the way of it. There’s no middle ground.

Let’s begin with how questions in user onboarding can break trust.

Here are the questions Hotjar asks upon sign-up:

Hotjar gets a lot right in this page.

The ‘Let’s customize your account’ headline does a great job of priming me for why these questions matter and giving me context for why they matter now.

I’m invested in providing these answers because I’m looking forward to an experience that’s tailored to me.

The problem?

Hotjar never delivers on that promise.

Once I’m inside the app and exploring it, there’s absolutely nothing to suggest that the answers I gave Hotjar actually had an impact on my in-app experience.

Let’s take Zendesk.

Like Hotjar, Zendesk ticks both boxes by executing a contextual and primed ask once I’m inside the app.

The problem is that it doesn’t deliver on its promise of ‘customized Zendesk support’ (maybe they mean they’re asking for this information so they can help me better when I write in to support. That’s a problem too, however. If you need this information later, why ask for it now?)

In both cases, the questions prove to be ineffectual and end up undermining the effort of the onboarding flow to either educate, showcase, or drive action. Because they don’t impact the onboarding flow, they come across as unnecessarily demanding. Most importantly, though, they break trust. Both Zendesk and Hotjar set up the expectation of a tailored experience and don’t deliver on it.

How to make sure questions never put user onboarding in this position? Reward the user for answering a question with an immediate display of impact. 

Once again, Cluster shows us how it’s done. 

When Cluster asks me a question (in this case to access my contacts), I see the impact of it in the very next step of Cluster’s onboarding flow.

Not only does Cluster ensure that every ask is contextual (with gradual engagement) and comforting (with permission priming), it also rewards users by putting the impact of every question that makes it into a user onboarding flow on display.

To conclude

The more we investigate what separates mobile and web user onboarding, the more blurry the lines become.

Yes, the questions we ask our users are different. 

We’re not asking users to download something, we are asking them to take a piece of new software to a team that (probably) has an established workflow. And we’re not asking users for access to their location, we are asking them how many people they employ or how much money their business is making.

But whether we’re building for the web or a phone, enterprises or consumers, we’re building for people. And people deserve both good questions and good asks. As we figure out how questions ought to figure in the onboarding flow we’re developing at Chargebee, this is our biggest takeaway.

Here are the lessons:

First, use gradual engagement as a compass to figure out when a question must occur.

Second, use permission or information priming to help users be comfortable with every ask that you make.

And finally, make sure that every answer you receive is accompanied by an immediate delivery of impact.