Forget food videos on the feed: The Atlantic is sailing against the winds, opting for longer videos as part of series that are distributed through YouTube.
The 160-year-old publication, which has a small video operation compared to the distributed-media publishers that get billions of monthly views on Facebook, is focusing on creating longer videos that dive into serious topics such as science and politics. This includes weekly video series featuring its lineup of star editors and reporters, as well as animated videos and documentary features. At the same time, The Atlantic is prioritizing YouTube as the platform to distribute this content. The reason: Not only is YouTube the place where this type of content performs best, but YouTube is still the best place for publishers — especially smaller ones with a limited amount of resources — to reach a lot of viewers while also generating consistent revenue from pre-rolls. (YouTube typically takes a 45 percent cut of ad revenue from pre-rolls.)
“We tend to be pretty focused on profitability — new investments require that revenue comes along with them,” said Kim Lau, vp and gm at The Atlantic. “The big shift for us is the realization over time that while our audience at TheAtlantic.com is interested in and increasingly aware of our video, being able to grow [our video business] with just that audience is a little bit of a limitation.”
With a billion daily users on YouTube and countless videos to watch, YouTube certainly offers a reach that few others can match. It also offers a lot of noise.
The Atlantic’s approach to standing out is focusing on distinctive content that works well on YouTube’s platform, rather than pushing out as many videos as possible. Today, it’s launching a new science video series called “You Are Here,” which will feature The Atlantic’s science, health and technology writers exploring topics such as why Americans smile so much, the science of cool and whether social media is changing friendships. “You Are Here” joins other weekly video series such as “The Atlantic Argument,” a commentary series covering the latest news and political issues, and “Unpresidented,” which explores the new American political landscape. These shows follow a weekly release schedule.
“We know YouTube rewards consistency,” said Kasia Cieplak-Mayr von Baldegg, gm and executive producer for Atlantic Studios, “but we also try to jump on the news cycle, especially with ‘The Atlantic Argument,’ when there is something of huge interest for our audience.”
While these shows aim to bring more regular viewers — and subscribers — back to The Atlantic’s YouTube channel, they are also in the service of a handful of longer documentaries The Atlantic puts out every month. The publisher typically releases two or three documentary features, typically running for 10 minutes or longer, every month. These go in-depth on topics ranging from Nazi Richard Spencer to American towns that welcome refugees.
With this approach, people are beginning to come to The Atlantic’s YouTube channel and spend time watching videos. The average watch time among The Atlantic’s 41,000 subscribers was more than three minutes last month, the publisher said.
“Among the distributed video platforms, YouTube is so strong at creating an experience where people are watching longer videos and with the sound on,” said Cieplak-Mayr von Baldegg.
Of course, many scale-seeking digital publishers are still prioritizing Facebook because that still remains the best place to grab a lot of views in a short period of time. The Atlantic, like other publishers, is not ignoring Facebook. But it’s honest about Facebook’s limitations right now. The Atlantic will cut shorter versions of its videos — and include captions — for Facebook.
“Focusing on YouTube now allows us to bring monetization and high-quality storytelling all together in one place,” said Lau. “We’ll continue to dabble on Facebook.”
Our last major redesign in April 2015, explored the idea of “a real time magazine” and the implications therein. Stories had large images, the page was fully curated, and there was modularity, which in theory provided editorial flexibility. The hope was that we could give the entire page the same care and attention as the top of the page. Over the next year, through A/B testing and analytics, we found that putting more stories higher on the page and reducing the size of the images increased engagement. So while the original vision was off the mark, through iteration we ended up with a performant page that has served us well for the past two years.
But as time went on, and editorial needs changed, we started thinking about where we wanted to go next. We began by talking to our readers, to find out why they use our homepage. We spoke with our editors, to learn about operational pain points and how they are thinking about The Atlantic going forward. And finally, we spoke with our sales team to better understand how the homepage fits into their strategy.
We embarked on a series of user tests in 2016 to help us better understand how readers use the homepage. We spent two days with 10 readers where we tried to contextualize their habits and bring nuance to our quantitative data. Some highlights:
Readers mental model is much different than our own. Those that use the homepage treat it as an index of the site’s content, not a subset.
Related, it was difficult for users to find the latest stories.
Readers often have preferred writers that they look for.
When browsing on a traditional computer, e.g. something with a keyboard and mouse, they almost all had two modes: discovery and consumption. In discovery mode, most readers opened multiple stories in new tabs before switching to consumption mode. As one reader said: “I do the filtering first and the reading second.”
A large portion of homepage readers access the site through the homepage only.
Those who watch video tend to do so in the evenings.
We interviewed the editorial team to find out how The Atlantic editorial strategy has changed and what we can do to improve their workflow. We discovered that an entirely curated homepage, while nice in theory, is operationally difficult and taxing on the team. However, it was clearly expressed that they wanted to maintain a curated presence, albeit a dramatically reduced one. The other request was more density and clearer hierarchy so that they could be more flexible when there are multiple stories that they want to highlight.
We distilled our competitive, stakeholder, and user research into two points:
Designing based on these questions, we ended up with two distinct sections: important and curated (top) and new and programmatic (bottom). By establishing this framework, we were able to meet editorial and reader needs in an elegant and coherent manner.
Important and Curated
Anchoring the top is a lead story, a familiar paradigm to readers and editors alike. Then we have two areas which serve to showcase our breadth: a discrete auto-populated News section and a group of three curated stories which can each have related links to provide more depth and context.
One of the major changes we implemented was adding a new area called Featured. By playing with the hierarchy, this area serves to highlight stories which might not be in the news, but that we think are worth our readers time.
New and Programmatic
This section is anchored by the Latest module, a reverse chronological river of stories, so it’s easy for frequent visitors to catch up on what they missed. We redesigned our river item to be at once more scannable for readers and flexible for editors. Given our increased focus on video, we also added an inline video module to showcase our latest content.
Second, we moved our Popular module up the page. Users would go hunting for a list of popular articles, so rather than make them look, we surface it as soon as possible.
Third, we implemented a new Writers module which functions similarly to the river: when a writer publishes a new article, they appear at the top, and as more stories are published, they move down the module. The intention is to expose both established and newer writers to our audience in order to build both trust and familiarity.
Finally, we implemented multiple promotional modules that were designed to be flexible and able to promote anything from a newsletter, to a podcast, to a new magazine issue.
Five years ago our President (then Editor), Bob Cohn, reflected on the role of the homepage in 2012. He noted that “the homepage is the single best way for editors to convey the sensibilities and values of their websites […] the homepage is, as the marketing team would put it, the ultimate brand statement.”
I think those words still ring true. A “brand statement” for The Atlantic in 2017 meant that we should focus on the stories, make it easy for people to find something to read, and get out of the way. While obvious in retrospect, aligning the company around that vision takes a lot of upfront work, but in the end is worth it. However, despite our research, prototyping, and deep focus on our users, I suspect we got some things wrong. We already have multiple A/B tests planned for launch and I’m excited to see how the design evolves.
The Atlantic is toughening its stance toward ad blockers.
Starting April 10, the news and culture publisher will require people using ad-blocking software to pay $3.99 a month or $39.99 a year for an ad-free version or turn off their ad blockers and view an ad-supported version of the site. The Atlantic planned the move to follow its converting the site to https. Publishers have been undertaking that process to provide secure connections for visitors and in anticipation of Google giving preference to https sites in its search results.
The Atlantic has been preparing ad blockers for this move since October, when it offered that choice in a message window. It was a soft wall, though, as ad blockers could continue visiting the site for free if they closed the window. Now, that escape hatch is going away.
Lately, publishers have been taking the brute-force approach to ad blockers or asking readers to pay up to help support the heavy cost of digital media. This move by the Atlantic isn’t so much geared toward getting readers to pay — just half of 1 percent of the ad blockers opted to pay up since October, and The Atlantic is pushing subscriptions to its magazine in other ways.
Slate editor-in-chief Julia Turner last week wrote a piece on the site asking readers to whitelist the site, while revealing it lost $1.5 million to $2 million from ad blocking. Slate does not block ad blockers from accessing content, however. The Atlantic estimates that ad blocking cost it $3.4 million in 2016.
Ten to 12 percent of visitors to The Atlantic have ad blockers installed. And while the percentage of people ad blocking has leveled off, it’s not likely to go away long-term, given that young people are more likely to ad block.
“To me, starting the conversation and helping them understand the value exchange is important,” said Kim Lau, svp of digital and head of business development at the Atlantic. “We have to start that conversation about how we make our money. We need people to understand there is a real dependency on advertising. We have journalists we need to continue to pay to do great journalism that’s critical at this time.”
The Atlantic fully expects 60 percent of those ad blockers to abandon the site when presented with the message. There’s some anxiety about that. But as Lau sees it, those people aren’t contributing financially to the site, so losing them won’t have a big financial impact anyway.
The publication has been taking on ad blockers for more than a year, starting with messages requesting they whitelist the site. Some publishers have circumvented ad blockers and served ads to those people anyway, but The Atlantic didn’t go that route, lest it upset people who already expressed a clear preference not to see ads.
How publishers communicate to ad blockers has proved to make a big difference in their success in getting them to whitelist a site. Making sure the language was right was the biggest issue for The Atlantic for the past several months. A lot of people didn’t realize they had multiple ad blockers installed or didn’t understand how to whitelist the site, Lau said.
This morning, The Atlantic launched a project called the Life Timeline. It’s an ambitious attempt to sort, contextualize, and personalize more than a century of journalism. By entering her own birth date, a reader can see her lifetime through the lens of The Atlantic’s historical coverage. It’s quick. It’s surprising. It might teach that reader something about her place in the world.
What that reader may not realize, however, is that the Life Timeline isn’t merely a new way for her to discover stories — it’s also the result of a Silicon Valley innovation process only recently imported to our east coast headquarters; a process that’s revolutionizing the way we think about creating new products and shoring up our creative process throughout the company.
The process is called a design sprint, originally developed by Jake Knapp, with John Zeratsky & Braden Kowitz of GV, the venture capital arm of Google’s parent company. Here’s how they describe it:
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at GV, it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process that any team can use.
The sprint has proven to be a powerful catalyst for concept development here at The Atlantic. More than a year ago, the site’s deputy editor Matt Thompson conceived of a tool that found a story from The Atlantic’s archives pegged to the midpoint of a reader’s life. Everyone liked the idea, but nobody was quite sure what shape it should take, or what the best way to deliver it to the reader would be.
Then, along came the sprint.
By using the sprint methodology, we “fast-forwarded” through five days of rapid learning and concepting to develop a solid theory of what the tool would be and how it would work exactly. We made some mistakes along the way (keep reading!), but we also took an idea that had been gathering dust on the shelf and turned it into the tool we love and launched today.
Why did we need it?
The Atlantic has a 160-year history of big ideas and exploration of difficult questions. In many ways, innovative thinking is already a core part of our work every day. Yet, we consistently found ourselves running up against a wall when it came to giving outside-the-box thinking the kind of time it needed to really take flight. Throughout the media industry, companies find themselves pitting small, incredibly busy teams of brilliant people against huge goals, grand ambitions, and endless task lists. With these very limited resources, how is it possible to innovate on unknowns?
For The Atlantic, the sprint has been part of the solution to that problem. One of the greatest risks in developing ambitious new ideas is that it’s possible to sink months, even years of work into what seems like a good idea, flying blind the whole time to how it will be received in the market. A sprint allows you to move directly from idea to testing, cutting out the development and launch process in order to test a concept before it’s even begun. That makes all the difference. The ability to pre-flight an idea, to understand its value before assigning strategic priority to it, is radically powerful. Even a “failed” sprint, where all of your ideas and conclusions are proved wrong, is still a huge success — that’s months of work and thousands of dollars saved from a wild goose chase.
And, in the really great sprints, you find an amazing idea and gain invaluable insights into what makes it tick.
So how does it work?
(You can, of course, skip this part if you’re already familiar with the sprint process. Really, I won’t be offended. Move along to the next section, it’s a good one.)
The sprint works by gathering a small team of smart people in a room for a full week, from 10am–5pm, and asking them to follow a rigorous process for discovering, curating, and exploring ideas. And when I say “rigorous,” I mean that they specify the size of paper and, ideally, the color of sticky dots you use, when you take your lunch break, even what kind of snacks you should be providing. (Yes, snacks are mandatory.)
The process demands some breaks from intuition and business convention, but always justifies whatever it asks of its participants with case studies from successful companies like Slack, Savioke, and Blue Bottle Coffee — or, just as often often, cautionary tales from pseudonymic companies that strayed from the straight and narrow and failed because they didn’t live up to the sprint methodology.
The benefit of this specificity is twofold: first, it works. GV is a serious investment company, and every item on the checklist is there because it’s needed and it’s worked over hundreds of successful sprints. Second, the specificity ensures that the entire team (and their managers, who are releasing them for a full 40 hours per head) that the process is on the rails.
At its core, a sprint consists of the work week broken out as follows:
On Monday, you learn. You study the problem, set a goal, invite outside input, and agree on the landscape of the problem you’re tackling.
On Tuesday, you sketch. Rather than group-thinking your way to an outcome, you sketch solutions individually (and no, you don’t need artistic talent) and then, counterintuitively, you don’t show those sketches to each other.
On Wednesday, you decide. You evaluate the sketches and decide on a direction to pursue for the remainder of the sprint.
On Thursday, you prototype. You rapidly create not an actual product, but a facsimile thereof that’s good enough to elicit an honest reaction from a potential customer.
On Friday, you test. You bring in people who are either in your customer set or as close as you can reasonably get, show them the prototype, and learn from their feedback.
Each day has a checklist of steps that break down those ambitious results into reasonable actions. If you’re interested, I highly recommend picking up a copy of the sprint book — even if you’re not implementing the process formally, it has great insights into what makes the creative process tick… and how to reinvent it.
Here’s what we learned
So we sprinted. We’ve done it several times now, with increasing success. In fact, if you’re reading this during business hours on the week it was published, I am presently in the middle of running a sprint at this very moment. But I said I’d tell you the mistakes we made, and I’m true to my word. Here’s what not to do when you try your own sprint.
Don’t hack it lightly. Our first sprint was… well, to be honest, it was kind of a mess. We didn’t plan it far enough in advance, so we only had people for about half the week. We didn’t have conference rooms booked, so we moved from place to place like vagabonds. We ignored the entire third act of the process and put together a pitch deck instead of a testable prototype, which led to all kinds of false assumptions and downstream woe. If you’re going to attempt a sprint, I highly recommend following the process as closely as possible. It may take work to get that kind of buy-in from busy stakeholders, but changing the formula is kind of like changing a recipe for baking on the fly. If you’re an expert, it could be okay — but spinning the temperature dial on the oven rarely yields good results.
Get the right participants. The method outlines exactly who should be in your sprint, with archetypes like “The Decider,” “The Troublemaker,” and “The Voice of the Customer.” You’ll want to take these recommendations seriously — especially when it comes to the Decider. It’s essential to go as high up the food chain as possible when running a sprint. The Decider is a key player in the process. She’ll be the one to ratify the goal, to decide on the concept to prototype, and — ultimately — to defend the decisions you made to the leadership of the company. In a perfect world, your Decider should be the person who actually makes the decisions, day to day, about the problem you’re trying to solve in the sprint.
Don’t hand-wave the hand-off. As much as I am a deep believer in the efficacy and usefulness of this process, it’s easy to make a single, crucial mistake — bad followup. A sprint is a learning tool, a way of breaking out of stale innovation processes to see what could happen in the future, to understand your customer better. However, a sprint does not and cannot replace your time-tested product process. A sprint will educate you, but it will not magically build a well-considered product. It’s geared for speed, not permanence. My recommendation is this: when you’re scheduling the sprint, schedule a Monday meeting for the week after the sprint. In that meeting, lay out what you’ve learned and determine how to use those learnings to inform your normal development cycle. Don’t assume that you can translate the incredibly hacked-together prototype from Thursday into the actual product. It won’t work. We tried. It was bad. Don’t do it. Use the sprint as a discovery engine — then use your incredibly effective and brilliant team of experts in their everyday roles to figure out where to go from there.
The future of Atlantic sprints
We’re excited about the design sprint process as an ongoing part of our innovation cycle here at The Atlantic. I wouldn’t be preparing to lead another one as I write this if we weren’t. As long as we have big ideas with only vague ideas about execution — or massive head-scratchers we’re not sure how to tackle — the sprint process is going to have a place.
But there’s more to it than that. These sprints aren’t just about five days in a well-provisioned room with lots of natural light and whiteboard marker fumes. They’re about learning to think differently. In isolation, any of the days suggested in the process offers a wealth of design thinking and creative strategy insights. The Monday process can be executed in isolation to identify a problem and a goal. Tuesday’s sketch methodology is helpful anytime you want to break apart your assumptions about what a product “has” to be. (Trust me. That Crazy 8’s exercise really works.) Wednesday has a lot to teach about how to find the best ideas in sketches without falling prey to the wiles of a charismatic pitchman with a half-baked idea. Thursday is all about making something that’s useful, even if it’s not pretty or perfect. And Friday is a masterclass in user testing that should be brought into every project that involves human beings interacting with a thing made by other human beings.
We’re just starting the process now of learning how to bake these lessons into the totality of our process. But whether we’re sprinting in whole or in part, we’re glad to have come across this methodology. It seems to be here to stay.
At the beginning of 2016, The Atlantic decided to embrace an industry best practice and transition from HTTP to HTTPS, or “secure.” The decision to devote time and resource to the effort required support and participation across our organization — from our writers who rely on embedding content from a variety of sources, to our advertising operations team that trafficks ad tags, to our developers. And while the decision to move to secure was relatively easy, the process to get there has been a more arduous journey.
What is HTTPS and Why Go Secure?
In 2014, The New York Times called for all sites to transition to HTTPS by the end of 2015. Among the 9 justifications for the move were “Authenticity of News Delivery”, “Privacy” and “Security”.
In a nutshell, HTTPS means that data will be encrypted between our servers and your browser thus reducing opportunities for spying or nefarious interference while you’re reading our site. A user knows a site is secure when they see the “lock” symbol by the URL in a standard browser.
In concept, anything we can do to verify the authenticity and integrity of our site is a no brainer. However, at the end of 2015, Poynter reported that the progress of publishers to embrace HTTPS was slow. Most organizations, including the New York Times, had failed to make the transition.
Our Journey Began
We began our process to transition to HTTPS in April by porting over images and individual elements, so that when it came time for articles to transition to HTTPS, there would be no mixed content on our pages. One of our developers scanned our database to find any of these elements that might break the site post-transition.
Next, we devoted a beta server to testing and addressed third party scripts on the pages, reaching out to third party vendors for HTTPS versions of scripts.
One concern for the transition was that our journalists would inadvertently include insecure images, interactives or other elements in our content management system (CMS). Even though these elements would show up blank in preview, we wanted to ensure errors wouldn’t persist in our backend. To address this, we created a warning that would notify editors on save that their story contained insecure elements.
A Challenge: Insecure Ads
Next, we worked with our ad ops and planning team to change our ad specifications and require HTTPS compatibility from our direct advertisers. We then made a list of our programmatic vendors and began requesting updated tags or code for HTTPS compatibility.
Once we had our tags updated and our QA process in place, we began monitoring the beta site. The most common issue we ran into when testing the secure site were assets that had initially passed QA and later showed up with insecure elements. Often, this was the result of an advertiser changing the creative and inadvertently adding an insecure element, like a tracking tag, after the ad was live.
It was clear that we needed a better monitoring process, and in June we began trials with systems that could do just that. We determined that a key requirement for our new validation software would be to monitor ads on a continuous loop.
Going Live with HTTPS (gradually)
We’ve benefited throughout this process from the learnings of those who’ve gone before us. In particular, these product posts from The Washington Post and Wired were extremely helpful in identifying challenges and pitfalls. Both publishers described gradual transitions to ensure they were safeguarding against search traffic loss and unexpected errors. We knew, we’d want to follow a similar process so we could monitor errors and impact closely.
Once we were comfortable with what we saw in the beta test environment, our first step was to turn off the redirect on visitors that typed in “HTTPS” before “theatlantic.com.” With less than 1% of daily traffic hitting the secure site, we were able to safely monitor for errors. Over a period of 3–4 weeks, we identified one error in a third party script and a handful of third party ad creatives that were not secure.
This week, we will be taking a bigger step as we transition our homepage to secure. This will take us from <1% secure to roughly 20% of the traffic being secure. We plan to monitor that change for 1–2 weeks. If all goes well, we’ll move onto making newly published content secure and finally, to redirecting the archive. In total, we are aiming to complete the transition to 100% secure by the end of 2016.
With a little luck, we’ll be ringing in 2017 with a fully secure site. And that’s something to toast to! 🍻
Many thanks to Delaney Chambers for her contributions to this project and this post.