Talking user onboarding with Samuel Hulick

Through his detailed and witty teardowns of the new user flow of popular products like Instagram, Netflix and Snapchat, at useronboard.com, Samuel Hulick has become the go-to authority on onboarding.

When I interviewed him recently our conversation covered everything from potential conflicts between product owners and users, to what video games can teach us about onboarding.

What follows is a lightly edited version of the interview but you can listen to it in full.

Increasing the chances of success

Des: Most of our readers will be pretty familiar with a lot of your work at useronboard.com. To get straight into it, what do you define as onboarding for a product?

Samuel: My definition of onboarding might be a little bit different than a conventional one. I define it as any time there’s an opportunity to increase the likelihood that users are successful when trying to adopt your product. It’s not just an intro tour or design patterns along those lines, but basically any time that you can close a gap between somebody who’s seeing what they can be capable of with your product and actually being successful with it.

Des: By that definition, does onboarding ever stop?

Samuel: A very simple example would be if somebody has been using your product for six months, they’re totally up to speed, and you release a brand new feature that’s going to significantly increase their abilities. That’s an onboarding opportunity there.

Your product and company as a whole exist in order to make people successful in a specific way. Anytime there’s a way you can be making them more successful, there’s an opportunity to onboard them even further.

Des: A lot of customer success teams would focus on teaching the customer to get the most out of the product. Is that conceptually in your head onboarding?

Samuel: I don’t see a real need to draw a distinction between in-app onboarding and “outside-app” onboarding. One onboarding tactic that I think is criminally underappreciated is a lifecycle email setup, and using each email to get people back into the product. Not just getting them through their next activity, but also building habits around becoming ongoing users with their second visit, third, fourth, fifth, and so on.

Likewise, you can start helping people become successful long before they sign up. That’s typically considered to be “marketing” but could easily fall within the onboarding continuum when you define onboarding as helping people switch to your product.

Des: Are there any general trends you’re noticing here?

Samuel: Well, concierge onboarding is something that I’m seeing getting more and more traction. That’s really something that historically has been reserved for people that are identified as being higher-value accounts and associated with more of a high touch sales process, as opposed to providing that level of white glove treatment to people who are signing up whether they really show strong signs of being high value enterprise-level customers or not.

Another trend I’m seeing is generating an environment that’s conducive to people getting value out of your products, something like forums or communities, where disparate people can be helping each other and having a compound effect on the value you deliver.

Webinars are another thing that I see people leveraging all the time. That’s something that scales really well, and it’s a repeatable process on your end. It’s a great way to maximize your own internal resources while still earning loyalty by providing a high-touch experience.

Teaching versus configuring

Des: A lot of onboarding blurs teaching the user how to use the product with how to configure the product. Should they sit together, or in the user’s mind are they two different things?

Samuel: I would actually group those together as being more similar than different. The distinction I really make as far as onboarding is concerned is: are people making progress in the goal that they were hoping to when they signed up for your product? For example, if they sign up for TaxSlayer, are they getting closer to having their taxes filed? Or, if they signed up for Basecamp, are they getting closer to managing their projects well? Or, in Intercom’s case, are they getting closer to being able to talk to their customers better?

As far as onboarding, defined as “introducing users to the interface”, is concerned, typically that’s not something that people are going to wake up and really be highly motivated to get better at during their day. They really just want to get better at solving whatever their problems are with the least amount of learning.

Des: Are there times when onboarding ends up at a conflicted crossroads, where a business wants a user to do one thing, e.g. enter your credit card now, whereas the user is not ready to do so, or actually wants something different?

Samuel: Anytime one person is charging and the other person is paying, there are probably going to be goals that aren’t necessarily 100% aligned. Of course, it’s better when they are.

Some onboarding-specific examples that come to mind are when there’s the “spam your friends” part of the signup process, where you’re going through maybe a wizard and then it says to enter in your email address, or your Twitter account, and then blast this message out to everybody. It’s not necessarily in the user’s best interest, or it at least doesn’t get them a lot further in terms of what their personal goals are. At the same time, it might be helpful to the company with what you might call growth hacking or a viral factor or whatever. The more you can link your success to your users’ success, though, the more likely that the energy that’s driving the experience — the user’s motivation to solve a need — will be flowing in the right direction.

Des: Do you remember onboarding in the Web 2.0 era, which was very much about a button tour, where tooltips showed you each button on the screen.

