The Clearleft Podcast

This is the Clearleft podcast. That’s how I start every episode of this podcast. One sentence. I don’t tell you all about Clearleft. I don’t tell you about other episodes of the podcast. I certainly don’t tell you how to listen to the podcast. That would get very tedious very quickly.

Imagine popping into a new shop for a pint of milk. And as you spot the sign for milk, the manager appears blocking your path. She asks where you’ve come from and starts to interview you about the sorts of products you usually buy.

She hands you a loyalty card application form and offers you a guided tour of the shop. Perhaps you want to join the mailing list, or perhaps you want to turn around and try the shop next door instead.

That’s my colleague, James.

I’m James Gilyead. I’m a product designer at Clearleft.

As you may have gathered, James was talking about the experience of onboarding. His hypothetical example sounds extreme, but what he’s describing is what we experience in online products and services all the time. James worked on an onboarding project recently, together with Jo Dimbleby.

I am Jo Dimbleby. I am a content strategist and content designer.

Before we hear more from James and Jo, I’m going to break the fourth wall a little. Right now, I’m making this podcast episode in an app called Descript. It’s a good app, but it seems like every time I open it up, it’s just dying to tell me about the new features that have been added. There’s a little red dot nagging at me to be clicked on.

When I do click on it, I’m given a menu of tutorial videos I can watch to get me started. I’m sure they’re very good videos, but right now, I’m making a podcast. Now is not the right time. But Descript is not alone in trying to nudge me into watching its onboarding instructions.

If we’re going to talk about onboarding, then we have to hear from Krytal Higgins. She literally wrote the book on this topic. It’s called Better Onboarding, published by A Book Apart. Krystal spoke at one of our events a little while back. It was a great talk. She explained that crummy onboarding experiences often come down to something you might not expect, fear.

Fear is what can get in the way of better onboarding experiences. Because we fear that new users will leave if they don’t know everything up front.

We fear that they won’t do anything later so we need to get them to do it all at once.

We fear these needs that they have, that we can’t predict. And so we don’t know what they might need to know so we put everything up front.

And we even sometimes selfishly fear that without telling somebody something, they won’t recognize the hard work our team has put into the product.

The initial impression I had was, ah, this has been written by some developers who are very proud of their feature range, which is great. It’s a really, really powerful product. The difficulty is that you you don’t think about how the average Joe is going to approach all these powerful features.

The problem is that such fears can lead us to unnatural solutions. The most common of which is front-loaded instruction.

This is when we try to explain everything about our products upfront, using anything from slideshows to tool tip tours, to overlays and videos, instead of letting people dive in.

There is that temptation to explain what you’ve done or explain how people can find certain features or how to navigate. But actually that’s just adding noise. It’s adding a layer of complexity that I would personally try to avoid.

Like attending a lecture at a university, you’re expecting people to memorize all of this content in one sitting.

It reminds me of back in the olden days when people were building Flash sites and they would put so much energy into designing the loading screen for their Flash site.

But I’d put all of that energy into removing the need for a loading screen before I put it into designing a loading screen, because no one’s here to see the loading screen. Nobody’s here to enjoy your onboarding experience.

It’s also presented out of the context of use, and it’s really hard for people to apply what they’re seeing to real actual usage, making your onboarding experience that much less actionable.

They’re here to perform a task that you’ve promised they can do with your tool, so get out of their way.

Front-loaded instruction can also increase how complex someone perceives your product is, which is kind of the opposite of what you’d hope they get out of something like that.

You want to stay out of their way. You want to provide them with the options to solve the problem that they’re hiring your product for, and you want to give them the option to find further information if they need it.

But you don’t want to put them off by showing them everything upfront and forcing them to kind of circumvent your well-intentioned onboarding materials in order to go and find that feature that they’re looking for.

All right, so if fear driven front loaded instruction isn’t the solution, what is?

Better onboarding comes not through front-loaded instruction but through guided interaction.

What is guided interaction? Well, it’s when we anchor information to action being taken in the context of that action.

It also means that we distribute guidance so that the user can encounter it at their own pace.

And finally guided interaction is about providing guidance in a way that feels like an authentic extension of your product instead of something that feels tacked on and disruptive.

Now I can’t show you what good guided interaction looks like. This is an audio podcast after all, but I can demonstrate what it sounds like.

That’s the sound of the first level in Super Mario, and it’s a masterclass in guided interaction. As the player, you’re onboarded into how the game works by playing the game.

Legendary game designer Shigeru Miyamoto said “we kept simulating what the player would do so even within that one section we knew that the player would understand the general concept of what Mario was supposed to be and what the game is about. We didn’t need to have a separate tutorial.”

I remember speaking very specifically to James about the gov.uk approach, which is one piece of information or one set of information so that you are not expecting someone to gather all of that information at once and establish for themselves what it is that they need to be worried about. You are actually giving them one thing to focus on at a time, and then through that you accomplish more.

