User Experience Expert Samuel Hulick Discusses Onboarding For SaaS Apps

Samuel H_large

Samuel Hulick is a professional User Experience Designer based out of Portland, Oregon. He has a real passion for User Onboarding, which has led to the development of UserOnboard.com where he does teardowns of well known websites. He is also the author of 'The Elements of User Onboarding'.

Play

Tweetables
Create a website that behaves as you would if you were interacting with that person instead.
People buy things because they're looking to fulfill a particular need.
People don't want a quarter inch drill, they want a quarter inch hole.
Retain customers by continuing to deliver value and upping the ante month after month.
People are motivated to do things and to continue doing things because their lives are better because of it.

Today's Podcast Highlights

[02.10 - One thing that was always really important to me was looking at the impact that a redesign would have.]
[03.05 - For someone who's written a book, I actually find writing itself to be pretty agonizing.]
[06.09 - Once you become such an expert on your own product, and your product's domain, it's really hard to unlearn that kind of thing.]
[06.57 - A lot of times it's an organizational issue before it even results in becoming a product.]
[09.17 - I typically don't recommend just papering over the interface with tool tips or coach marks where you're literally pointing out the areas that are confusing instead of making them less confusing to begin with.]
[09.43 - A lot of times it's hard to tell what's the one thing that I should even be doing as a new user.]
[10.06 - You might hear of the “aha moment”, which is when somebody realizes what the product is capable of or what kind of benefit it can provide to that person.]
[10.13 - I think of "Time to Wow" as how long it takes you to deliver on that value that they've recognized.]
[11.27 - My first question there would be, what absolutely is super critical for getting the first run experience?]
[11.42 - Whatever happens after sign up immediately going into the application, how can you set them up with a quick win that will end it in a successful state on that first visit?]
[12.04 - If you go once and have a great experience, that might provide you with the momentum to come back over and over.]
[12.28 - Set up a life cycle email campaign to get people coming back and entering in the rest of what they need to unlock all the other capabilities of that application.]
[13.27 - Ultimately the job of helping shepherd people through needs to be done one way or the other.]
[14.15 - You're basically walking them through it, seeing what areas they're tripping up on, what areas are producing anxiety for them.]
[15.04 - I think the user experience and a focus on that is really important.]
[16.37 - If I were to boil user experience down to a single thing it would just be to create a website that behaves as you would if you were interacting with that person instead.]
[16.52 - You have to understand the people that you're serving and understanding what they're looking to accomplish so you can best tee them up for a pleasant and successful experience.]
[18.09 - People buy things because they're looking to fulfill a particular need, and they're almost hiring it in the way that you would hire a person to do something for you.]
[18.24 - Identifying what the primary purpose that somebody's looking to use something for, and best serving them and being able to accomplish it is more important than the product you're creating itself.]
[20.06 - You need to continue delivering value and upping the ante month after month to retain them month after month.]
[20.11 - Looking at how can you reverse-engineer a really predictable and reliable way to have people staying on as customers.]
[20.32 - The reason that people are motivated to do things and to continue doing things is because their lives are better because of it.]
[20.38 - Integrating your entire product and business around making people better in one specific way, and then letting the product follow.]
[22.42 - My definition of onboarding is increasing the likelihood that people are successful when adopting your product.]
[26.49 - Another thing that I offer are video tours where I personally walk people through what it's like to sign up.]
[31.27 - I recommend looking at overall work flows and how you're aligning that with people becoming more successful in whatever they're trying to accomplish.]
[33.01 - Injecting that humanity I think is really important.]
[33.14 - You also want to make sure that you're being consistent.]
[36.18 - Most tactical recommendations would be to perform usability testing whenever you possibly can or just to maintain that sort of a presence.]
[37.16 - Setting up a live chat in there makes a lot of sense.]
[37.33 - You can make the changes that will really decrease the friction to increase the conversion rates for everybody.]

Disruptware is building the largest community of software entrepreneurs on the planet. Make sure you are on the list.

 

download2

Full Transcript

Paul: On today's show we're going to talk to Samuel, who's the founder of UserOnboard.com. What we normally talk about is SaaS startups and growth and traffic and everything. But Samuel is an expert in user experience. And more specifically he has this great site called UserOnboard.com. What we're going to talk about specifically is all about user onboarding for SaaS apps. And Samuel has written a great book called The Elements of User Onboarding, which we'll talk about a bit more towards the end of the show. But Samuel has agreed to come on, and we'll talk about some factors and key elements of user experience, and offer some advice to our tribe on how to improve it and how to make their SaaS app attractive enough to keep customers using it, which obviously reduces churn rate, increases conversions and everything like that.

So, Samuel, tell me a bit about yourself. How did you get into all this? You know because obviously you've been in UX for some time, right?

Samuel: Yep, I'm a longtime UX designer and consultant. And one thing that was always really important to me was looking at the impact that a redesign would have. So, instead of just handing off wireframes and wishing them the best of luck, really looking at what KPIs are being affected here. Does the effect that we thought would happen actually happen and to what degree? So taking more of a scientific, conversion-oriented approach, it just really naturally lended itself to focusing specifically on user onboarding because it's got such a high overlap already with the conversion funnel and things like that.

Paul: Got it. And you started looking at already-existing SaaS apps that were already successful and started breaking down their whole process, right?

Samuel: Yep, that's correct.

Paul: Which is teardowns, as you call it.

Samuel: Yep, yeah, basically I was just looking to contribute what I've learned. And for someone who's written a book, I actually find writing itself to be pretty agonizing. So instead of writing a blog or writing guest posts on other people's blogs, I thought a teardown would be a cool way to create content that was hopefully valuable to people without having to sit down and actually write a long form article.

Paul: Great. So, your teardowns include companies like Basecamp, Buffer, you know, even Gmail, Less Accounting. And I think I saw the other day WhatsApp as well. So, are you getting any feedback from these guys? I mean you're just going in, right, and signing up, and going through the process of breaking down their onboarding process, and sort of criticizing it – constructively, of course. Are you getting any sort of feedback from them as a result of that?

Samuel: Yeah, I am occasionally. A few times it's led to consulting work and things along those lines where we actually get to put some of the recommendations into practice. And sometimes I just get a brief email saying, you know, "Thanks for pointing out a couple things," or things like that. And also a couple times… There will be times where I'll critique something and say, my guess is this is what they were looking to do, or this is the reason that they did something. And I've gotten an email or two from people saying, "I'm on the product team, and your guess was right," or "Here's a little background on how we made that decision." Things like that.

Paul: Fantastic. And are you going to keep doing this? You know, keep doing teardowns of different products?

Samuel: So long as people continue finding them helpful.

Paul: Yeah, well, I certainly did, you know. It's really interesting just going through it because you can learn a huge amount just from looking at other examples. And the way you actually break it into the good things and the bad things, and the things that you would do better, creates some real takeaways for me.

Samuel: You know, I do want to be really clear. There is kind of the good and the bad. I certainly wouldn't say that someone coming in without knowledge of the constraints the design team was working with, specifically what they're trying to achieve… And most importantly what their conversion rates and actual onsite behaviors are… For me it's just pointing out some things where, from a surface perspective, anecdotally, me going through it, these are things that I noticed. But certainly not saying that they're flat out wrong, or saying that I could specifically do better in a particular way.

Paul: Oh, sure, I understand that. But then, you're coming at it from a user perspective, which is really valuable obviously to the design team because they don't often get that feedback. You know, they're not going to get that feedback from their customers. All they're going to do is look at the stats, and quite often they'll be wondering why they're not getting X number of conversions or whatever apart from split testing. So, I think what you're doing, even though it's constructively criticizing , it's obviously great, valuable feedback, right?

Samuel: Yep. A lot of companies have commissioned their own private ones, and they've really found a high ROI on that, so it seems to be a valuable thing. One thing is, once you become such an expert on your own product, and your product's domain, it's really hard to unlearn that kind of thing. And even if you're using your own product on a consistent basis, you're not signing up for it over and over again on a consistent basis. So, it is often a real blind spot for teams. And having someone come in from the outside seems to be very valuable for them.

Paul: Yeah, absolutely. So from all your experience now, and looking at all these different things, can we just sort of go through what would you say are the key points that people overlook, and the key things for people creating their apps, and designers in particular. You know, what should they ensure that they focus on when building their onboarding?

Samuel: Sure, well, I guess it depends on how long – how long you want me to cover in one show…

Paul: Yeah, sure.

Samuel: The first thing I would say is, a lot of times it's an organizational issue before it even results in becoming a product issue. That the way a lot of teams are structured, there's the product team, which is really focused on ongoing use, advanced use, creating new features – things like that. Then you have a marketing team, which is more focused on driving awareness and getting people to the site, traffic. And then maybe at the end of that, are sign ups. So, who's really in charge of taking someone from sign up to advanced use, or ongoing use, tends to not necessarily fall under the role of one team or the other. It's kind of a gap there. So, your question was, what are common patterns that I find that people are doing wrong. A lot of times it seems like it's set up to be neglected to begin with.

Dovetailing with that is, a lot of times you can tell when a product has been designed… going through the design process of maybe they've made comps, or prototypes, or done user testing, or things along those lines. But it's always been when it's full of data, when everything's up and running. You can kind of get a feeling, logging into certain applications where it's, maybe, the home page is a dashboard, and it's just all zeroes and empty containers that nobody really looked at "How do we get people from zero to 60?" and also "How do we elegantly handle blank states to be helpful and guide people to filling them up with interesting things?" as opposed to saying "There's nothing to show you right now."

Paul: Got it. So, what do most people do? Or what should they do? Should they create, sort of templated data or something like that to start with?

Samuel: I wouldn't specifically recommend that. If it's done well, sometimes. Like if you look at Basecamp, for example, they have a sample project that's already loaded. And if you click into the project, it says, "I'm a To Do list," and "Click my third bullet item to drag it around" or "Mark it checked off" and things like that. And it kind of walks you through how to use it itself. But it kind of stops short of actually getting you to be successful in the real world, which is really what Basecamp is -- to help you facilitate managing a project as opposed to just learning an interface. So, as far as filling things up with dummy data or mock data, it's not a recommendation that I typically make.

Another thing that I typically don't recommend is just papering over the interface with tool tips or coach marks where you're basically saying, you know, you're literally pointing out the areas that are confusing just instead making them less confusing to begin with. But certainly, handling blank states, and just really being intent on what is it like for somebody to, immediately after signing up, what do they expect to see? What would be most helpful? Or even, a lot of times it's hard to tell what's the one thing that I should even be doing as a new user. So just getting really clear on those kind of things.

Paul: Because I guess the goal is really to get the user feeling as much value as possible in the first few minutes or something, right?

Samuel: Yep. There's a phrase, "Time to Wow," which is basically… You know, you might hear of the aha moment, which is when somebody realizes what the product is capable of or what kind of benefit it can provide to that person. I think of "Time to Wow" as how long it takes you to deliver on that value that they've recognized.

Paul: That's a good expression – I like that. You know, historically, obviously everyone focused on the conversion, and the "Time to Wow" is what builds that retention rate. That's what makes people stay in it. As soon as they start seeing the value and feeling that, this hey thing's really going to optimize the process or make me more money, or whatever it is.

Samuel: Yep. Or even preferably "This has already made me more money." You know, when they're actually receiving the value that they perceived on the onset.

Paul: Right, right. And would you… you know, I'm looking at one of my apps now, and it's a content marketing tool. And one of the challenges that I have is that there's quite a lot of setup involved, you know, because it's designed for agencies and there's a certain amount of data that needs setting up first. Do you advise a wizard approach, or something like that to get them going? To get them through the process, which can be a bit laborious to start with.

Samuel: Sure. Well, you know, my first question there would be, what absolutely is super critical for getting the first run experience? That very first experience where, basically, they haven't gotten up from their chair, they haven't closed the tab. Whatever happens after sign up immediately going into the application, how can you set them up with a quick win that will end it in a successful state on that first visit? And then tee them up for return visits, and going from there.

Because it's kind of like I compare it to going to the gym, where if you just go once, you're not going to get enough of a workout to have a totally in shape body, but if you go once and have a great experience, that might provide you with the momentum to come back over and over, form the habits that it takes to actually get that beach bod.

Paul: Yeah, yeah.

Samuel: So, in that sense I would say, if there's a lot of things that are required up front, is it possible to just require a couple things to get somebody to a particular state? And then set up a life cycle email campaign to get people coming back and entering in the rest of what they need to unlock all the other capabilities of that application.

Paul: Right, I got it. So, just focus on the easiest, quick win that you can, straightaway.

Samuel: Yeah, especially when that's really tightly aligned with the value that the product delivers.

Paul: No, I understand. And if in some cases where you can't do that, do you get people – or do you advise people to set up some sort of account management, or some sort of inside sales? Where someone, a real human can follow up after the sale to nurse them through the process?

Samuel: Sure. It's an expensive way to solve the problem, but a lot of times I'll speak to teams, and they'll say, "Oh, we don't have an onboarding experience. We have to call people and walk them through it" or…well, actually, you're the onboarding experience in that scenario. So whether you created software to replace yourself or not, ultimately the job of helping shepherd people through needs to be done one way or the other, so just different ways to skin the cat.

Paul: Yeah, yeah. No, exactly. And obviously that's the value, right? If you can do it through the app – if there's any way you can do it through the app and avoid the cost of human contact, then obviously that's going to be the real quick win.

Samuel: Oh, well, it would be more economical, generally speaking. I think there's a lot to be said for… what Rob Walling, for example, calls concierge onboarding, where you are walking somebody through it and you're intentionally injecting yourself or making yourself available at the very least. Especially earlier on, if you're not completely sure what those key touch points are going to be that help guide somebody to getting any value out of the product. It's a really great way to learn – you're basically walking them through it, seeing what areas they're tripping up on, what areas are producing anxiety for them. And then you can take all of those findings and feed them back into the product.

Paul: Ok. So, just looking at teams in general, you know I saw a talk not too long ago by Dave McClure who was saying that the UX guy is probably one of the most important part of a team nowadays. How do you feel about that? You think that's really like… I mean, you obviously are a UX guy, so you're going to say yes, of course.

Samuel: Are you trying to butter me up here?

Paul: Yeah, sorry. But would you say it's the essential thing nowadays to any app?

Samuel: Well, you know, I think the user experience and a focus on that is really important. I actually would say, the only caveat to that is, if there is one person who is the "UX guy," and the rest of the team, or the rest of the company doesn't really give much of a crap about the user experience or about the customer experience, that to me is actually a sign of danger where user experience is really not something to be siloed off or tacked on or stapled on afterwards. It's really something that, when it's really done well, the entire company's living and breathing it. So, that would be the one caveat, but yes I do think it's extremely important.

Paul: And for people who are kind of new to this, and who are like UI, I guess, designers who want to get more into understanding how to build great experiences, what would you say they should look and read and learn from?

Samuel: Like, what resources would I recommend for books or podcasts or things like that?

Paul: Yeah, yeah, because to understand someone's user process is kind of a bit different from a graphical design, right? They're two almost separate things to a certain extent, you know.

Samuel: Sure.

Paul: And understanding that world, you must have a certain mindset to get in that world and really master it. So I'm wondering if you can offer any advice to people who are looking to become experts in UX. What should they study, what should they look at?

Samuel: Sure. Well, my number one, just as a general rule of thumb, my recommendation – if I were to boil user experience down to a single thing it would just be to create a website that behaves as you would if you were interacting with that person instead. So, that requires taking an empathetic approach. It also really requires you to understand the people that you're serving and understanding what they're looking to accomplish so you can best tee them up for a pleasant and successful experience. So that's my general recommendation.

You can kind of spread that out and look… there are a lot of different areas that you can refer to. A lot of the most helpful books that I've read on user experience aren't actually specifically about user experience. They're more about psychology or product design, industrial design – things along those lines. There are certainly people that I really, really look up to as well. I could name some names if that would be helpful.

Paul: Yeah, yeah, absolutely. That's what I'm looking for, really – the psychology side. You know, really understanding what's behind the design, or what should be behind the design.

Samuel: Sure, so Ryan Singer, a product designer at Basecamp – I guess now it's called Basecamp – turned me on to two things through just following him on Twitter that really, really influenced my thinking. One is called "jobs to be done," which… do you think your audience is familiar with that? Or is that something that you're familiar with?

Paul: Not specifically, no.

Samuel: Ok, the general gist – let's see if I can pack it all in to a one liner here. The general gist is that people buy things because they're looking to fulfill a particular need, and they're almost hiring it in the way that you would hire a person to do something for you. So, there's kind of a saying people don't want a quarter inch drill, they want a quarter inch hole. So, identifying what the primary purpose that somebody's looking to use something for, and best serving them and being able to accomplish it is more important than the product you're creating itself. One follows the other. You're integrating around the job that somebody's looking to accomplish in that sense. That's a very, very brief overview, but that's the general notion there. And Clinton Christensen, for example, is the person most known for promoting that. And there's also jtbd.org, I believe, which has some great interviews on - or material on how to get to the bottom of what people really are trying to accomplish and what their job to be done is when they're "hiring your application or your product." So that's one thing I'd really recommend looking into.

And another one is the work of Kathy Sierra. She had a Business of Software presentation from 2009 that just completely blew me away – it has really, really informed my entire approach.

Paul: So, Kathy Sierra from Business of Software? Ok.

Samuel: Yep – 2009. If you do a search for Kathy Sierra, BOS 2009, I'm sure it would come right up.

Paul: Got it. But why specifically? What was it in her presentation that ignited that?

Samuel: Yeah, very similar, actually, to "jobs to be done" – looking at why do people love products? How can you create a really highly engaged user? Because with SaaS especially, it's not like something where you're selling on premises, a $10,000 enterprise deal, and you can walk away. And if they don't like it or if they don't use it, then you get to keep all the money. You need to continue delivering value and upping the ante month after month to retain them month after month. And so looking at how can you reverse-engineer a really predictable and reliable way to have people staying on as customers. And looking at what are the best drivers there? Do they love your company? Or do they love your support? Or do they love your product? Really those are just incidental to them really just loving themselves. And the reason that people are motivated to do things and to continue doing things is because their lives are better because of it. And so, integrating your entire product and business around making people better in one specific way, and then letting the product follow that as opposed to creating a product and then trying to find people who are willing to buy it. To me it's a subtle but revolutionary difference in perspective.

Paul: Yeah. No, I get that. So "jobs to be done" and Kathy Sierra's talks. But, focusing on the end game, so really just drilling down and focusing on what the user's trying to achieve. Rather than the software itself and trying to solve that.

Samuel: Yep. And that goes… it's like a fractal, I guess, where you can zoom in. In the grandest scale, what are they looking to achieve? How are you improving their life station? All the way down to what are you going to use for button copy? Just to get a really clear idea of what's going to resonate with them. What are they looking to accomplish in that micro-moment? And then everywhere in between.

Paul: That's fantastic. And so, coming to your book, "The Elements of User Onboarding," what are the key things that you focus on in that book?

Samuel: Sure. Well, basically looking at that trajectory that we were just covering of how do you make somebody better in the grandest scheme of things. And looking at what is that growth path for that person, where they're going from the lame, frustrated version of themselves to the awesome, very satisfied, successful version of themselves, and how can you… once again, using the same words over and over, but integrate your entire product experience around generating that growth in that person from the very beginning to the end and seeing where are things dropping off, how can you get people back onto the right road, or on the right track going from end to end.

One thing that was pretty surprising to me, after starting writing the book, is that, I think a lot of people consider user onboarding to be a wizard, like you mentioned, or a tool tip tour, where people kind of click through and then are dumped into the application. I really genuinely believe that onboarding… my definition of onboarding is increasing the likelihood that people are successful when adopting your product. And that starts way earlier than before they even sign up, because if somebody's signing up for something thinking that it's banking software, and it's really accounting software or tax software, there's no wizard that's going to save people from that misperception. They're already oriented in the wrong direction. So, it's not an interface problem, it's a communication problem – like an inter-relational problem in that sense.

So getting really, really specific on priming people for success before they even sign up so that they know what's going to be happening. And then also setting things up to deliver on that success – even after they've already gone through the process of setting it up. It's not really about activating features as much as it is about finding that value that you specifically provide. So it happens long after sign up and hopefully starts long before.

Paul: Yeah, I know, I get that. And I think I am one of those. I hold my hand up, naively I always thought onboarding is, literally, once my credit card goes in, then it's "How do I get up and running?" So in my mind it was all wizards and tool tips and all that. And so you've really opened my eyes into the fact that it's a lot deeper than that. And just focus on continually getting that, I guess as you said, the first wow, delivering the value and sort of focusing on what the customer's end goal is all the way through the process. And as you just said a minute ago, from the very start, even before they sign up.

Samuel: Yeah, and one thing I think is really crucially… under-paid-attention-to – I'm sure there's a better word than that.

Paul: Yeah. No, we get you.

Samuel: It's also getting people to come back. They're really not officially onboarded until they're a successful user who… You know, one metric is return visits and frequency of use, but one thing I pay more attention to… For example, if I need to find a place to eat, I'll turn to Yelp. So, I would consider myself fully onboarded on Yelp because they're the first thing that I think of – basically the only thing that I think of if I'm looking for a restaurant in a different city, or a new restaurant in my own city. But, at the same time, I don't go there once a week or multiple times a week or necessarily even multiple times a month. The real question there is, when I'm in that situation, what's the thing that I consistently turn to? What owns that space for me? And so in that case it's Yelp. And that's what you really look for with onboarding  -- they're not just having a surface experience and then going away, but they're fully engaged with you when they have that job that they need to be done.

Paul: And it becomes habit forming.

Samuel: Yep, big time.

Paul: Yeah, got it. And, so your book, what I've noticed – it's not just a book, is it? You have a number of different packages. You include some checklists and things like that. Can you just run through that for me? What else do you include in your package?

Samuel: Sure. Well, I recorded an audio book version just because I thought that people who would be busy would want to work while doing it and consider it a time saver in that sense. So, that's one thing that's included. The two big ticket items that I really have found very even valuable just for myself were the interviews where I spoke to some really influential people – even more than influential, they were expert level, very smart people, is what I meant to say. Hiten Shah, Patrick McKenzie, Jeff Vincent from Wistia – a few others that I'm unfortunately not remembering off the top of my head here. Oh, Josh Elman, for sure.

Paul: And Brennan Dunn

Samuel: A lot of those interviews were really, really helpful for me getting a complete picture of what onboarding is. Also some individual tips and tricks for how to approach it from a design perspective or a conversion optimization perspective. So, the interviews were really, really big there. And another thing that I offer are video tours where I personally walk people through what it's like to sign up for Basecamp and pointing out specifically what Basecamp is attempting to do, or what they're doing well, and how you could relate that back to your own application. So I have a video tour for Basecamp as well as for Vimeo.

Paul: Fantastic. That's really, really good. So, for anyone because a lot of my tribe are also bootstrapping, so they don't have big teams or, necessarily, lots of money. And so they might be looking for someone to help them with the UX and things like that. And obviously there's your services. But so what kind of things should someone, if they're recruiting someone to handle that, what sort of questions should they be asking? How do they know what's a good UX guy and what isn't? Because I think there's a good population of people now who might be graphic designers who are now re-labeling themselves as user experience people.

Samuel: Ok.

Paul: And so, how do you differentiate? What sort of questions should someone ask when interviewing someone like that?

Samuel: Sure. So, one thing that came to mind, one person in the interview package that I neglected to mention on the first pass there, Brennan Dunn is very much a bootstrapper, and is one of the smartest onboarding thinkers that I've gotten a chance to speak to. So, he's intimately aware of what it's like to deal with those kinds of resource constraints. He's a single founder, doesn't even work on his product full time, but his onboarding approach and design is very, very high level, or very high quality. So, that was one of my favorite interviews. And if you are bootstrapping, that's one that I really recommend checking out.

But, specifically to your question you were saying, how do you evaluate a contractor? A UX designer?

Paul: Yeah, exactly.  I mean, if you're hiring freelance or even permanent, how do you tell who's a really good UX guy to who's just a UI graphic designer?

Samuel: Yeah, so that's tricky

Paul: That's why I asked the question.

Samuel: Yeah, I have no… I'm a terrible graphic designer, so that's never been a problem for me.

Paul: Right.

Samuel: I've always had to stand on my own merits as a user experience designer, what you might call "pure user experiencer," things like that.

Paul: Sure.

Samuel: My recommendation would be, specifically if you're looking to suss out who's someone that leans a lot more towards UX design more than graphic or visual design, one thing I would really look for is experience in conducting user research. So, specifically saying, "When have you done user research in the form of interviews or surveys – anything along those lines. If they don't have any experience, then that would be a big flag to me.

Another one would be if they don't have any experience conducting a usability test, where they're getting one or more people into a room and having them go through the site and recording the areas that they run into problems and things like that. That's literally… anybody with a zero dollar budget could be doing that. And I actually recommend that founders or product teams do that on their own as well that – in the same way we were talking about concierge onboarding and spending as much face time as possible with actual users in the moment is a really great way to not only help that one individual user become more successful, but also taking what you're learning about where they're running into problems and spinning it into product changes that would prevent thousands of other people from running into that problem as well. So, that's something I would recommend doing – not even contracting out necessarily. But that would certainly be a strong indicator of a good user experience designer.

And then lastly, I think that a lot of people consider design to be the… well, two things. It's not so much about the patterns of pixels that appear on the screen or how elegant or appealing something looks, a lot of it is what you say. So if people – if a UX designer doesn't at least have a strong appreciation for copywriting, if not expertise in that to begin with, that's something that would be a big flag to me as well. That if they're really just looking to solve it through changes to layout or the composition of the site or textures or things like that. Those are certainly important, but you're cooking with only one ingredient if that's the only one that you're using in that sense.

Paul. Yeah, got it.

Samuel: And then the other big thing that I would recommend is looking at… once again, not so much important as an individual screen, but looking at overall work flows and how you're aligning that with people becoming more successful in whatever they're trying to accomplish once again. So, if you see – if a UX designer is really focused on creating screens in isolation rather than identifying how five different screens would help facilitate somebody through a particular work flow – that's something that would be a big flag as well.

Paul: Got it. You know, and what's interesting, what I see a lot more nowadays is people trying to inject personality into the onboarding process.

Samuel: Yeah.

Paul: In the terminology and things like that, "Hey, that's cool." And just trying to break down the barrier of, hey this is software, into something that's a bit more fuzzier.

Samuel: Yep. I mean, once again it goes back to -- as representing your business, how would you interact with someone if you were taking the place of your website? So looking at what is a human… because it's human-computer interaction, but it's really human to computer to human interaction. One way that I describe websites is like they're conversations with one side of it that's been pre-recorded. So, how do you want to represent yourself? What kind of tone do you want to take? When is it appropriate to say something, and when is it not? Even things as simple as welcoming people to the application for the first time. It would be really weird if you were operating a brick and mortar store and somebody walked in, and you just got right to business. So, injecting that humanity I think is really important.

At the same time, it doesn't mean that you need to make everything goofy or punchy. It has to obviously be in alignment with what the user would be expecting as far as your brand is concerned. And you also want to make sure that you're being consistent. So, if your marketing site is very buttoned up, and then the onboarding experience lets it all hang out or whatever, that would be a mismatch of what somebody would be expecting and could be kind of a… make for an awkward moment.

Paul: Got it. Got it. When talking about…

Samuel: Oh, wait, just to round that off.

Paul: Sure.

Samuel: One other area that I really recommend looking how human they are, are error messages. That if you can, first of all, prevent error messages by making a more usable product, then that's great. But assuming that things will break down, writing something that, in that moment of very… that's probably tense and frustrating and full of anxiety – to come in and really be human, be apologetic as opposed to accusatory. That's something that I think is a great area of opportunity for a lot of product teams.

Paul: Yeah, definitely. "Oops."

Samuel: Right.

Paul: I mean, you see it all the time now, right? "Oops, something went wrong." Just going back a step, when you were talking about user testing, it brought back memories of… in my background, I was the CTO of a big SaaS, corporate-type app, and we were selling into Nike in Europe. And one of the things they did, they did user testing on the app. And the way they used to do it was they'd have the users in a sort of test suite, as it were,

Samuel: With those two-way mirrors, things like that?

Paul: Yeah, and they had cameras and stuff like that recording what they were doing, but being a sports company, the way they did it is they had yellow cards and red cards – you know like in soccer. So, basically, if you had like… if something was really objectionable, then you got a yellow card. And if they found another one, you got another yellow card, and obviously then, you got a red card.

Samuel: And the test users would hand those out?

Paul: Yeah, yeah, they'd literally hold them up. So if they'd hit something that was like really objectionable, they'd hold up a yellow card, right?

Samuel: Oh, that's awesome. That would make such a great, easy way to record all of that as well.

Paul: Yeah, exactly, exactly.

Samuel: I've never even heard of that. That's a really cool approach.

Paul: Yeah, it was good fun at the time. Thankfully we escaped it, and we got through that process.

Samuel: Right.

Paul: But, yeah. No, that's cool. So, it's been really great chatting with you. We've come to the end of the interview really, and I think… You've recently launched your book, and it looks like a fantastic package. And it think the interviews would especially be really, really valuable and interesting to people creating their – especially bootstrapping their apps. Any parting thoughts on people, to help them and guide them into ensuring their onboarding process is as slick as possible?

Samuel: Sure. I think the two easiest, most tactical recommendations would be to perform usability testing whenever you possibly can or just to maintain that sort of a presence. So looking at… it's so easy to forget this crucial moment of getting people to actually sign up and have a positive first experience. It really gates them being able to be successful down the road. If you start looking at statistics of how many people who sign up for a trial ever even come back a second time? The numbers can be pretty sobering. So looking at, you can't have an advanced user… you kind of have to crawl before you walk sort of a thing. So, really paying attention to that. Keeping that highly visible within the company is a recommendation that I would really make.

And the other thing is to maintain as much of a presence in the moment as you possibly can. One thing that I think is really underused is, for example, live chat, making that available if you have a wizard that's walking people through the set up process, for example. Setting up a live chat in there makes a lot of sense just because, once again, you're not only helping the single person that you're providing the chat assistance to, but you're learning about what really causes that confusion and anxiety in that process, or where people are being hung up. Then you can make the changes that will really decrease the friction to increase the conversion rates for everybody.

Paul: That's interesting. And I guess from the other side of the fence, so if I'm sitting here watching users come into my system, are there any tools that you would recommend that would help people obviously just monitor the metrics but kind of get some insight into how people are experiencing your app into real time?

Samuel: Sure. KISSmetrics and Mix Panel both come to mind. I haven't used Mix Panel very much, but I've seen enough of both of them to make a recommendation in that regard. Crazy Egg is really helpful if you're trying to diagnose where problem areas are, or if people are clicking on a picture because they think it's a link as opposed to… or maybe you should make it a link if that's what people are thinking is going to happen. There's a… Joel Spolsky has a definition of usability that I really like a lot, which is basically, make things happen in the way that people expect them to. And, anytime somebody expects something to happen, and what your product does doesn't align with that, then either you need to do a better job of orienting their expectations in the right direction, or just changing it so that it behaves in the way that they expect. And any usability breakdown basically comes down to that. So, that's one thing that I would definitely recommend there.

Paul: Brilliant. All right, Samuel, I really appreciate you coming on the show.

Samuel: Absolutely.

Paul: I found it really insightful talking with you and it has certainly given me some ideas for my app, and I'm sure my tribe as well really appreciating some of your insights

Samuel: Cool. Absolutely. And you know I'm always just an email away if you or anybody listening to this has any questions I love answering them.

Paul: And anybody listening, you can go to useronboard.com and you can get… see all the teardowns that Samuel has put together and obviously his book there as well. And I highly recommend it.

 

Recommended Resources:

1. User Onboarding – Click here

2. The Elements of User Onboarding – Click here

3. Ryan Singer – Click here

4. Clinton Christensen – Click here

5. Jobs To Be Done – Click here

6. Kathy Sierra, BOS 2009 – Click here

7. Brennan Dunn – Click here

8. Hiten Shah - Click here

9. Patrick McKenzie – Click here

10. Jeff Vincent – Click here

11. Josh Elman – Click here

12. KISSmetrics  – Click here

13. Mix Panel  – Click here

14. Crazy Egg – Click here

15. Joel Spolsky – Click here

 

 

, , , , , , , ,