Samuel Hulick

[Amy Jo Kim] How did you get started in design and tech?

[Samuel Hulick] Yes, so I’ve been working in the software realm for over a decade now. I initially hung out my shingle as a developer, or kind of a WordPress theme coder. I would wind up coming in at the end of a waterfall design process where a lot of … Basically all of the decisions have already been made. I had just inherited a PSD and was told to make it clickable. There were a lot of times where I would notice some pretty basic usability issues, or do we really need another homepage carousel here, or things that haven’t really been thought through. But by that time the deadline was looming and the budget have already been used up, and people were essentially saying, “well, we’re just going to run with this anyway.”

I would grit my teeth and code it out. Eventually really wanted to come in earlier and not the decision making process, and decided that what i was really most passionate about was user experience design, and that I should start getting as much experience in that field as I could. Eventually, I was able to call myself a full fledged user experience designer and then realized that there was one other piece I was missing, which was, for me to be able to know that I was getting better as a designer and the general notion of coming in and making something nicer and friendlier, but no necessarily knowing if it was better or not and served the people’s needs, who was using the websites needs better.

That led me to want to take a more empirical, experimental measured approach. Which lends itself really nicely to workflows and user onboarding is one of the key work flow. That’s when I decided to get even more specific and just focus on user onboarding.

When was that?

The user onboarding part was about a year and a half ago.

What was it that prompted you to start creating and sharing publicly user onboarding tear downs? You’re very well known for that now. How did that get started?

I decided to self publish a book. I wasn’t really sure what the book was about but I had this high-minded design philosophy as a topic. I put up a landing page and wanted to get people, basically to build up an email subscriber base, so that I would know that I had people to sell the book to once I had written it. Realized that I needed to get people to go to that page. I was thinking about guest blogging and things like that. I really was not known outside of some designer friends that I had at the time. Really didn’t have any following or anything whatsoever. Realized that, as a consultant, one thing that I would do on a user experience project was, would go in and take screen shots of the different parts of a work flow and mark them up with annotations and things like that.

I was, like, if only I could share one of these. I bet people could get value out of it. Then I wouldn’t have to go the trouble finding a guest post and things like that. Realized also that it would be not great to share something that had been commissioned without the expectation of it being made public. At that point I realized but there are thousands of companies who haven’t paid me to do anything for them, and I could just do that for free and post it online, and see what happens. That was the genesis of the tear downs.

Got it. I’ve enjoyed reading a lot of your recent post about how you think about product development. What are some of the most common mistakes that you see first-time creators making in the early stages of designing and testing their ideas?

The fundamental design error in my opinion is not being really clear on how you make people more successful, or how you improve the life situation that they’re in. That essentially, when you are signing up to use a product, it’s kind of an expression of hope. Where you’re thinking, me with this product in my life will be better than me right now. Aligning the entire experience around that and developing people’s skills and demonstrating how much more successful they are, to my mind is the approach to take.

Any time that you are creating something that is out of alignment with what people are trying to accomplish, or any time that you approach design from a standpoint of imposing your will on the world more so than harnessing the motivation that people already have. I tend to see that as being a missed step I guess I would say.

Got it. When you’re able to be in charge of a project, how do you approach early testing and iteration?

Iteration of design or just in general?

Both. Iteration of design, but then also iteration of, say, an MVP.

My particular approach is to get as much qualitative information as I possibly can. That a lot of times will take two primary forms. One are surveys at key moments in people’s lives, and the other is in-depth, in-person interviews, or Skype interviews. Things along those lines. The surveys, I take the jobs-to-be-done mindset on … I look at the moment of switching, which is to say, instead of surveying or asking people what they thought of something when they’ve been using it for three years, or what they think they might find useful about something that they’re not currently using. In both of those cases, it’s kind of a speculative or trying to remember. The concrete has set or doesn’t exist.