Users will find their own level of engagement if you trust them to do so. So it’s about making sure there are those points of reference, areas where they can get support if they need it, but also not cutting them off from any of the functionality within the product or service itself.

The thing to keep in mind is that if you’re going to add any special new user states or guidance, you need to think about how you are extending your product authentically to provide that guidance.

There’s a time and a place for everything, and if you can get everything into the right prioritization, that can smooth out so many user experience problems without you actually having to touch anything within the product itself. It’s just by creating that kind of onboarding ramp, you then take away some of those task-based issues that people experience, because hopefully if everything is working correctly, then once they’re actually into the day-to-day of it, then then they’ll just get used to the product itself.

When you’ve got that strong foundation of core product design in place, then you can start thinking about layers being added for new users specifically.

So when they first come to the product or service, it should be very clear what type of help is on offer and where that help can be found. And then that should maintain across the navigation. So, so that there’s always an area where they know that they can go and get that information, should they need it.

People over-engineer onboarding. The challenge is that people think about it as this discreet thing, and it feels like sometimes onboarding is done for the sake of onboarding.

When I think about good design, I don’t think onboarding is discreet. I think a well designed product would naturally have better onboarding than a poorly designed product.

Better onboarding starts with better product design.

Hopefully, along with your onboarding, you are thinking about the usability of the product itself and so that you are giving them little contextual hints and tips.

Onboarding is about building familiarity with something. So building familiarity with a new thing is an ongoing process, and every user, which you consider a new user, brings their own experience into that equation. So no two users are the same, whether they’re new users or established users.

This is the reality of onboarding journeys, because not everyone will follow the same path because they come through our product in different situations.

Pretty much any project involves dealing with users who have had no experience of the product or service before. So I was really interested in this idea of the, the onboarding as kind of a continuous process and it’s, it’s not about a one and done.

It’s about that, that consistent experience throughout your, your journey with that product.

A new user might be coming with no relevant experience whatsoever, or years of experience in a similar product or even years of experience with your product, possibly under a different account name or with a different business or any other way they might have experienced that product and good onboarding avoids alienating or patronizing any of those user types.

I don’t think any of the things that we proposed were exclusively useful to a first time user, and we ended up coining the term longboarding to describe a transition from a new user to an established user. And we thought that name captured the idea that onboarding is not a thing that happens once in a controlled environment.

Longboarding, I like it.

See, we think that onboarding is a single moment of instruction. And then after that, the user knows everything they need to know about our product and will jump right into building a life with it. That’s where the pressure comes from to get everything right at the start. But really what we consider to be onboarding today is really first-time use.

And that is part of a larger learning curve that represents the true onboarding journey. The true onboarding journey is the collection of activities and learning between someone arriving at your product and getting to a point of core established use.

What are product improvements that are gonna help throughout the product, not just the first time you use it, or even in your first week or your first month.

Concepts like contextual tips, which could be dismissed. Inline status information to help users with on-the-fly decision making.

Little pieces of information to remind them of that onboarding experience. Oh, yes, that means this. I need to put this in here. Which I suppose is related to UX writing and thinking about what type of information do people need in order to achieve this task?

How can we do that as unobtrusively as possible?

I tend to associate UX writing with really, really good microcopy in the most positive sense.

Be aware of how the basics of product design can inherently guide your users before you start implementing lots of fancy UI patterns. These include things like the navigation of your product, its labels and microcopy, affordances, and transitions between different states. These can greatly influence the learnability of your product.

No user is using your app or your website and no others. These days everybody is coming with some understanding of how these things work.

Leveraging established patterns is a good way to ease people into your product. Innovation doesn’t always mean reinventing the wheel or bending over backwards to come up with a new way to achieve something that we already understand how to do. There is value in leveraging existing patterns that people are already familiar with because then you don’t need to onboard them to that pattern and you can focus on what’s unique about your product. There’s no reason to go and over-engineer something new. That isn’t innovation. That’s adding complexity with no user benefit.

I love the idea of designing away, as much as possible, the need to explain concepts or direct people around your app. It just becomes so intuitive that they just instinctively know what to do.

I think that might not always be achievable, but I think it’s a useful lens to look through.

More recently we’ve been wondering about whether non-boarding could be a new thing.

From onboarding to longboarding to nonboarding.

Some products you don’t realize have onboarded you. And I think that’s a huge compliment. If somebody starts using your product or, or eventually becomes an established user and doesn’t even realize they’ve been onboarded. That’s almost the, you know, the holy grail.

One thing I learned from one of my design teachers was that sometimes the best design is invisible. And I really feel like sometimes the best onboarding is invisible.

So unless it needs to be visible, it probably shouldn’t be.

Thank you to James, Jo and Krystal for guiding me through that journey. And thank you for listening.