#BiteSize is a video series where leading experts answer some of the most pressing questions entrepreneurs have while building or marketing their startups.
In the latest episode of #BiteSize, Samuel Hulick talks about the key components of user onboarding for desktop vs mobile and B2B vs B2C products.
Samuel Hulick
Samuel Hulick runs UserOnboard.com and is the author of The Elements of User Onboarding. He’s combined UX savvy and a cat-like curiosity for measuring UX impact to become an expert in onboarding. His approach is shaped by over a decade of web experience, theories taken from behavioral psychology, cognitive development, video game design, and even filmmaking.
Transcript of the Video
I look at it as two different sets of categories – on the one hand you have mobile vs desktop and on the other hand you have consumer vs business. So, in the mobile space, you can have a mobile business oriented product or most mobile apps are going to be pretty consumer facing. At the same time, you have desktop or browser based products that could be B2C like Netflix, Yelp or Gmail or B2B like Basecamp or any kind of accounting softwares or anything along those lines.
If we’re looking at a split between B2B and B2C – B2C by its very nature has to be a lot stronger on the self-serve side of things. If you’re thinking along the lines of enterprise, you can throw a human resources at the problem a lot more than B2C where it just doesn’t scale because you’re by nature going after 10 or 100 orders of magnitude – more people you’re going to get up to Twitter levels if you’re a social media product whereas if you’re HubSpot, you can reach revenue with far, far fewer user base headcount.
So the time and attention you can pour towards one group vs the other is really going to demonstrate itself in the onboarding experience. On the B2B side, it can feel a lot more personal and white glove where you’re being greeted by an accounts person, there’s a support team thats there to help you out, a customer success team possibly – things along those lines.
When you skew further on to the B2C side of the continuum, it’s much more self-serve. Maybe you might be able to find a phone number for support where you hold for 10 minutes like with Comcast or maybe there’s a knowledge centre where you can file a bug. And so, the lower lifetime value of any given user, the more they’re left to fend for themselves.
Which means you really need to formalize your onboarding experience in an automated way as much as possible so you can scale as much as possible.
So, if you’re starting out, it’s really important to know which of the two ends of the spectrum you’re going to come in on. Either way, it’s great to automate the parts that need automating, that can be automated. But you just know if you’re going after consumer-play, you’ll be going at it right from the beginning.
If you’re making an enterprise kind of play, it’s probably something you’d be wiser to hold off before formalizing your product’s onboarding experience and instead you would just want to BE the onboarding experience as much as possible, until it gets so boring and predictable that you can automate it from there.
As far as mobile vs desktop is concerned, there is a whole different set of consideration whereas with mobile the screen size is much more constrained – you don’t necessarily have the keyboard and mouse combination, but then you’re also afforded other things like having cameras and contact lists and even accelerometers – whatever different capabilities that a mobile device would offer that a simple browser on a laptop wouldn’t.
Gaining access to the camera and to the contact list is something where you need to be provided permission in order to access those. And there is definitely an approach that some companies are using and I think they’re a little bit ahead of the others.
Many others aren’t in permission priming. Instead of letting people with dialogue boxes that say ‘___ app wants to use your camera/contacts’ right from the beginning when anyone’s experienced your product, let alone receive value from it – what I would recommend doing is getting people in through the door, being warm and welcoming and then doing ‘permission priming’ which is telling people that ‘we’re going to use your camera in so many ways that are going to be beneficial to you, when you tap next you will get this dialogue box and you should tap yes.’ So you’ve provided a rationale for it.
Even better when permissions are easier to accept are when you chain them to some sort of an event that the user has prompted themselves and it results in an ‘oh-duh’ moment. For example, as part of your onboarding experience, you’re asking someone to upload a photo of themselves, and they tap on the photo button and in order to take a picture, the next thing that pops-up is ‘___ app would like to use your camera’.
As a user it’s a ‘oh-duh’ moment because in order to upload the profile picture you need to let access to the camera. It’s worlds apart from throwing that dialogue box up as soon as someone has fired up the app and hasn’t even gotten to experience the app.
The browser side of that continuum is a lot more well known. Mobile is a new frontier and has less established conventions and ways of solving those problems.