10 Minutes to Retain More Users
How designing an intentional post-onboarding experience can reduce churn, lower your SaaS CAC, and increase LTV
This is part three in a five-part series on creating exceptional onboarding experiences.
In this post, you’ll learn:
Why post-onboarding UX is your product's silent killer (and how to fix it)
Designing for reality: Match your onboarding UX to actual user behavior
Several approaches to reduce churn and make users more successful after sign-up
Congratulations, you’ve just secured another new user for your workplace SaaS tool. You ran some expensive Facebook ads, put in a bunch of hours to climb to the top of Product Hunt, and now someone from a Series C, high-growth startup is your newest user. Get their experience right, and the virality potential is off the charts. Get it wrong, and you’ll burn your runway going through that acquisition process from scratch again and again. They were intrigued enough to check out your landing page, which converted them into a free trial user. Now you have 14 days (but really, more like 14 minutes) to make your case to them as a valuable piece of their company’s monthly budget.
Your onboarding process was pretty straightforward - you collected their work email, asked them to invite a few teammates, and had them answer a few questions about their use cases and their company makeup. We’ll call it a 7.5/10 (we can help make it a 10), and now they’re excited to get started and see what they can accomplish with your product. But there’s one (big) problem. After all that, you’ve onboarded them into a Home view with a left rail nav that has a dozen different sections, most of which are missing context and, at best, have a title and a button to “Add New”. They click into 5-6 of the sections, unsure of what to do, and eventually decide that it’s not worth their cognitive load to figure all of this out right now. They tell themselves they'll return later, but you both know that's not true.
Typically, when a potential user finds you, they’re not browsing in perpetuity with hours to burn on trialing. They’re not at the mall, going to a half-dozen different stores and trying on a couple of items at each store. The cognitive load of doing this - both in shopping and in software - is pretty high and leads to fatigue more quickly than we imagine.
If you’re designing for users to be in this mode, you’re asking them to be open to at least a couple of hours of browsing, sampling, signing up, and trial-and-erroring your tool. This assumption also means they’re likely doing this with other tools in the space as well, making you stand out even less. This is - for the most part - not a good assumption to make when designing SaaS tools.
But what’s the alternative? In the shopping analogy, it’d be something like:
User has a friend’s wedding coming up this weekend and needs something to wear to the Friday night reception event (problem to be solved)
Their closet is a bit stale, and they only have 72 hours before the event. Not enough to buy online, where browsing is more feasible (constraint)
In the first 12-24 hours, they do a bit of online browsing to understand what styles are in and what options are available. This is done in their free time and they spend, at most, 10-15 minutes in a block of time looking at these options (Research - notice how little bandwidth is committed to this)
On Thursday afternoon, they cut out of work a bit early to hit the mall, with 4 stores in mind that have styles they like. While they’re willing to visit all four, they won’t visit all 4 if store number 2 has what they need
In each store, they’re evaluating fit, price, style, and available accessories for each jacket that they’re trying on. They’ve already done the background research to understand their own needs, and now they need to find something that meets all - or most - of them (solution seeking)
The take-away here is that very rarely in any purchase decision-making process is someone allocating a ton of cognitive bandwidth to passive browsing or research. For larger purchases - homes, cars, etc - this is more frequent, but for something like consumer goods and software, it’s rarely the case. Instead, users have an acute problem, a limited capacity for browsing, and a set of criteria that will get them to purchase. They’re more likely to browse multiple products, trialing their problem in each. If the tool works for that problem, they’ll try and solve another, and so on. If it doesn’t work, on to the next tool.
Ideally, your SaaS product will solve a handful of specific problems really well, especially in its early stages (although there seems to be a proliferation of super generic workplace tools popping up for some reason, but that’s for another day). These 3-5 problems should be easily translated into product features, and not scattered amongst a dozen half-baked features. This is critical to onboarding success, which is critical to stickiness, which is critical to growth. Put another way, it may feel silly to be so specific about such a seemingly small and often templatized component of software, but screwing this up means not even getting a chance further down the funnel with most users.
If you’ve structured your product and marketing this way, 3-5 specific user problems and targeted features to solve those problems, here’s what your workflow now looks like when onboarding a new user:
Greg is in a meeting with his team. Someone raises a problem with the available tools for solving problems X, Y, Z. Their manager assigns Greg to find a tool that solves most of those problems without breaking the bank
After the meeting, Greg heads to lunch and does some passive browsing on Product Hunt, Reddit, etc to find out what other teams use for this same problem. He checks a few out, but only has 30 minutes and needs to eat, so he shelves his browsing for later
After a few more hours of meetings and work, he has 45 minutes at the end of his day to do a bit more browsing. Now he’s getting ads for competitors in the space, and checks a few more out. He’s now at mental capacity for how many SaaS tools for Problem X he can care about - let’s say that number is 4-6
He spends a few minutes testing out three of them today, with his team’s specific problems in mind. Each time he signs up for a dummy account, he thinks specifically about solving the 2-3 biggest sub-problems his team has
If it’s not clear immediately after sign up how he should solve those 2-3 sub-problems, he closes that tab and that product is discarded from his calculations, never to be thought of again (or at least not for 6-12 months)
This is where the importance of the post-onboarding task flow comes in to play.
When Greg arrives to a Home view that doesn’t have any information about what tasks are more important than others, which problems and sub-problems your tool specializes in, or what his first steps should be, he’s almost certainly not sticking around to find out. He needs your help as a product designer to understand the order of priorities in your tool. In practice, this looks like: (in order of quality and effectiveness)
An Onboarding Checklist
Opt-out tours
Hover/click tooltips
A chatbot offering assistance
A Help button that takes you to a help center
A Contact Support button
Onboarding Checklists
These are criminally under-utilized in SaaS tools today. Many well-established/enterprise tools will have a useful checklist, but I’m always surprised how infrequently startups will leverage them to help users become familiar with their product. This is especially true for tools that are broader in scope and have multiple functions/feature areas that users might be attracted to. For example, some users might have seen marketing for Feature X and others for Feature Y, and dropping both of them in the same starting point without a map or a compass almost ensures that they’re not going to have a good time.
I assume startups opt out of onboarding checklists for one of two reasons:
It’s technically a bit more involved than tool-tips or a help link, meaning more dev costs
Product teams don’t understand the full upside of implementing one
But these are really two sides of the same coin and make checklists even more compelling as a solution. While implementing something a bit more technical - say a five-step checklist where users can either mark items as complete, or those items are auto-updated upon user completion - not only do you help users understand what’s important and where to find it, but you also get some of the most valuable data about product usage that you could ask for. As a designer, this makes the case for your PM/Eng partners - if they’re any good - a no-brainer. They spend a day or two creating an onboarding checklist, and in exchange they get insights about nearly every user who onboards, including what tasks they care about, where they get stuck in their first experience with the product, and what minimum completion threshold signals stickiness for a user (eg if a user completes 3 of 5 items, they are still a user one year from now 60% of the time).
Onboarding checklists create a great user experience, provide a treasure trove of insights to PMs, and are not a massive technical lift - they should be a no-brainer for just about any SaaS tool in 2024.
Opt-out Tours
You’ll notice that I’m explicitly calling out opt-out tours, and not just product tours more generally. This is because product tours are one of the most frequently botched tools I see in software products today. I’ve outlined some principles for good product tours here, but the ideas behind those principles are largely the same as with onboarding checklists. Users will have different priorities and immediate needs when onboarding to your product, and so you shouldn’t force them to sit through a bunch of features that they don’t care about. Even worse, you’ll often see product tours that don’t effectively prioritize the tool’s features, and instead will highlight features that don’t really matter to the user or the builder. If you’re going to take this approach, ensure you’re focusing on a the fewest, most impactful features possible.
Bonus: product tours and onboarding checklists aren’t mutually exclusive, so once your tour is over, you can still have a checklist for users to action.
Tooltips
If product tours are a one-time endeavor, then tooltips are their evergreen cousin. Tooltips are effective and practical because you spend very little time building them once, and then let them list in the UI for a long time. At any point in their journey, users can reference back to them to remember how to do something that they learned about in the tour or their checklist.
Tooltips are inherently supplemental though, to they’re often best leverage in combination with one or more of the other approaches here. Dumping a user into a home view with only some tooltips to reference is only a marginally better experience than dumping them in the UI with nothing to reference.
When done well, tooltips are minimally invasive, convenient, and serve as a great supplement to your other onboarding efforts. When done poorly, they’re rarely used and don’t provide much additional value to users.
Chatbots, Help Centers, and Support
These options can be lumped together because they are all serving similar functions. They’re not onboarding-specific, they’re evergreen, and they require more work than users might care to put in after immediately onboarding. If you’re banking on these to be your post-onboarding solution to user questions, you haven’t designed a great product.
Much like tooltips, these options should be reserved as complimentary pieces to the rest of your onboarding efforts, Unlike tooltips, they require a lot more user bandwidth to find the solution they’re looking for. Generally, these options should only be used as a last resort, or to help users once they’re already engrained in your product and need to level up from 1-to-10 or 10-to-100, but not from 0-to-1 in their product usage.
Which of these options you choose to build will be dependent on many factors specific to your company and product, but it’s universally true that these options should not be your only onboarding support for users. If they are, you’ve got some massive low-hanging fruit to help your user retention and conversion numbers.
In product design, there are trade-offs made at every checkpoint in a user journey. But the post-onboarding experience is being sacrificed far too often in modern SaaS tools and it’s hurting not only the users who might have their problems solved by your tool, but you as a product team who are building things that users will likely never find.
So spend a few extra days in design and dev to help users understand where to find their solutions in your product, and you’ll see retention, CAC, and LTV metrics improve without much other effort. Worse case, you’ll get even more data about where your product is falling short and can iterate from there.
As always, if you’re looking for a design partner to help strategize, research, or design solutions like this, Discohouse is accepting new clients and would love to hear about what you’re working on.