May 1, 2019

Don't Waste Time On User Onboarding

Dan Hulton @DanHulton

I've noticed a few questions in the past while on this site and others about what the best user onboarding frameworks/plugins to use. Generally, this is based on the idea that what's really holding users back is that they don't know how to use your service, and the one thing that can fix that is a sequence of flashing arrows and tooltip text.

This is very rarely correct.

There are a great many things that you should be spending your limited time on long before spending time encasing your existing UX in a tour. If you don't, you're missing out on some very simple and powerful improvements you can make to your service, as well as making yourself less agile. Imagine what happens when you want to add or remove a feature to your product, but you've got a big heavy tooltip-tour in place? You have to devote time to updating the tour as well as the feature, and if the feature changes in the future, so too must the tour. You're slowing yourself down, potentially before you're ready to commit to winning designs.

I put together a whole list of things you should be paying attention to before trying to decide what tooltip framework is the right one for you: https://greaterdanorequalto.com/dont-waste-time-on-onboarding/

It's like trying to run before you can walk, or before you've looked where you're going. Sure, you may get there quicker, but you'll get there bruised and hurt, and did you really want to be there in the first place?

Would love to hear your thoughts.

  1. 2

    I think "product tours" are not just a waste of time but result in poor UX. My view is that your UX should be good enough for the user to intuitively figure out how to use your product.

    Personally i always dismiss overlay tours/tooltips and find them an annoyance.

    Onboarding can take a different form however and must be part of the sign up flow.

  2. 1

    I think this is a worthwhile contribution, but as usual, I think the truth is: "It depends".

    When I started, we had difficulty getting many users to first success. Tips about watching users, using hotjar to track user activity identified areas of simplification which was great and scalable. I wasn't interested in permanently unscalable solutions like concierge setup although we did that to learn.

    I don't think our service was inherently intuitive to our non-tech customers as it required new ways of thinking and doing. Think of Zapier.com where the website is just to set things up, but the service is invisible, in the background and driven by user actions in other applications.

    In our case, simplification wasn't sufficient and with a few in app and via email tips for those that got stuck, success rates and conversions improved.

    1. 1

      I definitely could have mentioned lifecycle emails, but I also could have mentioned a few dozen other things as well. Had to cut the list down to a more manageable size. I expect to keep writing a lot about this topic going forward though, as it's really very broad.

      1. 1

        Agreed. You're dealing with the ROI on time and attention. Would be interesting to segment those case types where the ROI might be higher or lower.

  3. 1

    I think it’s important to note that this would not be the case at all if the onboarding is a critical part of the user journey and isn’t required to get you into the right “state” to get started.

  4. 1

    What other things should indie hackers avoid? Or what would be the ideal minimum set of things to start with as a foundation?

    I guess in projects you have scope creep, onboarding could be viewed as something that creeps into your software. Or we could call it marketing creep? :) Before you know it, you have to manage so many tools, so much content, then it becomes a job within itself to maintain it.

    1. 1

      I’d say billing integration before you have any customers is a total waste of time.

      1. 1

        I'd caution people here with this advice. If you can't collect money then you don't have a business. One of the biggest mistakes I've made in past side-projects was not building in a billing mechanism early on, which turned into never having one. It's so easy to get caught up in other areas of concern and ignore billing.

        Marketing and finding users is so hard, if you manage to get anyone to visit your site and 1% find it useful enough to pay you, and you're not ready to receive their money, then you failed.

        If you're not heavily marketing your site, then maybe sideline billing for a temporary amount of time, otherwise you need to work on how you will charge customers.

        1. 1

          There's definitely different ways to do billing than an on-site integration, though. You can send invoices and set up subscriptions directly through Stripe and PayPal, and if you've been working directly with the customer (like in Enterprise sales or very early-access services), you probably won't even upset anyone that there's not a "proper" section of your site to do billing in.

          I can see it being a very easy way to save a bunch of work while trying to evaluate/refine an idea.

          1. 1

            I can see how that would work in enterprise. Thanks for your response, it broadened my ideas on billing, I almost always experience an integrated experience, and provide the same on my SaaS product.

            As long as you have some plan for billing and it works for your potential customers, then you should be good to go.