Making sense of product messaging
Product messaging is really, really hard. Product, Marketing, and Design are all doing it to varying degrees, but no one really owns it holistically. So visibility into what each other is doing and staying aligned is tough.
But it’s incredibly important. These messages are the loose threads brands weave into customers’ minds and lives. That prompt an action or reaction — or worse, nothing. It’s relationship-building.
Yet usually isn’t given the love it deserves because it’s really hard.
It’s a sad cycle! And customers suffer the most. On the receiving end of all these fragmented messages.
In this post, I share my journey of developing Betterment’s product messaging framework.
Problem
Long before I joined, during a hackathon, our in-app messaging mechanism emerged on the Betterment interface. It was a notifications drawer/fly-out/thing. It probably started out simple, and probably worked fine for a while. But then people moved on to other projects, and the notification drawer remained untouched. It quickly became out-of-date in every possible way — brand, design, technical, data, product, and marketing. And, probably because it was built as an MVP, it required a manual, difficult process. But it was all we had, so everyone begrudgingly used it.
A short time before I started, a solution was tested with the hopes of replacing the notification drawer and serve up more personalized messages. It appeared as a banner on our summary page. While it performed well enough to keep around, it didn’t perform well enough to get rid of the notification drawer.
So if anyone wanted to communicate anything to customers in the app, they had to use either the notification drawer or the banner on Summary.
After speaking with designers, product managers, engineers, and marketing folks about how they use notifications and banners, I learned of a few problems:
- Became junk drawers. What I mean by that is there wasn’t a strong, dynamic structure in place. So all the messages we sent, which were essentially 3 different types (promotional, transactional, “advice”), all had basically the same treatment and priority. For example, a time-sensitive message about Brexit had the same treatment and priority as a regular occurring transactional message about dividends.
- Trained customers to have “banner blindness.” Designers started to notice this in user interviews. Most customers had a little red badge on the bell icon in the nav and a banner. This was a problem for us, because obviously our messages weren’t being read, but really because both solutions were designed to really only show one message at a time. So if a customer didn’t click the bell or didn’t dismiss/act on the banner, they never saw the other notifications or banners. Which arguably, because some time has passed, has become even more irrelevant to them. Some customers even went so far to say that they thought the messages were ads. Yikes.
- No ownership. Marketing felt they were the assumed owners of notifications and banners since they owned email, but didn’t feel this was right and didn’t have the resources to be responsible for the features’ performance and improvements. So everyone shoved messaged into these two channels to push information to customers, but no one was responsible for orchestrating the conversation with the customer in mind.
- We weren’t learning. Product Managers wished there was more data, and wished they could do testing easier. The notifications drawer was built just to push and list messages, so all we knew was if a customer clicked on the little bell. We knew nothing about the count of unread messages, which message it was that prompted them to click, nor if they clicked on any other messages. And although the banner was built slightly cleverer, we weren’t doing anything with the click events. We weren’t studying the why nor informing future messages with any new learning.
- Hard to use. Everyone I spoke to said both solutions were hard to use. It was hard to get the right message to the right customers at the right time. With the notifications drawer particularly, it was hard to update messaging and to even to send a message. Engineers talked about the old technology and that to do any work would probably require rebuilding.
So neither solution solved all of our needs, nor did they provide much value to the customer.
I decided we surely can do better. Especially since we’re a financial institution. So not only are there probably regulatory reasons to have solid communication channels with customers in the app, but we believe in long-term investing, which means we’re in a long-term relationship with our customers and need communication solutions that support that. So we needed a holistic solution that gave us some structure on how and when we message customers, specifically in the app.
“Your UI is your product’s humble compensation for not being telepathic.” @mortenjust / source
Research
So, “how are other companies doing this?” I was surprised how little this topic has been written about considering messaging is a tool used by every product. (That being said, Intercom’s blog was an amazing resource and source of inspiration.) At the end of the post, I’ve plopped some of the quick highlights from my readings around the web, including links to the full articles.
“The key rule of customer communication: don’t tell people to do something, motivate them to do it.” Des Traynor / source
Audit
In order to figure out how we should communicate to customers, we first wanted to understand how we currently communicate to customers. The research convinced me that product messaging works best when co-owned by Marketing, Product, and Design, so I recruited a few passionate stakeholders from each discipline to embark on one of the most ambitious audits of my career.
The audit was ambitious because I wanted to look at all the ways we communicate with customers. So it was comprehensive of both in-app messaging and emails.
Our audit took the form of a spreadsheet. It comprised of all in-app messaging, transactional emails, and drip emails, which were then categorized by a handful of themes and accompanied by some notes.
Our spreadsheet had four tabs:
- In-app messaging
- Transactional emails
- Drip emails
- Definitions
With at least these columns:
- Target - the “who”
- Theme - the high-level “what,” like “depositing” or “IRA”
- Name - how we reference this piece of messaging
- Mechanism - how the message is surfaced. So an emails’ mechanism might be “Transactional” or in the app it might be “Tooltip”
- Type - the type of message it is, like “Info”
- Trigger - these could be customer actions, behavior, or status, or time- or system-based events
- Message headline
- Message body
- Primary action
- Secondary action
The result was nearly 300 points of communication. From which, a handful of “types” and “themes” bubbled up. The takeaway was that this is interesting, but not necessarily useful. Although this helped us catalog what, how, and somewhat why we’re communicating to customers, it doesn’t really help us understand how it all comes together — the fluidity of our communication.
Exercise
We had all that juicy data from the audit, so we started by narrowing down the focus to one aspect of our experience. Three criteria we used to narrow was: had to be important to the business, had to be crucial for a customer’s success with our product, and had to affect all communication platforms (in-app and email). We decided on depositing.
Armed with data from our audit and a focus, we mapped out the experience:
No one had ever looked at the experience from this angle before, so it was thrilling to see it all on display in a format where you could look at it holistically and point to things. Three themes emerged:
- Triggers
- Timing
- Target
Overall we learned that there is a bigger difference in how we communicate with customers in the app’s UI versus email than we all originally assumed. Our three takeaways were:
- Volume: Most of our communication happens outside of the app (via email). In other words, the app is very quiet whereas email is very chatty.
- Personalization: Email was tailoring communication based on time, behavior, and demographics. The app was not, and ultimately sounded kind of robotic.
- Coordination: Although there is some push and pull between email and the app, generally they do not have a cohesive, orchestrated dialogue.
Outcome: Our Messaging Principles
To address our first two takeaways and give us some structure on how and when we message customers within the app, I drafted our Messaging Principles.
Here’s the framework I came up with: How interruptive should we be? How and when should we speak to customers? What should our voice be?
Keeping our last takeaway from the exercise in mind, I actively included Marketing, Product, Design, Engineering, and Management throughout the drafting process. Sharing, reviewing, and collaborating with several stakeholders. This effort even spawned a rudimentary UI Copy Principles doc as well.
Now that we had this framework, all that was left to do was implementation — which meant identifying the right opportunity that aligned with one of the company’s goals. As a requirement of implementation, Engineering asked for a decision tree. Meaning, since messaging is co-owned, there should be some guidelines around when to use which solution.
So I started to map out the framework into a decision tree in Sketch. Which was fine, but not very exciting. So I translated that map into a Typeform.
With this framework and decision tree anyone in Product, Design, Marketing, Engineering, or even Management could easily generate the appropriate message to customers.
“It’s not just what you say, it’s where, how, when and to whom, and how often you say it.” Des Traynor / source
Final thought
Messaging tends to be a messy junk drawer. With messages being sent from all corners of the office, with varied objectives. It’s becoming more and more important for brands to focus on relationship-building with their customers. UX is on businesses’ radars but messaging is a really lightweight way to have your product feel personalized.
Research links
Smart vs System
Smart notifications will feel more like a note from your assistant or another human being, and will rely hugely on user feedback, asking quick questions from time to time. Contrast that with a system notification which appears as a little bell icon on the top of your screen. Read more ›
Messaging can be a layer
Focused on mobile, but still an interesting philosophy. The philosophy being that messaging has different layers in the UI and different levels of control and customization. This particularly struck me since most of my experience with product messaging has been solutions where we had fixed “homes” for notification-like things — like a drawer via the nav and a banner on the dashboard screen. Read more ›
Supporting the spectrum of interruption
The interruption level and value of a message live on a spectrum, so we need to design different styles of communication along it. Read more ›
Seven flavors of context
Device, Environmental, Time, Activity (what do users want to do anyway?), Individual, Location, and Social. Read more ›
Experiences are summative
By dividing the time spent into tool time and goal time, you’ll get a real understanding of what a product is like to use. Read more ›
