Hi, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.
And I’m your other host, Karen McGrane.
And this week, we are just crazy excited to speak with Betsy Ebersole and Libby Bawcombe from The Atlantic. Betsy, Libby, thank you so much for sitting down with us.
Glad to be here.
So, why don’t you guys introduce yourselves and tell us a little bit about what kind of responsive goodness you’ve been working on recently.
My name is Betsy Ebersole. I am the senior product director here at The Atlantic and I manage the day-to-day workings of our product and dev team. We work on TheAtlantic.com, CityLab.com, and TheWire.com, and I also work on with an outside partner for our app design and development. Most recently, we have done an overhaul of TheAtlantic.com to make it responsive.
And I am Libby Bawcombe. I’m the digital design director on the product team at The Atlantic, which means I am in charge of anything that we do that’s responsive, anything on the website, any design and layout for our mobile apps. I’ve been with The Atlantic for about a year and a half and the entirety of my career here has been working on responsive designs and slowly changing The Atlantic website over to be completely responsive.
Rather than convincing our stakeholders that we needed to go responsive, really what we did instead was look at and try to understand our audience and set goals for this project that made sense.
Wow, that’s fantastic, and I have to say, the end result looks beautiful. I’d love to hear a little bit about how that initiative started. How did you guys actually kick this process off of going responsive? What kind of conversations did you have to have with your stakeholders internally? And I’d be really interested to hear if there were any concerns or challenging discussions around responsive design as a methodology.
Fortunately, we didn’t have to convince our stakeholders to go responsive. For the last year, year and a half, all of the new development we’ve done on The Atlantic has been responsive. So, we’ve launched several new site sections: the photo section, the video section, and something for our live team that were all responsive. And so, rather than convincing our stakeholders that we needed to go responsive, really what we did instead was look at and try to understand our audience and set goals for this project that made sense.
We can see from our data that about half of our unique visitors come to our site on phones.
We looked at those goals in a couple of different ways. We started by looking at our traffic and our usage patterns, and then we talked about monetization, and then after that, we focused on technical performance because we knew that is increasingly important for SEO and social referrals. If we go through those in order, we can see from our data that about half of our unique visitors come to our site on phones.
With the growth in social networks, we’ve seen that our core audience actually might be made up of people who come in often from social.
So, we know that our audience is broken up into two groups: our core audience and our drive-by traffic. Historically, we’ve thought about our core audience as people who come in through our homepage and then find a headline that they want to click on, and our drive-by audience are folks that come in through a side door directly to an article page. With the growth in social networks, we’ve seen that our core audience actually might be made up of people who come in often from social. So, they’re repeat visitors, they love our content, they come often, but they don’t necessarily come in through our front door. We had to make sure that we were catering to the needs of these repeat audience members, whether they come in directly through the homepage or to a side door, as well as the folks that come in just because they saw a headline on Facebook, for instance, that they thought was interesting.
We see folks who are not only coming in on phones, but they’re actually looking at our site on their phone and the desktop, so we know that there’s a big overlap in our audience.
The next thing that we looked at with our traffic patterns was the fact that half of our unique visitors come in on phones. So, we see folks who are not only coming in on phones, but they’re actually looking at our site on their phone and the desktop, so we know that there’s a big overlap in our audience.
We’re at a bit of a crossroads in our industry because we’re seeing an increase in the requirements around ad viewability and the importance of moving ad units around on the page.
After traffic, we focused on monetization, and the big thing to focus on there is we’re at a bit of a crossroads in our industry because we’re seeing an increase in the requirements around ad viewability and the importance of moving ad units around on the page. But we also haven’t yet moved away from some advertisers asking about placements above the fold versus below the fold. So, it’s an industry that’s in flux and it made for some interesting requirements for our site redesign. So, our primary goal, first and foremost, is to make sure that we have an absolutely fantastic site for our readers, but we also need to make sure that we monetize that site, and viewability is a big part of how we do that today.
We took a very critical look at everything we have on our site, from third-party code on the site, to how we lazy load ads, to how we crop images to make sure that we are loading as quickly as possible.
Last but not least on the strategy side, we spent a lot of time looking at page speed optimization. So, we know it’s increasingly important for Google—they rolled out some changes recently to improve search rankings for sites that have quick load times. We’ve also heard from some social networks that that’s important to them as well. So, we took a very critical look at everything we have on our site, from third-party code on the site, to how we lazy load ads, to how we crop images to make sure that we are loading as quickly as possible. Looking across all of these buckets, responsive really wasn’t a difficult decision.
We know that our customers come across multiple platforms.We ran a survey recently where we saw that fifty-one percent of our monthly unique visitors visit via a desktop and a phone.
So, I will tell you guys, I worked on the relaunch of The Atlantic back in 2008, when Justin Smith came in and they did the huge rebranding of the publication. One of the things that was so interesting in working on that redesign was that it seemed like The Atlantic had a very strong sense that if they grew digital, that it would actually help with print—it would help with print advertising, it would help with print subscriptions—which, at the time, was sort of heresy. There was just the sense that all digital ever did was cannibalize, and if you gave any magazine content away on the internet, that just meant that you were going to drive your business model into the ground. I thought the The Atlantic was a fantastic case study in that that turned out not to be true and the growth of the digital platform has resulted in financial and business benefits across the board.
I would love to hear you talk about how you see mobile playing into that, because I think in the same way that organizations at the time struggled with the idea that lower value ads on the internet might cannibalize print revenue, now there’s this sense that perhaps lower value ads on mobile or viewability restrictions on mobile will cannibalize desktop revenue. Can you talk about how a responsive redesign fits into that broader question of mobile versus desktop?
I think the most important thing that we try to focus on is that these are our customers. So, someone who is coming to our website, maybe they’ll subscribe, and we try to put circ. offers in front of them, or maybe they’d want to attend an Atlantic event someday. We try to recognize that no matter how someone comes to our site and reads our articles—I hate to say the word “content”—but our articles, they’re not users, they’re customers. So, we know that our customers come across multiple platforms.
It’s not a question of cannibalization, it’s a question of the same person coming across multiple visits on multiple platforms.
We ran a survey recently where we saw that fifty-one percent of our monthly unique visitors visit via a desktop and a phone. So, it’s not a question of cannibalization, it’s a question of the same person coming across multiple visits on multiple platforms. It’s important for us to understand that while the engagement might be different between one platform and another, they are still coming across those multiple platforms. You see someone who comes in through Facebook, maybe doesn’t read as many articles on that visit, but perhaps they come back on subsequent visits because they continue to click on our headlines. So, it’s important to recognize that it’s all part of a larger strategy and you’re not taking away from desktop by building up a good experience on mobile.
Everyone used to say, “Oh, people don’t read long content on phones,” and our data shows that’s just not the case—people do read longform content across both platforms.
The other thing we’ve seen is everyone used to say, “Oh, people don’t read long content on phones,” and our data shows that’s just not the case—people do read long form content across both platforms. So, it’s important that we provide a good experience to do so.
Things that are really fun to do are to consume video and photos on the phone.
Something that I would like to add is we have these amazing video and photo sections online, and something that we really wanted to do with our responsive redesigns, as we’re doing this slowly over time, is to make sure that as people are consuming content on their phones, things that are really fun to do are to consume video and photos on the phone. And so, those were the first sections that we really wanted to refocus on, to say, “These are popular and people really like these things, and let’s make them as accessible as possible on their phones.” Even though they were a good desktop experience, we wanted to make sure that we brought that to people in a way that they could consume it where they were.
By having a developer in the process from the very beginning, we were able to make informed decisions.
I’d like to ask a little bit about scope. So, once you’ve actually identified a few key sections or pages to actually work on, how did you actually figure out how much time that was going to take? How did you actually get your arms around the actual scope of what you were going to be building?
I thought we had a really interesting and new approach for this project. We had a core working group, and it included not only Libby and me, but it had several members of our edit team, our digital director of analytics, as well as one of our developers, and I thought that was really a smart way to approach this project.
In the past, we’ve done design and then vetted with a developer. By having a developer in the process from the very beginning, we were able to make informed decisions about what was a very big lift—or sometimes things sounded like they were going to be a big lift and they weren’t. Having a developer really just streamlined that process, it helped in the brainstorm. And our developers love our site too, and they had really valuable insight to bring to those conversations.
We were able to very quickly pull data for how people use our site today. We were able to see how they were using our old site while we were doing the scoping conversations.
The other thing that we benefited from with that working group was having our digital analytics director join us. We were able to very quickly pull data for how people use our site today. We were able to see how they were using our old site while we were doing the scoping conversations. We were able to plan out A/B tests that we could run on the old site to inform those design and scope decisions. We also mapped out a long list of tasks that we wanted to run after the redesign went live, and, in fact, we’re executing that testing plan now.
So, the focus on data in that process was very strong. We didn’t want to just make guesses. We wanted to make sure that we were grounding our decisions in data as much as possible. And I think that working group was awesome. It was a very tight-knit group. We worked together multiple times during the week, and now the communication between the groups is very easy, it’s very organic, we’ve regrouped afterwards to make quick decisions, and it’s just been a really, really good experience for this project.
We wanted to arm ourselves and the marketing team with new ad product; we launched this custom ad size that’s responsive.
Let me ask specifically about ad sales, just because I know that that’s such an important issue for publishers as they’re wrestling with how do they improve viewability and how do they deal with ad placements in a responsive design. Just talk to me about how you handled that.
The big thing that we were focusing on was making sure that we’re meeting industry standards around viewability—these emerging industry standards. We always want to make sure that we’re providing a good experience for our readers, so that no ad decisions were ever at the expense of customer experience. We wanted to arm ourselves and the marketing team with new ad product; we launched this custom ad size that’s responsive. It’s the first time we’ve had responsive ads on our site and our marketing has worked on building custom ads to fill those units. We’ve also worked on updating our new promo placement and designs with this project. We just wanted to make sure that we’ve given them tools that they can go out and use to monetize the site on mobile as well as on desktop.
It was sort of this long process of redesigning these as we go, which is great for our readers because they could get this slow change over a long period of time.
Let’s talk a little bit about design process. You guys are maintaining existing desktop properties, some native app presences, and now some responsive sites. Has that been a challenge for the way you think about building digital designs?
Sure, I’d be happy to talk about this. So, with The Atlantic redesign, we did it in sections slowly over the period of probably a year or so, starting with some of our sections like video, our feature article template, our events section, things like that, and most recently with our homepage and our article page, but also we redid our photo section before that. So, it was sort of this long process of redesigning these as we go, which is great for our readers because they could get this slow change over a long period of time, as opposed to having this giant relaunch all at once and it’s so disorienting.
It’s very interesting how the design process has to look so far ahead when you’re doing a slow relaunch such as that.
But it’s very interesting how the design process has to look so far ahead when you’re doing a slow relaunch such as that. You have to be cognitive of “How is this going to work for us in the future, especially as web standards change?” and particularly as ad standards change, as we’re looking at viewability as the new metric for how ads are performing. So, that has been a big shift for us as we’ve been slowly doing these redesigns of the different sections—"Are ad placements okay? Do we need to move them for viewability? Do we need to have a new unit?“ So, that’s been interesting.
When we did CityLab about a year ago, we did CityLab all at once. [Laughs] So, that was a very different process. We did the whole site all at once. So, that in turn makes it easier for the aesthetic of all the different pieces and templates to work together. When you do an extended redesign over several months of the different sections, you have to make sure that the aesthetic is going to work with each other as you’re redesigning each section. That becomes a little bit of a challenge, especially as new tools become available, and new ways to use fonts, new code that can allow different things. So, it has its pros and cons, basically.
Our process has been sketching on paper with good ’ol sketchbook and sharpies, and then talking with the developers as we’re wireframing.
Since you mentioned tools, I’d love to follow up on that for a second because I’d love to hear what you guys are working with on a daily basis. Do you find that since the CityLab redesign and now that you’ve actually launched The Atlantic up again, are you still, more or less, using the same applications and tools to actually talk about design? Or do you find yourself still relying on mock-ups, or making more prototypes? Tell me a little bit about that.
Sure. So, the tools that we have been using for our redesigns have been more traditional tools. As doing the design work, I’ve been working and doing the wireframes and the mock-ups in Illustrator because I’m used to that pixel perfect control over things and I need to flesh out a lot of the design before I can bring it to a developer and say, “Hey, this is what I want to do.”
That process could have been greatly improved by prototyping early on with a developer. So, I think that’s something that we’re going to look at changing for future redesigns.
So, our process has been sketching on paper with good ’ol sketchbook and sharpies, and then talking with the developers as we’re wireframing, and talking with our working group and our stakeholders with the wireframes, and then moving into actual comps in Illustrator. That process could have been greatly improved by prototyping early on with a developer. So, I think that’s something that we’re going to look at changing for future redesigns, is getting into the browser early and doing a lot more work with development early on so we can see real fonts, real representations, real colors, real responsiveness.
That’s the big challenge with responsive design, is that you can’t use these traditional tools to get across how a responsive page behaves.
That’s the big challenge with responsive design, is that you can’t use these traditional tools to get across how a responsive page behaves. So, it’s not enough to have multiple art boards and Illustrator at different breakpoints to indicate “this is what it looks like here,” and “let’s just imagine what it does in between these breakpoints.” I think we’re going to have to change our process going forward to have something that’s more dynamic and interactive during the ideation phase.
The changes to the back-end were smaller, but what they did was they actually introduced additional templates.
Let me ask you about changes to the actual editorial, perhaps the actual structure or the types of editorial content that you’re publishing. So, some of the interviews we’ve done—like NPR, for example—said that they used a responsive redesign to really deeply reexamine what they were publishing, how things were structured, what types of content they had.
Other publishers, like Quartz, came back and said they didn’t make a lot of really substantial changes, but a responsive redesign was an opportunity for them to add in some smaller new content types. So, things like how they handled charts or other data presentation—they added new things like that into their publishing process.
What did you guys do? Did you change anything in your editorial?
We have, over the last couple of years, gone through a major rebuild of our content management system. It’s in-house now, it’s a system called Django. So, this redesign focused much more on what was visible to the reader. The changes to the back-end were smaller, but what they did was they actually introduced additional templates, and those templates, in turn, allow edit to have more options in how they tell stories.
So for our homepage editor, you’ll notice that there are lots of different module layouts on the homepage. She can pick and choose the one that’s appropriate for a particular story. When we have a magazine cover that’s going blockbuster, she can give it that full bleed, high impact experience when it’s at the top of the page. But also as it moves down the page, as it ages slightly, she can still leave it a high impact presence with a large image. It doesn’t get relegated to a tiny little headline at the bottom of the page.
That’s important for the homepage editor to be able to use modules that are appropriate, whether it’s to show the importance of one particular story or to connect stories.
I think that’s important for the homepage editor to be able to use modules that are appropriate, whether it’s to show the importance of one particular story or to connect stories. So, if you’ve got ongoing coverage of a nuclear deal with Iran or, god forbid, there’s a tragedy in the news cycle, we can do ongoing coverage and she can put it together and connect those stories. I think that’s important for her.
By getting rid of that right rail, we now have the ability to do full width images, full width graphs, full width videos embedded in the body of the story.
Likewise, individual story authors, we gave them a couple of different templates for the top of the page. The largest of the templates has a full bleed, beautiful image at the top. The smallest has a much smaller image for stories that don’t have good visuals, or strong visuals.
But the other thing we did is we got rid of our fixed right rail. We did a number of tests that showed that people weren’t really clicking on the stuff on the right rail, other than the most popular box, which we retained. But by getting rid of that right rail, we now have the ability to do full width images, full width graphs, full width videos embedded in the body of the story. And it’s all about giving the editors options and tools to tell the story in the way that they want to, and I think that’s pretty exciting.
On our mobile site we’re not going to have heads and decks. It’s just going to be heads, so they need to write the heads in a way that are self-contained and self-sufficient.
Yeah, I’d like to add to that, as well. We are in a culture of A/B testing here, and we A/B test a lot of stuff. And so, something that we have done as one of our A/B tests that sort of affects editorial content is we try to A/B test on our mobile site to see if our stories were performing better if they included headlines and descriptions, or if just headlines and thumbnails were sufficient. We found, through our A/B testing, that people weren’t reading the descriptions, that they performed better when we had just thumbnails and headlines.
And so, that’s something going forward for our editorial staff, that on our mobile site we’re not going to have heads and decks. It’s just going to be heads, so they need to write the heads in a way that are self-contained and self-sufficient without having to rely on the description that follows after them. That’s a big change editorially for them, but we know that’s what the readers prefer, and that tested better, and so that’s what we’ve done for our mobile site.
I get an email every morning that says how we’re performing on these various metrics. We are prepared to react if we see trends that are troubling or things that we didn’t expect.
Let me follow up on that since you mentioned testing and learning: Have there been any elements of the site’s design that you’ve reworked since it’s been released? And if so, I’d be curious to hear what the cause was.
I think it’s too soon to say on that. It’s been just two and a half weeks since we launched, and we are, at this point, waiting for the dust to settle. So, you’ve got your regular audience who comes and they see something’s new, and they’re going to click around and try to learn their way around the new site. So, we don’t want to react too soon to anything that we’re seeing in the data, and at this point there’s not a lot that’s a cause for concern.
We set out, before the redesign started, with a set of metrics we wanted to measure. We stated our goals, we defined the metrics we were going to measure to track those goals, we’ve worked with that director of analytics I’ve mentioned to put together a dashboard, I get an email every morning that says how we’re performing on these various metrics. We are prepared to react if we see trends that are troubling or things that we didn’t expect.
Likewise, we’re starting to run the first of the tests that we planned out. So, we have this new “most popular” box at the bottom of most article pages that we’re pretty excited about. Unlike a traditional “most popular” box that’s just a list of headlines, maybe there’s a thumbnail, we’ve got a much larger thumbnail and we actually have an excerpt of the story, and it’s a preview of the story, and we’re hoping that will perform well but we don’t want to just cross our fingers that it will. So, that test is running right now to compare that—the number of stories that we tease there. We’ll also do a couple of variations on the design to see what performs best in that module. And we’ve got a number of other tests queued up to make sure that we’ve made good decisions and smart decisions along the way.
We’re not just looking at traffic to see what’s successful. We’re looking at shares, we’re looking at referrals from social, we’re looking at viewability metrics and ad monetization.
Let me follow up on that and ask how do you measure the success of this responsive redesign, and is it different? Like, do you still look at your analytics by mobile, tablet, desktop, and make decisions based on platform?
Yes and no. So, we are looking at traffic across those different platforms just because previously we had a desktop site and a mobile site, so we need to look at the benchmarks and see how they’re performing. But we’re not just looking at traffic to see what’s successful. We’re looking at shares, we’re looking at referrals from social, we’re looking at viewability metrics and ad monetization, we’re looking at the number of circulation orders that have been placed since we launched.
Speed influences our SEO, it influences ad viewability, it influences how our readers perceive our site.
The other big one that we’re looking at is speed. Speed influences our SEO, it influences ad viewability, it influences how our readers perceive our site. So that’s another big one, where we’re going through and looking at where we can optimize queries to make things run faster. We’re looking at third-party code that’s on our site and plucking things off if we think they’re too slow. So, there’s a number of different things that we’re using to say whether or not we’ve been successful here.
We sometimes unfortunately hear about issues from our readers and that’s definitely not our intention.
I’d actually be interested to hear a little bit more about how you define support in your responsive design. We talk to a lot of organizations where their entire QA process has been changed once they don’t have a desktop site and a mobile site anymore—it’s just “the website.” How do you guys actually test this wonderful, flexible thing that you guys have built?
We don’t have a dedicated support team. I would love it if we could build that out, but for now we rely on our current usage data to inform which browsers we do support. I think, in listening to other episodes of this, this is a shared issue, where we sometimes unfortunately hear about issues from our readers and that’s definitely not our intention.
So, we’re doing our own testing. It’s a tricky thing. We’re a very, very small shop—we’re seven developers and four product managers, and so we divide up resources, we pull people off other projects before a major relaunch.
We did finally end support for IE8 with this redesign, which is pretty exciting. I’m sure developers all around the interwebs are excited to hear that, as well.
One of the things that we have planned this year as our team has grown late last year is to make sure that we have folks, on a regular basis, going through our virtual machines and various gadgets that we have within the team and making sure that we’re looking at our site proactively to make sure that we aren’t inadvertently breaking support for a certain browser. We did finally end support for IE8 with this redesign, which is pretty exciting. I’m sure developers all around the interwebs are excited to hear that, as well.
The biggest piece of advice I have for any major redesign is to allocate enough time upfront to go through your setting goals, deciding what you’re organizing principles are going to be.
So, this has been a really interesting look at your redesign process and what you’ve learned from it. You must have picked up some insights along the way that perhaps our audience would be interested in hearing about. I’d love to hear from both of you: Do you have any advice for other organizations, perhaps even other publishers, that are undertaking a large-scale responsive redesign?
The biggest piece of advice I have for any major redesign is to allocate enough time upfront to go through your setting goals, deciding what your organizing principles are going to be for the redesign, making sure you spend time looking at competitive sites for things that both inspire you and things that people don’t like and want to avoid.
When we set our original schedule, we thought that we were allocating a lot of time to that process and, in fact, we used every minute of it and then a little bit more. I think it’s really important, it makes the rest of the process to run very smoothly. So, if you know up front, “What’s the most important thing for various stakeholder groups?” and you’re very clear about what your requirements are, it just makes everything else run much more smoothly.
Really have a laser focus on your organizing principles of how you want to organize your content.
My advice for other responsive redesign projects is to really have a laser focus on your organizing principles of how you want to organize your content. We had these great working group meetings with our editorial and product teams working together, and also with our stakeholders, and we had a lot of design discussions and function discussions, and “How is this thing going to perform?”
But it all circled back to “What’s the best way to organize the content?” Not like specifically user-centered design discussions, but more about “How do we want to connect stories to each other? What is the best way to showcase stories? Do we want to have something that’s more dense that people can see more at a glance? Do we want to make this more of an exploration on the site so that we can highlight individual stories in a way that is unique and interesting?” We talked a lot in those meetings about how do we want to organize the content in a way that is there for people to find, and explore, and discover new content.
So, those design discussions, and those function discussions, and development discussions were very important, but sort of getting back to the bones of “How do we want to highlight the content and make it easy for people to find and read?” were really things that we circled back to a lot.
Well, thank you so much for taking the time to talk with us today. The Atlantic has long been one of my go-to examples or case studies of an organization that’s really thinking smart about how they make the transition from print to digital, and I think you’ve got a fantastic case study here of how you make the transition to responsive, so thank you.
You’re very welcome.
Great. It was awesome talking with you all, and I just want to acknowledge our wonderful editorial and product teams. They deserve all the tacos and we are so thankful for them, and just wanted to thank you guys for talking with us today.
Thanks to everyone for listening to this episode of a responsive web design podcast.
If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.
If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.
Thanks for listening, and we’ll be back next week.