How Much Help is Too Much Help? Less is More. How to Use Custom Events to Avoid Frustrating Tooltip Overload in SaaS
I was walking near my house this week when I noticed a couple of construction workers putting up these ‘Quiet please’ notices on the walls:
I stopped and couldn’t help but think ‘Duuude. You don’t need to cover the whole wall with them. One or two would do the trick. *Seven* just turn the wall into a yellow eye-sore, without actually increasing the effectiveness.’
This reminded me of the experience I’ve had with some SaaS tools. Seeing too many tooltips, notifications, or being dragged on a lengthy product tour (that completely ignores what you need, want, and know already!)
This is not going to make your user happier, or more efficient at using your app. It can actually make them pretty frustrated.
That’s why I wanted to talk to you about the topic that is one of our most frequently asked questions:
How much handholding does a new user need? 🤔 And how many tooltips are too many tooltips?
How can you prevent the nasty ‘tooltip overload’ with custom events?
In this post, I will answer this question. Meanwhile, grab a video TL;DR:
I think there’s a common consensus that you do not want to:
1) Show notifications or in-app experiences to people who don’t need to see them (because, e.g. they are too early – or too far – in their user journey. Or because they have not performed a certain action that is a pre-condition for performing the one you want to notify them about.)
2) Show notifications/ tooltips to people who don’t want to see them, because:
a) they have already seen them and performed the required action (you’d know if you set a goal of the experience to match the custom event you want the user to perform);
or b) because they have seen them and actively dismissed them, indicating they are not interested in what you have to say.
(Believe it or not, it happens. They’re not your mum.)
How do you avoid these situations?
The short answer is:
❌ DON’T: User linear flows and demographic triggering
– Use linear product tours with multiple experiences that are triggered in a row and time-based (e.g. shown to everyone who has just signed up) regardless of whether someone has actually completed any of the required steps. – Use time-based experience triggering in general – trigger experiences based on custom events, i.e. actions that the user has already performed. – Fail to ask the user for their Job-To-Be-Done, and show one generic experience flow to all of them.
Let’s take a look at this example: an email marketing tool that took me on a tour (and got me to do nothing at all):
This is exactly why I tell people they shouldn’t use Intercom product tours (unless they don’t care about their activation rates and want to annoy their users.)
Don’t get me wrong: Intercom is a great tool for in-app communication, but when it comes to onboarding experiences…the tool is really too basic.
As you can see – the only triggering conditions are purely demographic. How do we know this new user has any contacts to upload at all? 😳
Assuming they do have an email list to upload in the first place – which again, is a guess – Don’t you think it would make sense to wait until they have actually uploaded the email list (STEP 1), before you suggest them STEP 2 – how to create a newsletter?
✅ DO: Use branching logic and custom events
– Use branching logic for your in-app experiences (e.g. show experience B only to users who have seen experience A, *and* belong to the ‘new user’ segment. / Show experience B only to the users who have achieved the goal of experience A, *and* have signed up less than 30 days ago.)
– Make sure your tooltips are triggered contextually (in the right place, at the right time.) by restricting them to the users who meet specific engagement criteria.
– Make sure you exclude the audience who has already done what the experience is asking them to do (e.g. by showing the particular step only to users for whom a specific custom event has not occurred yet). Let me show you that on an example.
How to create a branched onboarding experience with custom events to avoid information overload?
You want your users to complete two actions that are conditional – STEP 2 depends on completing STEP 1 e.g. 1) Add an email list, 2) Create your first newsletter.
OR: 1) Add your social media accounts 2) Schedule your first post.
Let’s take that example to see how you can create an effective onboarding experience – one that shows the users only the tooltips that are relevant to them (because they have or have not achieved some goals – as we know from custom events – already).
We want our social media scheduler users to accomplish two goals as a result of the experiences:
1) Add their first social media account(s)
2) Schedule their first post
STEP 1: Adding social media account(s)
We started the experience from asking our new users to add their accounts right after seeing the welcome screen:
This is how the experience looks on the ‘backend’:
We restricted the experience to only the users who:
– have signed up less than 3 days ago
– have seen the welcome screen
– and have not added the accounts themselves yet:
Source: Userpilot. Why not see how to build branched tours in your product?
That way, we made sure only the right people see this tooltip.
Further – we set a goal to ‘connect account’ (this is a custom event passed by the devs) – that way we will know whether the user has actually achieved the goal of the experience or not.
Based on that we will show them the next step only if they completed the goal of the first step.
STEP 2: Scheduling their first post
Now, you don’t want the users who have not added their accounts to see a tooltip urging them to publish their first post (as there would be nowhere to send it!).
In order to trigger the ‘Schedule your first post’ tooltip to the right users only (the ones who completed step 1 – added their social media accounts) -we had to restrict the second experience only to the users that have added their accounts:
This way, we know that only the right people will see this tooltip.
Again, we set the goal of this experience to the custom event (so we know how many of the users who’ve seen it have actually scheduled their first post, and tweak the experience to improve the goal completion rate).
That way, the users see only what they should see – and don’t get overwhelmed by a linear product tour asking them to do STEP 2 before STEP 1 (see Get a Newsletter’s example above). Nor do they get frustrated by a tooltip asking them to do what they have done already.
Simple! Building this whole branched experience with custom events in Userpilot took us less than 10 minutes.
Want to see how you could easily implement these branched experiences based on custom events *right* into your product without coding? Why not jump on a free consultation with us?