I get that there are probably established best practices that people follow for designing onboarding but I've never experienced one as a user that I didn't want to immediately dismiss or skip through.
This is why I have a certain distaste for articles like this. The author has this sort hypothesis / contention, specifically that user onboarding is a waste of time, yet presents no data to either validate or disprove their hypothesis. We're supposed to just accept their hot take as gospel, where as folks like yourself can offer actual data that serves as a compelling counterpoint.
I dunno that it's a counterpoint. The thesis of the article is that setting up a user onboarding flow before you're ready is a waste of time, and/or that it's not as useful an activity as others you could be doing with that same time.
I'd consider Polar a success of "adding onboarding when ready." I just don't want people to consider onboarding as the first and only tool to reach for when trying to fix your Trial-to-Paid Conversion issues. There are a lot of other useful tasks you could - and frequently should - be working on as well.
Because everything has onboarding now. Sometimes it's unskippable (think mobile games). It's always annoying, very frequently patronizing, and, frankly most people's app/site designs aren't that special because modern UX seems to have no more than a handful of designs for how tech is to be spoonfed to the masses.
Of course none of that matters because it makes another tiny, self-selected group considerably more money.
This is really interesting, because Polar is the first onboarding experience I've had in a really long time that made sense and wasn't extremely annoying.
> About 50% of our users completely skip the onboarding altogether.
How is this different than when you had no onboarding? (serious question) Did you make other changes that made the onboarding process less important to end users?
You separate people in those willing to explore and figure it out on their own, and those who'd otherwise probably never check further than the home page on their own. In my experience the biggest gain from intros is that when you get people into entering some basic data - creating an example project or something - they feel like they've already invested some time and are much more willing to explore the features further and enter more data and eventually really start using the app.
Likewise. However, it’s worth remembering that the average user of a website that’s called “Hacker News” is almost certainly more tech-savvy than the average user of any app we create.
My solution is, just as the article suggests:
> Okay, so your service is immensely easier to navigate since you ran it past a battery of theoretical users. Now cut half of it out.
Perhaps that applies no matter how big the app gets, perhaps a simple UX that hides the power tools until they’re called for is the one true way. On the other hand, virtually every time I’ve faced a user saying “$App should perform $Task”, it already does. Sometimes the app doesn’t have a particular feature, but the virtual assistant of the OS does.
What’s the best way of helping those users discover those features?
It's more for the "onboarding" session that you'd cut half the app out, I could have made that more clear. The idea is that you're looking to sprint to value, to get the user's eyeballs on the most-important part of your service ASAP. Otherwise, they don't stick around to explore and find all the power tools. In normal usage, you should definitely have an easy way to find and use all features, but that's a broader product design question, not an onboarding one.
If you can skip it, it’s probably not designed right. Well designed onboarding should answer the questions you might have right when you have them, not before you even know that there is a question to ask. It’s not rocket science, but it takes some thought. Design empty states that make it obvious how to use a screen and what it’s for, always have a clear “main” action that will have a productive outcome for most users most of the time, and make sure to have a clear and consistent way to get well designed help that is relevant to what you currently see on screen (can be tricky to do on small screens, though).
That said, traditional onboardings have their place, for example to introduce new features. Even if you skip them or click through and only skim it, you might still pick up enough of a heading or illustration to make it easier to figure out why things are different.
If a product wants me to go through a lengthy onboarding session, whether it be with a representative or through some guided tutorial it's an immediate turnoff and I will likely abandon right then and there.
Personal anecdote:
We were evaluating Cisco AppDynamics last year as we were in the market for an APM product and, unfortunately, we are a huge Cisco shop. They wanted to hold our hand and walk us through everything, and the product was certainly in a state where I can't blame them - the agent sucked to deploy, they had a nice little UI to configure things during install but after that it was all editing XML. Sure, I could automate it all with Ansible - but you could tell they knew the UX sucked and they just wanted you to get through the onboarding quick and hope you didn't notice.
We ended up purchasing Dynatrace instead, I started a trial with no intervention from sales reps. They made their happy onboarding path a "game" (they have "quests" in the UI to guide you through the various parts of the product) but otherwise threw you right in with no handholding. The agent was stupid simple to deploy (here's a manifest to deploy to OpenShift, here's a .msi to install on Windows) and it picked everything up automatically and started working. Figured everything else out by just playing with the tool, with the docs as an aide.
// End anecdote
I think onboarding has a place, but it shouldn't hold a user hostage. I really liked Dynatrace's approach, especially as the "quests" were covering different components of the product and could be tackled in any order - they also weren't guided tours but instead directed me to investigate other parts of the tool and perform certain actions, even providing a carrot (free credit) for completing them.
This is a problem I've run into anytime I'm purchasing "Enterprise" licenses for software. They always want you to contact a sales rep, talk to an integrator, set up a meeting to discuss your needs. My NEED is to pay via Purchase Order...
There was never an enterprise licensed software that didn't involve multiple meetings. The software was the same software we had already integrated in the development environment, we just needed licenses for production. Didn't matter that we'd been using the software for ages, they still wanted to set up hours of meetings before sending us an invoice.
Same. 9 times out of 10 I don't want to learn a new tool, just use an intuitive, predictable UI. If I need to "read the instructions" first, your app is probably trying to do too much.
Keep it simple and only use onboarding if your app is truly novel.
