Case Study: Facebook Story Midcards

Headers

Context

Facebook stories are image posts that disappear after 24 hours. Story midcards are quick promotions that appear in between them. One way to think of them is as first-party ads. They drive growth by encouraging people to create, interact with friends, and see things they might have missed. That said, most story midcards are designed to encourage sharing by offering a ready-to-share suggestion from the user’s camera roll.

I’ve been the primary content designer on Facebook Story midcards as the for about as long as they’ve been around, and my approach to their content design has gone through several iterations.

Challenge

With story midcards, your biggest challenge is time. Because stories are all on a timer, midcards only appear for a maximum of a few seconds unless they choose to stop and look. They also have the option to skip them entirely. Still, you have at least a fraction of a second to attempt to grab them, and you need to make it count. In these precious moments, we often have to communicate complex ideas, as well as a clear call to action. There is very little time to mince words.

The biggest challenge in these projects may have been the fact that my ability to AB test content was extremely limited. Early on, we were so focused on building new cards and seeing what stuck, that there was almost no time or budget to revisit or optimize existing cards. I had to work harder to interpret what was working and draw conclusions from tangential (but not direct) data.

Solution 1: Copywriting approach

Early on, I drew on my background in copywriting and focused on communicating benefits in interesting or clever ways. A sharing suggestion that included music used the header “Make your story sing.” A sharing suggestion that involved replacing the background of a photo using AI used the header “Reimagine your photo.”

At this stage, I was also very concerned about privacy. It can be alarming to see a photo you haven’t actually shared while using Facebook. To make things worse, our ability to suggest photos was very primitive. Most of the time, we would suggest the most recent photo in your camera roll. It’s easy to imagine how this could create panic in users. I worked hard to make sure it was clear this had not been shared yet. This included a design that looked different than a normal story, as well as body copy that made it clear that this has not been shared, and that they have the option to replace or edit the photo before they share it.

Solution 2: “What,” not “Why”

After the midcard ecosystem had matured a bit, we noticed that midcards with shorter copy tended to perform better. A rare content test confirmed this. The prevailing theory was that shorter copy allowed for larger media previews, which were already a known metrics driver. However, shorter copy also performed better when the preview size was unaffected. This led to a much deeper, more meaningful insight: it’s not the “why” of the card, it’s the “what.”

In copywriting, as important as benefits are, they are irrelevant unless it’s clear what you actually have for sale. In most copywriting, this is easy to take for granted, because everyone knows what toothpaste is. The same is not true in tech. I realized that showing a benefit and call to action was all secondary to communicating what the hell the user was looking at.

Given the seconds-long lifespan of these midcards, I also started to second guess the need for body copy. In the past, body copy felt crucial for educating, instructing, and directing users. Soon, I realized that all but the most complex cards could do this with a header and buttons alone

Solution 3: Add a verb

After focusing on the “what,” and dramatically paring down content, it was time to see how much copywriting flair we could add back without wrapping to two lines. More often than not, this was as simple as adding one word: “Share.” A header like “A special moment” became “Share a special moment.” Metrics went up, and we started making almost every header start with a verb.

Button Copy

Context

Any content designer will tell you that button copy can have a huge impact on metrics. They are easy to learn, but impossible to master. For story midcards, the initial content when I started on the team was “Add to story.” However, this decision was not backed by any data, and was causing translation issues. There was also some confusion over what “story” meant, since it can refer to the individual media, or the container. In other words, one could “add a story to their story.” Something needed to be done.

Challenge: 2 groups, 1 button

Adding to the confusion, tapping the “Add to story” button did not actually share the suggestion. Instead, it opened an editor where the user could make changes before actually sharing. This was a necessary step to ensure people didn’t accidentally share and then delete.

The problem was that this meant the button was now serving two different groups of people: people who wanted to edit first and people who wanted to share as is. If I wanted to share, a button that signaled editing may scare me away. If I wanted to edit, a button that signaled instant sharing may scare me away. We needed a way to split the difference.

Solution

My first call was to avoid using “story” to refer to the overall container, except under specific circumstances, and never on the same screen. This change quickly took hold and became a de facto standard throughout the app. Because of how the story product and terminology was set up before my time, it would be impossible to completely undo this issue, but I managed to mitigate it significantly.

The second call was to test CTAs wherever possible. This proved extremely difficult as most Product Managers were not interested in optimization, only launching new cards. However, at a few key moments I was able to run content tests that proved monumental. One insight showed that button copy like “Edit story” and “Preview story” performed poorly, despite the fact that the button literally opened an editing screen. Interestingly, “Share story” and “Create story” performed about 30% better.

Challenge 2: One tap sharing

Product wanted a sharing suggestion that could be shared with a single tap, rather than taking users through the editor. This presented a challenge: Most of our cards took you to an editor. This one would share instantly. “Share story,” our best performing CTA copy, was already in use across most of the fleet. We needed a new CTA that signaled instant publishing, and it needed to be different from “Share story.” In other words, we couldn’t use the same language for “buy now” as we did for “add to cart.”

Solution 2

I decided to use the copy “Post to story.” While this had its own complications (posts are what we call things you share on your feed), there was also a built in understanding among users that “post” = “publish.” While we considered alternatives like “share now,” my reasoning was that contrast was more important. A “Share now” and “Share story” button may as well be identical if you only see them once a day for five seconds. I figured it was better to focus on contrast, even if it meant coloring slightly outside of the lines.

The real eye opener was what happened next. Since the beginning, I’d been pushing a theory that the more speculative the suggestion, the more editable it should appear. If we’re asking you to reshare a Facebook memory (literally something you’ve already shared), and we haven’t touched it at all, we may not need the ability to edit at all. However, if the suggestion is something random from your camera roll, and we’ve just covered it in edits and stickers (something we were trying at the time), we were essentially making a prop bet, adding a number of variables on top of each other. If even one was wrong, with no obvious way to make changes, it was unlikely the user would share. Product resisted this because adding editability to the midcards increased scope. Design resisted this because adding editing entry points added clutter.

One-tap sharing forced their hand. There needed to be SOME way to access the editor. So we added an “edit” button right next to the “Post to story” button. This actually outperformed a variant with no edit button, and therein lies the revelation. By having a dedicated share button and a dedicated edit button, we no longer needed a single button to cover both groups.