I like to go right at the moment when somebody is at the process of switching to a different product and essentially asking them what do you hope your life will be like with this product in it? What are you looking to accomplish with it? What was the external situation that motivated you to make a change with whatever it is that you were doing before anyway? Just get a really clear idea all around what they’re hoping to accomplish and achieve, and then use that for the inspiration for the design of the product itself.

How do you find people who are at that moment?

It can be tricky. There’s certainly areas where you could just say … If it’s your own product, then that makes it very easy. If you are looking to get other people’s products, or to find people with a switching moment there, and it can be something where you’re just making it known that if somebody is thinking about switching or is about to switch than you could just make that relationship warmer. You could also ask, if you have access to a wider array of people, you could ask of people who have recently switched, for example, within the last month or two. The “concrete” would still be pretty wet at that point as well.

What about if it’s a product that doesn’t yet exist?

That’s where I was coming from. That you would be … If you think of your competition as whatever someone is going to have to stop doing in order to start using your product, then you can essentially run those switch interviews for whatever that is. Beyond just saying, my product doesn’t exist yet so I can’t find out anything about the problem space, you could also look at … It doesn’t have to be your “competitors,” like the other software offerings that, if you’re trying to come up with an invoicing software, you don’t have to look at other invoicing products. There’s a pretty good chance that your primarily competition would be Word documents being emailed to people. Things like that. You could look at those kind of work flows as your initial source of inspiration.

Right. When you are working on, very early in a product, how do you figure out which ideas to pursue and which ideas to throw out when you’ve got a lot of them? How do you go about dealing with that funnel and vetting ideas, again, during the early stages?

I guess it depends. From an early stage standpoint, I find that it’s really helpful to get something in people’s hands and see how they respond to it. Ryan Singer who’s a designer at BaseCamp, or the lead designer at BaseCamp, I believe, Is someone who I’ve really looked up to for a very long time. He has this metaphor of that you can speculate on a light bulb all day long, but you’re not going to know whether it works or not until you plug it in. I find that to be a similar thing, that it’s great to go out and get … I almost consider it necessary to go out and get qualitative research information early in the process and use that to inspire what you’re going to create. But at some point you do have to create a minimal version of it at least, and get it into people’s hands and see how they respond.

It’s largely a question of, when you’re talking about deciding what to include and what to throw out. Thinking of your product as solving a problem and the absolute core essence of it. I like to stay really narrow as far as testing not a lot of variables at the same time, or building out a rich array of features. Instead, just say, what’s the quickest path from A to B, and solving this problem for someone, and can I confirm that’s a problem that they even want to solve, or that they are finding relevant or know what it is in their life at all.

Right. Once you’ve confirmed that it’s a problem they want to solve, figuring out how to build an MVP is something that I think a lot of people struggle with. I don’t think there’s any one answer, right?

Sure.

Once you’ve got there, you said, we’ve done through qualitative research, we found out yes, this is a problem people care about and want to solve. We’ve done the initial analysis and now we’re putting the M into the MVP, right? The Minimal.

Sure.

I find that many designers have their own little tricks they’ve evolved over time for figuring out the M. what that Minimal thing is. Do you have any heuristics or rules of thumb?

As far as just defining what the scope of the product is or in the process of actually producing it?

Really defining what it is. Then, producing it together. Those are related, but I don’t know how much you work at really early stage versus coming in to an existing product and fixing the onboarding.

A lot of times I’m coming in, as a consultant, I’m coming in to products that already exist and looking to reverse engineer what problem that the software solves and what needs to be presented to people first from an onboarding perspective. I typically really don’t recommend investing a lot in a formal onboarding parts of your software when you’re really early stage, because you’re probably not 100% clear on what that absolute must-have experience core workflow is, or even which parts of it you should introduce to people right at the beginning.

A lot of times when people “design their onboarding experience,” it’s in a capacity where they’re just maybe working on pretty shaky assumptions about what people should be doing right away in the product. A lot of times they skew towards pointing out features more so than getting people to accomplish things. Even just knowing what those things that people should be accomplishing are can be a very big leap forward.

