Every app and every web site has notifications. Whether they are push notifications, email notifications, phone call notifications, voice mail notifications, in-app notifications, or smoke signals, you are competing for a valuable and scarce commodity: the customer’s undivided attention. There are too many notifications to pay attention to, even if you just dip your toe in the information river now and then.
It must be a problem for a lot of people these days, judging from the number of retweets and favorites on a single Saturday afternoon tweet. Yes, you can turn off all notifications for an app or a service in the operating system of the phone, and this is a solution that may just leave the app unused. Surely there must be a middle ground.
Image may be NSFW.
Clik here to view.
So how can you make your message the one that the customer reads?
B.J. Fogg, a Stanford Professor, suggests that “three elements must converge at the same moment for a behavior to occur: Motivation, Ability, and Trigger. When a behavior does not occur, at least one of those three elements is missing.” (read more about it here).
The results of motivation are obvious – if someone wants to respond to your notification, they will. You can see the positive result almost immediately. Teasing out the reasons for the negative or null result is a bit more challenging. Did the customer see your message and ignore it? Did the customer never see your message? Did the mean to respond and forget? There are many reasons why this outcome might occur, so the next “why didn’t it happen” focuses on ability.
Does the customer know what to do? An extreme view suggests that notifications as a method are an anti-pattern – that is, they are a mechanism that contributes directly to the customer being unable to focus. When the notification happens so often that it becomes background noise, it’s hard to know what’s an “important” notification and the easy thing to do is to just ignore all of them.
If the customer knows what to do, why don’t they do it? They might not have the ability. The notification might make sense to the designer or the programmer who knows the intended behavior of the feature and the customer might not have the same mindset. Or there might be a bug in the system. Either way, when the customer encounters the notification, if things don’t happen right the first time their motivation will suffer, they may question their ability to complete the task, or they may more likely just say “that’s broken.”
And every time there is a “that’s broken” moment the effectiveness of the trigger declines – the reason you wanted the customer to interact in the first place – and you have to have a “one in a row” moment before the customer trusts that the notification is worth responding to in the first place. A great way to save a “that’s broken” moment is to understand when it happens (ideally before the customer does) and reach out and let them know you’re working to fix it.
As for the problem of too many notifications and overall cognitive overload? There is no way to control what’s going on in someone’s phone or in someone’s head. Giving the customer a pressure relief valve like “mark all notifications read” is one way to alleviate the problem before there is a fine-grained solution. Designers might say that adding such a feature is a mark of failure, and readers on Twitter who clearly deal with this problem frequently in apps might just say, “thank you, app developer.”
Image may be NSFW.
Clik here to view.
