So far in this series, we’ve covered:
- How apps are different from websites and have their own content ecosystem
- App indexing and how it helps users discover your app through search
- Push notifications and how they help your app keep users engaged
Following the APPS acronym, it’s time to turn our attention to what’s probably the largest cache of content in your app’s universe: product content.
What is product content?
When I say product content, what exactly am I referring to?
I’m talking about any content that appears in your app, including:
- Form field labels
- Error messages
- Product descriptions
- Terms and conditions
- And more
Because this is such a huge topic, let’s break it down a little further, and talk about your product content’s substance and structure.
Substance: the content itself
A few weeks ago at Google I/O 2017, Google’s UX Writing team gave a talk on the topic, “How Words Can Make Your Product Stand Out.” In that talk, they offered this framework for approaching writing content for apps.
Standout UX Writing from Google. (Shared by Guy Ligertwood on Medium.)
- Surviving is what you say. Are you giving your users the information they need to complete the tasks they want to complete?
- Thriving is how you say it. To thrive, you need to tap into your brand’s voice and tone guidelines to provide interest and even delight, when appropriate.
Surviving: delivering the information users need
To see this framework in action, let’s compare two travel apps (with their names redacted) to see how they accomplish similar functions using different content.
This fall, I want to travel from my hometown of Charlottesville, Virginia to Santa Barbara, California for my grandmother’s 100th birthday. When I look up flights for this trip, I’d really like to know upfront whether a flight will get in after midnight (in other words, is it a red-eye?).
In App A, I see this when I look at an overnight flight:
App A indicates an overnight flight with a small green date above the arrival time.
The fact that it’s an overnight flight is not highlighted—in fact, the first time I looked, I completely missed the green “Tue. Oct 03” in the upper right. If I select this flight, here’s the message I see on the next screen.
App A shows an alert that says, “Please note this flight involves a date change.”
I don’t know about you, but when I book a flight online, I’m nervous to begin with. My worst nightmare? That I’ll book the wrong dates and have to change my flight later.
When I see an alert that says, “Please note this flight involves a date change,” it makes me even more nervous! I worry that something is going wrong with my booking. I will now abandon this booking process, and try another method.
Let’s see how another app handles this information. Here’s the list of flights I can choose.
Viewing two flights in App B, one of which is an overnight flight.
On the screen that lets me choose my flight, App B doesn’t give me any text that indicates the flight is overnight. But it does show a timeline at the top (with times in both the zone I’m leaving, and the zone I’m arriving at). So there is a visual indication of the timespan of my flight.
What happens if I choose the overnight flight?
App B shows a graphic of a plane flying at night to indicate your selected flight lands the next day.
I really like this graphic treatment: it’s bold, beautiful, conspicuous, and best of all, easy to understand. I don’t wonder what it means, or whether something is going wrong with my booking.
Thriving: using voice and tone to surprise and delight
Let’s see how two apps convey similar content in ways specific to their app’s voice and tone—informing and delighting users in the process.
I just became aware of the trend toward “Basic Economy” class on flights. Essentially, Basic Economy is a severely restricted version of coach—you can’t bring a carryon, sit with your family, or change your flight.
App A uses a table to show details about Basic Economy restrictions.
App A does a great job conveying these restrictions in a table. It’s super-clear to me what I don’t get with Basic Economy, and what I do get with Economy class. (In fact, I have to click the slider on the bottom that says, “Basic Economy works for me” just to select the Basic Economy fare!)
App A definitely wants you to understand this information. Clarity carries the day here.
Now let’s see how a different app conveys this data.
App C uses a cartoon bear to call attention to Basic Economy restrictions.
Like App A, App C clearly conveys the data about Basic Economy that I need to know: the fare is “nonrefundable.” What they do differently has to do with their brand voice: they use the Fair Bear (yes, that’s “F-A-I-R” not “F-A-R-E” for some reason) to get my attention.
That’s interesting, isn’t it? App C could have used a similar treatment to App A’s table. They could have just written it out in text. But instead, they chose to have a cute bear deliver the news. Now I’ll associate the Fair Bear with this app, and I’ll know to look for restrictions when he shows up.
Now that we’ve seen how different apps accomplish the same tasks with very different content, let’s talk about the structure of an app’s content.
Structure: publishing app content efficiently
As a content strategist working on mobile apps, you have a high likelihood of managing content across platforms—minimally iOS and Android, and likely web as well. In that case, you’ll need to consider an omnichannel content strategy.
Omnichannel content strategy is a huge topic, one that could take up its own blog series. So I won’t provide an exhaustive discussion here. I just want to provide you with an overview and some resources, because this concept is key to developing content for apps.
‘Omnichannel’ content is so-called because it needs to be able to appear in all channels. We want the content to be reusable, so that we can enter it once and manage it in one place, rather than duplicating it in a separate content management system for each channel.
InVision does a good job describing the role of a “decoupled” or “headless” content management system (CMS) in allowing you to publish the same content to multiple front ends (apps, web, and more).
Your goal is for the same repository of content to feed into any number of front ends—from a website, to native mobile apps, to wearables, smart TVs, and even devices we haven’t invented yet.
At WillowTree, we’ve used the headless CMS Contentful, though there are others out there. A headless CMS stores our content in a kind of database, or as an API, and the front end reaches out to grab whatever content it needs. It also separates content from the presentation. So each platform (apps, web, wearables) can have its own front end design, and the content adapts to it.
In order for content to be compatible across devices, it must be stored in the CMS in a particular way: in small, modular pieces (we content strategists sometimes call these “chunks”), rather than huge monolithic pages or “blobs.”
We call the process of “chunking” our content “content modelling,” and Rachel Lovinger has written about it at length in A List Apart.
Here’s an example of a partial content model for a travel app. (There are various ways to do it, depending on the system and business, so this is simply one concept.)
We “chunk” content into separate content objects (indicated by squares), each with attributes (such as flight type and leg type).
One way to model content for a travel app. Alerts are separate content objects and would be stored once each in the CMS, then pulled into each front end separately.
If a company followed this model, for example, they could use the same “Lands next day” alert text for both their website and their apps. And if they decided to change it to “This flight lands the next day,” they would only need to change it once.
If you want to learn more about omnichannel content, I highly recommend the book Content Everywhere by Sara Wachter-Boettcher.
I hope you found this discussion of product content useful. In our final post, we’ll talk about how to get users to discover and download your app using App Store Optimization (ASO).
Editor’s note: This blog post is the fourth in a series about the mobile app content ecosystem: