How many notifications did you receive on your phone today? More than you realize (or maybe even count), I bet.
Looking at my own lock screen, I see a handful of likes from social networks like Twitter, Facebook and Instagram. There are some breaking headlines from The New York Times and The Washington Post. Two colleagues pinged me in Slack. There’s a calendar appointment and a weather forecast. Headspace is inviting me to meditate. A notice that the flowers I sent to my wife were delivered. And an email from her as well.
And I haven’t even yet unlocked my phone.
In another context, all of this might be annoying and verging on spam. After all, attention is an acutely scarce resource. But on the contrary, I not only welcomed these alerts but also interacted with most of them.
Why? Well, part of it is choice. I personally chose which apps have the privilege of alerting me, and I know I can tailor the alerts whenever I wish. At a basic level, that control is thanks to how my phone’s systemwide notifications framework is implemented.
But my engagement with the alerts themselves fundamentally is driven by the apps that push them. I’ve muted more than one app because its notifications were irrelevant, overly promotional or showed poor insight into how I wanted to use the service.
And there’s the rub: When done right, notifications improve the user experience and drive engagement and growth for apps and services. But when done poorly, they can turn off users and even lead them to abandon the app altogether.
So, as product managers, growth marketers and customer experience champions, how do we find the right balance with notifications? That’s a question that might deserve an entire series of discussions about design patterns and business goals. But perhaps the best place to begin is simply by considering how, when and why notifications work to support a great experience and increase user engagement.
The four flavors of notifications (and when to use them)
Mobile notifications have grown to be a core part of the user experience for today’s apps and cloud services. They’re highly functional, actively valued by users and absolutely essential to driving app engagement.
When we talk about “notifications,” I’m referring to four basic mechanisms. They each have strengths and weaknesses — or rather, each is best suited to different use cases — but they all play important and complementary roles for communicating with users.
In-app notifications: Sticky activity
In-app notifications are part of an app’s or service’s own UI. Facebook’s notifications menu is a prototypical example. For many users, it’s become one of the primary ways of interacting with the site. That power is why the social network considers it to be a core feature of its UX and has implemented the notifications menu across all its platforms. Its highly effective red notification counter has become a standard part of how similar menus work on other services as well.
In-app notifications are especially well-suited to presenting highly granular and frequent information, because the alerts are only seen while a user is actively engaged with the app. They also have the most flexibility, because they’re entirely within the control of the app itself.
Push alerts: Consistency and engagement
Push alerts use a mobile (or desktop) platform’s native notification framework. Specifics vary from platform to platform, but the approach to notifications in Apple’s iOS is what most of us think of when we talk about push.
Unlike in-app notifications, which can be highly idiosyncratic, push messages must adhere to guidelines established by the platform. That consistency makes them easy for users to parse (and to control).
Push notifications are effective for both presenting essential alerts and for encouraging return engagement when a user’s not actively in an app. But there’s a balance that needs to be struck: If messages are pushed too frequently or seem irrelevant, they’re going to be silenced. And, like tweets, they require skillful copywriting and timeliness to remain effective; dully repetitive alerts quickly get tuned out (or even silenced).
Text alerts: Limited, real-time interruptions
Text alerts are delivered using the SMS infrastructure of mobile telephone networks. That means they’re subject to a number of technical and functional limitations to message length, interactivity and more. (Fun fact: The 140-character limit on tweets — an attribute that’s come to define Twitter’s core identity — has its roots in the service’s initial idea to operate as an SMS-based application.)
Text messaging also is a relatively “low-permission” zone — users don’t want to receive texts they don’t expect.
But text alerts do have one essential quality that makes them an important part of the notifications toolkit: Users open SMS messages within three seconds of receipt 90 percent of the time. That’s why SMS is frequently used for important real-time security alerts and verification codes for two-factor authentication.
Email notifications: Notifications of record
Email needs no introduction. It’s a communications workhorse for conveying all manner of information, from personal notes to marketing offers and everything in between. But notifications and other forms of transactional email have become one of the most important ways for apps and services to build trust and drive user engagement. (Twitter, for example, drives a serious amount of traffic back to its service with notification emails.)
Email’s status as a universal, ubiquitous medium is part of that. And it’s deeply entrenched in how we use our devices and communicate. (After all, we use our phones for email far more than we do for calls!)
Finally, unlike other ephemeral notifications, email has permanence — think about how often you’ve saved a shipping notice, purchase receipt or signup confirmation for later reference.
For great CX, think holistically about notifications
Unfortunately, when one type of notification — push, for example — is implemented, it’s not unusual to find that notifications as a whole haven’t been considered in a consistent, purposeful way. There are different reasons for that: a lack of time or resources, technical difficulty and, like so much else, narrow definitions and the siloing that comes from different teams within a business owning different parts of the app.
But that kind of disjointedness is a kiss of death for the user experience. Instead, like so much else in good CX, product teams should approach notifications from the user’s perspective.
So approaching notifications in our apps and services for CX means thinking about the goal, not the means, and starting with questions, not implementations. And by that, I mean some really fundamental questions, like:
What information do your users want or need to know?
What do they need to know right now?
What information do they want to save?
What are the actions you want them to take?
What are their references for notification frequency? For channel?
Then, and only then, should we start thinking about which types of notifications are most appropriate to the need. In some cases, it’s likely to be “whichever the user prefers.” But in others (security alerts, for example), we might want to limit the choices to ensure information critical to safety doesn’t slip through the cracks.
“Customer experience” is a term that’s easily overloaded with meaning. But no matter how you define it, trust is a big part of it — trust that a company understands my goals and needs, trust that an app will work the way I need it to, trust that my experience will be emotionally satisfying. And sometimes, trust comes from simply knowing what’s going on and feeling in control.
You know what? That sort of trust-building and engagement is what notifications are all about. And it’s why thinking about notifications should be a key part of any CX plan.
Comments