That’s the capacity I typically work in. As far as coming up with an MVP, or just an entire product entirely, that’s typically not a huge focus of mine. To circle back to the not investing in onboarding right away; really getting a clear idea of what people are struggling with and what they’re looking to accomplish and helping them … basically be the onboarding. You, yourself should be the onboarding and be the system to people until it gets to be so clear what it is that people need to do, then you can kind of replace yourself with software.

I recommend exactly the same thing. I’m glad to hear you say that. I’ve actually got a chart about when you focus on onboarding, and when you focus on core loop. Let’s dive into that a little bit. When is the right time in the product development cycle to focus on onboarding. You just outlined beautifully why very early is the wrong time, but when is just the right time to focus on onboarding?

The approach that I really advocate is, like I mentioned to be the onboarding at the beginning, not only because you can shepherd the individual users through and help them find the value in your product, and so on and so forth. But it’s also a two-way street, or even more value is coming to you because you’re getting all this feedback.

The feedback, in my experience, comes in two main varieties. One is just discovering where people are tripping up. Just points of friction in your workflows, or simple usability problems, or I never thought that they would decide to click that button at that time. I should do something about it. Then, you could use that to incrementally go in and resolve the usability issues. Sand off the jagged edges off of your software. That’s one source, but then also the other kind of feedback that you’re getting is just around what people are hoping to accomplish, and what their aspiration for bringing your product into their life is.

At that point once you become really clear on where their mindset is and what they’re hoping will happen. That’s when you can formalize your onboarding experience in your software around this actual knowledge that you’ve been able to get straight from the horse’s mouth in the moment.

Which is great, but people aren’t always able to do that. I’ve noticed. With certain mobile apps that can be really tricky. Have you developed any tricks and tips for learning more about your users? I noticed in some of your writing you mention that there’s a whole grab bag of things that a designer/researcher can do to learn more about our users. What are some of your favorite ones?

The two that really stand out to me are being present and having live chat up. It’s really amazing what people will reach out and let you know about if you’re just maintaining that presence there. Once again, it’s helpful to be able to help that one individual person out, but then you could also take that information and improve your experience overall for all the untold thousands of people that will follow that person.

Again, like you mentioned if you have a mobile app, for example, that can be pretty tricky. The other thing that I recommend is to, especially in the early days, you’re probably not being inundated with signups, is to just sit there and watch people as they sign up. If you have any kind of visibility whatsoever in new user created, user accomplished X, user accomplished Y, and just see how far they get in that very first first session, and where they drop off.

There was an enterprise software company that I worked with. I would just literally watch as new users were created, and watched their activity in a database. If they hadn’t done a certain set of things, which were the recipe for a successful user than within a half an hour I would send them a personal email and say, “hey, I just got an alert that you signed up and it looks like you haven’t done this yet. Was it something that you found tricky about it, or can I be helpful in any way? Do you want to jump on a screen share and work through it?” That was just an insanely valuable source of inspiration and product feedback.

Wow, that’s a great story. Do you do much prototyping yourself when you’re throwing together some sort of prototype, as you say, get something in people’s hands as part of a project. You mentioned you had a developer background. Do you have a particular tools or particular styles that you like to use for prototyping?

Yes. I really like to keep as much of the design experience out of Photoshop as possible. To my mind is not really representative of an online experience, but it gives you the tools to get nitty-gritty with the pixels, which is typically a very beautifully-rendered box with Lorem Ipsum to me is putting the finish on something that doesn’t really exist yet. I would like to go identify what are the workflows that we’re going to assist people through, and match up screens or screen states in a very high-level, just marker-at-a-whiteboard fidelity around this is the key workflow, these are the complementary ones.

If someone decided to exit at this point, kind of come up with a logic tree basically and matching up screens to those different beats. Going from whiteboards to either Keynote, which is something that I really like to use and for whatever reasons … I use it for so many different things, and for whatever reason I much, much prefer that if I am doing graphics to something like Photoshop or Illustrator, or preferably going straight from whiteboard to really low-fidelity working prototype and code. Once again, just getting it into people’s hands long before you’ve put a lot of polish and things like that into it.