Samuel Hulick: Right. Speaking of Basecamp, Jason Fried a long time ago started a Flickr group called Signs on Signs where he would take pictures of, say, a sign in a library that for whatever reason wasn’t getting noticed, and where someone had pasted another sign pointing to it to draw attention to it, instead of making a sign that worked. He had a fun quip which is that he liked it because “it’s literally people pointing at bad design.”

If your product is so confusing that people can’t understand how to use it, and that you need to layer on more interface that literally just repeats what the interface it’s pointing to says, obviously there are a lot of issues with that.

Supporting the user’s definition of success

Des: I feel a lot of the work you praise understands the user’s definition of success and designs an onboarding experience to help them achieve that.

Samuel: I would say that’s a very good way of putting it, especially if we’re going to continue picking on tooltip tours. Another drawback with them is that they’re not necessarily accomplishment-oriented. They might have you go through seven or eight steps, and you’re tasked with trying to reverse-engineer what sort of scenario you would be in where that button would be relevant for you, and then try to remember what those eight different scenarios are for future reference when you actually might wind up needing that knowledge. That’s instead of saying “we know what the very first thing that you should be doing is, so jump into this right now, we’ll come back when you’ve finished that”, or something along those lines.

One thing that I’ve very closely studied in terms of onboarding experiences are video games, which have been around a lot longer. Anybody who might remember growing up with the original Nintendo games, sometimes they came with a 100- or 150-page booklet that you were supposed to read, because just getting started with the game itself was going to be a confusing and miserable experience. Looking at the evolution of the intro book turning into more of a tutorial where it would say to jump, press A, to run, press B, and things like that was a better way to do it, because then people were actually participating and taking action.

Where things really take off from a video game education standpoint, though, is when you mix the tutorial throughout the game to the point where it became indistinguishable from actually playing the game itself. That’s what I really aspire to from an interface design standpoint. If your SaaS product can be so intuitive and so well-considered that you’re getting people to gain mastery without even explicitly realizing that they’re being taught, that’s really the ideal.

Des: One thing video games do is just-in-time education. The complexity of the game arises from the fact that they only teach it to you once, and it’s up to you to remember that for the future.

I guess with SaaS products we’re not trying to deliberately make these things puzzles, but at the same time we can’t overly annotate the interface and explain every single thing all the time, because the product would become unusable. Right?

Samuel: Sure. The best approach I’ve seen is to really spend more time handling blank states — the times when the parts of your interface are empty or unused. Instead of starting your design process by fleshing out a dashboard with six months worth of data in it, design it for what things look like on the very first time that you log in. Or after one day’s worth of use. Or one week’s worth of use. Incrementally getting people through that timeline and designing for that on purpose, as opposed to just kind of going back at the end of the product design cycle and backfilling at the 11th hour by throwing up a message like “there’s no data to show, come back later”.

Blank states and the love of data

Des: I think designers when they sit down to design products, fall in love with this world where not only is there enough data there but the data’s really interesting as well. One technique you’ve seen used a lot lately is this idea of using educational content as the blank slate. I’ve seen this done, say, in task trackers where they say step one is to complete this.

Samuel: Blank states are an opportunity for you to provide a warm and human experience to your product, instead of literally saying, “Your dashboard is empty and that’s all I’m going to say.” That’s not something you would say in person with the customer, so why would you have your software say that?

Slack, for example, will not only have fun and punchy things that it says to you as it’s loading up, but it also walks you through the experience of using Slack in a very affable and personable way that people have really connected with. It’s not just a matter of being helpful, or informative, or educational, but also being warm and welcoming. I’s a great opportunity for you to help forge a relationship early on so that there’s a much higher likelihood they will get to the point where they can have that data six months down the line.

Modelling the long-term customer

Des: It’s popular now for people to look at their database and find what looks to be a great set of users. They might say it looks like people after they hit seven friends, they start using our product, so all we need to do is get everyone to hit seven friends. Is there too much correlation and causation going on there?

Samuel: I’m much more for it than against it. I think that there’s a lot of low hanging fruit as far as user behavioral data is concerned. Even taking the perspective that the customer is rarely buying what the company thinks it’s selling, are there inventive ways that people are using your product that never occurred to you and strongly correlate with people getting success out of it? Those are great things to know, just because it helps inform your product design.

However, on the flip side, let’s say you run the numbers and see that people who contact customer support are six times more likely to convert to paying customers, it doesn’t mean you should try to railroad everybody into talking to customer support. Maybe that’s really only correlated with the people who are most motivated to convert for your product to begin with, and is not necessarily going to be a high-value step for everyone.

Des: One thing that can easily be forgotten is maintaining onboarding? How often do you revisit onboarding? Should it be a part of every project?

