Intro
Sending an email invite to your friend (i.e. referral) via email that goes to their spam folder is not very useful, neither to the sender nor to the receiver and especially not to the business.
How to plan for when things don't go as planned? A simple answer - create backup plans. In plain English, provide alternative ways of achieving the same result.
How?
The critical part of designing fallback plans is to ensure that they take advantage of other functionality in order to accomplish the same thing.
Suppose email lands in the spam folder, and the user needs another way to send the invitation link. A simple alternative is "copy invitation link" functionality because it relies on a different feature and uses various channels to reach the recipient.
In this case, after copying the link user can share it via any form of communication like social media or even text message. Thus the user has more control and wider choice, and it provides a more personal way of achieving the result.
In other words, it is an entirely different way of achieving the intended result if other ways fail somewhere along the way.
What if
What if the user doesn't see the invite link button? If that happens, we can either make it more prominent OR create another way of accomplishing the task. That may seem like going down the rabbit hole, and sometimes it is precisely that.
At some point, you need to stop because you may start making up some unrealistic cases that have a 0.000001% chance of ever happening (the number is not statistically proven). Low probability does not deny possibility but let’s use some common sense here.
I usually go for three fallback scenarios. It rarely needs more.
If it requires more, however, it could mean that you have made some bad decisions earlier and need to go back to the drawing board. If you decide to design more than 2 ways to do a single task, it pays to consider development time. Don’t overdo it because developers might come for you when you sleep.
Other examples
Most features in a product should have at least two ways of using it.
Think of search, for example. When you visit an online store, you usually have at least two options to find what you are looking for. You can use either the navigation or the search field.
The same principle is used for most core features like signing up (manual vs via social media), adding items to a basket (from home vs from details page) or paying (card vs PayPal). More minor features like adding your profile photo (browse pc vs upload vs past link), creating new items in a table (plus icon vs dedicated button) or cancelling a popup (X icon in the corner vs button vs click outside the box).
All of them have at least two ways of achieving the same thing. Tailoring to different preferences improves usability for you may not see the little X icon, but you might notice the “Cancel” button instead and vice versa. When using standard features, they usually come with these prescriptions, but whenever you create something new, you need to be intentional about adding a plan B.
Using standard features usually “come” with these prescriptions, but if you create something new, you will need to add a plan B purposefully.
Simple action plan
In short, identify the core features and don’t forget to take a closer look at the new ones you have created. If it is an integral part of achieving a certain task, you should find at least one other way enabling users to do it.
Remember to make it simple and obvious. New features have an especially high risk of being misinterpreted, hence having a fallback plan minimises the risk of users misunderstanding features and bouncing from the app.
Takeaways
So here you go.
- Always consider at least two scenarios for the essential tasks of your application.
- Users can behave in mysterious ways but don't chase the rabbit into the hole.
- Pay close attention to new features you create.
- If in doubt, use common sense and standard practices.
- Be conscious of development efforts.