Talk a little bit more about that. Why it’s so important not to polish those early prototypes?

Because the polish isn’t going to make or break your design, most likely. If so, the polish is probably coming through in personality, the copy that you’re using. Not so much the aesthetics. If you take an approach of creating an MVP … Or if you take on the perspective that an MVP is something that you’re creating to validate your assumptions. Your assumptions is probably not that making it really pretty is the “killer feature”. Making it look nicer doesn’t help you validate that you have a business model and something that it’s something valuable to people.

Got it.

Unless, I could kind of see maybe a product that really wants to differentiate on design and making that a core assumption, but even in that scenario it still has to be … It has to do something for someone. That part, to my mind is always a lot riskier than will people be pleased when they look at it.

Well, when you polish something you grow attached to it.

Oh, yes.

I found that it’s slower. Of course it’s slower to iterate when you polish, but the team gets much more attached to the design that they’ve polished and then it’s harder to hear the feedback. Have you ever noticed that?

Yes, like the sunk cost fallacy.

Yes, like that.

Yes, totally. It’s also just something there the product teams that learn faster are going to be the one that wins, and so if you’re getting bogged down into the minutia of pixel-perfect design, so to speak, then your iteration cycles are going to be longer and your net learning is thus going to be less, or at least take longer. To be really quick and agile, you need to have the nimble flexibility that comes with just getting things out there and testing the core assumptions and not spending a lot of time really highly articulating something that might now worth being said.

Exactly. Everyone that we’ve been talking to uses some sort of collaboration tool to work with their teams. Part of my purpose for doing this is to create the podcast. Part of it is also to create great juicy content for the teams I’m currently working with on Getting2Alpha, the design program. They all are very interested in collaboration tools and they’re using Slack, because I use it for the program. It’s new for most of them. Not for all of them. I’m interested in what tools for Skype, and Slack, and GoToMeeting, and any other. Interested in how you collaborate. What kind of tools you use? What kind of practices you found worked well?

Sure. As you mentioned, Slack is way up there. It’s pretty crazy how it inserted in itself as sort of must-have piece of software. It would be almost unthinkable to try take that on with a different … I guess there’s Hipchat and things like that. That whole manner of communicating has been really vital. I also will use email when it’s something that can be more asynchronous, and I’m a really big fan of Google Hangouts or video chat in general. I tend to not use Skype too much, and I’m not really sure why. Those are largely the ones that I use.

I’m not really aware of any group collaboration software that will let you sketch in real-time, or things along those lines, that’s really well executed. I would love to discover that if and when that comes along, if not now.

It’ll probably show up as an integration in Slack perhaps rather than a thing on its own.

Yes, could be. Or I could see just giving people markers in a Hangout or in Skype, could be really useful as well.

What are you using Slack for?

I’m also building my own software. It’s actually in in what I would call an MVP state right now. I’m teaming up with a couple of other engineers. I’m working with them primarily over Slack to just either schedule conversations or just to stay on the same page, and get status updates, and so and so forth. So far that has been 100% remote.

Do you find Slack meets your needs pretty well?

Yes, I would say so. It seems to do the job pretty well. I haven’t gotten crazy with integration and custom emojis and things like that. Just as a asynchronous or non-asynchronous communication tool, it’s been essential.

Recently, I’ve talked to several people who’ve used both Slack and Hipchat, and really prefer Hipchat. Feature for feature it’s almost identical with Slack, but Slack captured the market.

It’s really interesting. I wonder how much having a warm personality had to do with that.

It certainly had something to do with it. Who knows how much? I think there’s a lot of good marketing too. But they had the warm personality. Let’s put it this way, that wasn’t the only thing that did it.