Samuel: Your “product” is not necessarily the software that sits on a server; it’s how you make people more successful. It’s just a matter of reliably getting people from A to B in their life, which also requires getting people from A to B in your product. As your user’s needs change and your product evolves, your onboarding should evolve along with it.

That’s a bit idealistic for many traditional companies, though. It’s typically very difficult to get onboarding resources allocated within a company whose Marketing and Product departments aren’t focused on the entire customer experience. Something that I point to is Conway’s law which wasn’t really designed for this scenario, but I’ve adopted it. It is, in short, that what a team produces will be organized in a way that reflects the way that the team was organized. If your company doesn’t have any departments or roles that are organized around new user engagement, it will probably be very hard to get onboarding projects off the ground.

Des: You take over a product tomorrow. Let’s say the product has 100,000 active users. You’ve got 2,000 users signing up every day, but less than 40% of those users are returning after their first session. Where do you start?

Samuel: I would start by getting organizational buy-in and a high degree of consensus around the specific way the customer’s lives are improved with the company’s product in it. I’d boil it down to a one-liner everyone could remember: Basecamp helps people become better at project management. Intercom helps people become better at talking to their customers. Evernote helps people become better at remembering things. That’s the context around which all the resulting onboarding should flow.

I’d then become very clear on which actions highly correlate with people finding success. I’d then look at all the reasons that people would be going off course or not really being able to make it through a given workflow. So, paying close attention to analytics and diving into the metrics, what is it that’s causing 60% of the people who sign up to never come back again? It may be the first run experience but the end goal for that is unclear, or maybe it’s too ambitious to be accomplished in a single sitting, things along those lines.

I would dive into running the numbers and seeing what the success rates for all the different actions are, and see how highly they correlate with people returning to the product and continuing to get value out of it. Creating an experience around those core engagement-driving actions is key to guiding people to the life that they want to lead.

The 3 Most Important Customer Moments

Des: Would you talk to any of the failed converters, anyone who did sign up but didn’t return?

Samuel: The three moments in the customer experience that I like to pay the most attention to from a user research standpoint is when somebody first signs up, when they convert, and when they cancel.

For signup, I just try to get an idea of what the user hoped to get out of it and what they thought they were even signing up for. Another question I like to ask people at this stage is you might’ve been thinking about this for a couple of weeks or a couple of months, but for whatever reason today, Thursday, November 13th, was the day that you actually did sign up for this product, so what was the thing that tipped the scales? I wouldn’t use the term external trigger, but basically what was the external trigger that caused you to think, “Today is going to be the day I do this”? There’s a lot of background in Jobs-to-Be-Done, switch interviews, and similar methodologies there. That’s one area that I look at.

Another area that I really look at is, let’s say you have a free trial, and somebody converts to paid, or if you don’t charge for your product, whatever engagement proxy you might have where you say, “Okay, this person has crossed the threshold where they’re going to be an ongoing user for a very long time.” I’m really looking to find out what things they accomplished that made it a total no-brainer for them to continue using the product. If we were to take away one or two features, what would you have really missed the most? Or going through the experience, what was a time where you almost didn’t make it all the way through, and what almost prevented you from doing that?

The last one is, as you mentioned, cancellations, just getting an idea of what they thought they were going to get that they didn’t, or what could have been done to make it a better fit. That’s probably the lowest signal-to-noise ratio area of the three. A lot of times it’s just that their company went under, or that they are moving to a different company, or things like that, which is fine. Still, though, it’s an opportunity to get some information you wouldn’t otherwise have. It’s super easy to set up post-cancellation surveys, etc.

Des: Just to wrap up, I know people can follow you on Twitter, and they can also go to UserOnboard.com, but could you give us an overview of what people will find in the book?

Samuel: It’s a super hands-on, soup-to-nuts guide to evaluating your entire onboarding experience. People go to useronboard.com and see the tear downs, and they seem to really like the insight they provide around specific onboarding experiences for some popular products. The book lays out an underlying philosophy for how you can take on a similar mindset to approach your own product’s onboarding. It’s very much what I provide one to one as a consultant in an afternoon or more, condensed down into book form.

About Samuel

Samuel Hulick is a long time UX consultant with an intense focus on user onboarding. He’s the author of The Elements of User Onboarding, and also the person behind UserOnboard.com, a growing collection of teardowns of popular web apps’ first run experiences.

Intercom helps web and mobile businesses with their user onboarding providing features like lifecycle emails, personalized customer support and in-product notifications.