I would be highly skeptical of anyone pointing to a single thing that was the cause for Slack’s success. I’m constantly asked about my thoughts on gamification, as they relate to user onboarding. I find gamification to be a really problematic term, because I think a lot of people associate it with points and badges and things along those lines, which are possibly helpful but more as an accelerant to an already well-aligned workflow than as something that you can slap on after the fact and suddenly your irrelevant product becomes a must-have in someone’s life. Or something along those lines.

From the term applied game design, I really like that because you’re able to say “let’s look at design from a perspective of providing people with skills and understanding their emotional state in a particular moment and understanding what’s psychologically driving them and create an experience that maybe alternates challenge and mastery or demonstrates their progress, or things along those lines.” Sort of “naturally’ within the product experience as opposed to throwing almost carelessly some points or badges, or things along those lines that are essentially very shallow as far as moving the needle and getting people to accomplish different things, and getting them to go through workflows and things along those lines.

How are you inspired by game design in your own work?

That’s something that’s been really mind blowing, especially with the Daniel Cook talks and articles that he’s written of looking at product design as … Where product design and game design overlap. To my mind is that you are providing people with skills and you’re developing their capabilities in the world. Virtually, or in real life, or whatever. The idea of aligning your entire product experience around the progression of their skillfulness, and the, how do I best put it?

Their journey toward mastery?

Sure, their journey toward mastery, but there’s also an element that looking at the outcome of your product as not somebody activating a feature, but it’s them actually accomplishing something and becoming a better person in some way. The skills are capabilities for being able to do something, but your product is also an actuator for them actually doing it.

That’s great. I feel very much the same way.

You can be successful in getting people to do things in a Skinner Box kind of way. You can manipulate people into doing things online, but A) you don’t have a lot of leverage because those things will wear off and people will decide that they don’t really enjoy being manipulated into doing things that maybe aren’t … That they really don’t want to do. And B) it’s just so much better to harness their real motivation and amplify as opposed to undermining it, or subverting it in some kind of way to get them to do something that they might not have been super interested in.

When you take an approach of product design as upgrading skills and encouraging accomplishment, then you’re really able to take the natural motivation and energy that someone is bringing to the experience and really deliver on it, and use it to your advantage as opposed to trying to constantly steer people towards something that maybe isn’t highly aligned with what they’re looking to do.

That’s really well put.

Cool. Thanks again.

What is your super power as a designer? What project light you up the most?

User onboarding projects for sure. I really like to work with teams that understand the value of user experience design inherently. I find that on my consulting projects I can come into work with a company … Seems like two main flavors and you can tell right away where some people are looking to hire UX Design, because it’s not inherently valued or intrinsically valued in the company. They kind of want to check that box, or they heard good things about it and they want to be able to slap it onto their product experience.

Versus, working with companies who find user experience online super valuable across the entire organization and are looking to get even better at it. I used to think going into companies where their user experience was really neglected, like oh. You’re going to love working with me. We have so much … Look at all the low-hanging fruit. I can really get you really far.

I used to think that working with companies that really had a priority for user experience was intimidating. Who am I to say that MailChimp should do what I say, or things along those lines. I found it to be completely opposite. That companies that really have seen the light really want to get better, and are really enthusiastic about putting the pedal even further to the floor on their experience. Whereas companies that, to my mind, don’t really get it, don’t tend to really value what I’m able to bring to the table. For those kind of reasons, those are projects that really light me up the most.

Awesome. Where is your focus these days and what’s coming up on the horizon for you? I know you have a new book out.

Yes. I have the User Elements of User Onboarding. That’s the book that I … That’s kind of where we started in the conversation that I’ve self published that got me to start doing the tear downs. I’m continuing to come out with new tear downs and I’m also doing quite a lot of consulting. As I mentioned I’m working on an MVP of a software offering to help people with their onboarding as well.

Very exciting. When will that be something that we can learn more about?

If you go to useronboard.com/beta there’s a survey that you can fill out to get on the early access list. I am using that to slowly roll it out to batches of initial customers. That would bet the number one way to get there.

Awesome. Thank you so much for joining us today.

It has been a distinct pleasure. Thank you for having me.