Episode Transcript

Ethan:

Hi, this is a Responsive Web Design podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week we are incredibly excited to speak with two wonderful people from Quartz, namely Zach Seward and Daniel Lee.

Karen:

But before we get started, let me say a few words about our sponsor, Campaign Monitor. If you’re like most people, you open your email on your mobile device. If you know anything about responsive design, you know that making emails look great on all of the different devices and screen sizes that people might want to use, is really hard. Fortunately, there’s Campaign Monitor. They have a great new email builder called Canvas, that lets you make responsive emails in a snap. There’s an easy to use, drag-and-drop email creator, and so everything just works! Your images are sized correctly, your typography is the right size. Now, you can even try out the Campaign Monitor Canvas without having a Campaign Monitor account. Just go to campaignmonitor.com/templates and try out their fantastic tool that enables you to create emails that work right, for everyone.

Ethan:

So guys, thanks so much for spending a little time with us. Why don’t you guys introduce yourselves and tell us a little bit about what you guys are working on recently. Zach, how about you start?

Zach:

I’m Zach Seward, I’m the product director and senior editor at Quartz, and I work on a variety of projects, most recently this big redesign, as well as some of our data visualization journalism in the news room.

Daniel:

Hi, I’m Daniel Lee, I’m the lead designer here, product designer. I mostly focus on the UI and UX of the site.

One of the main goals we had with the site was just not losing the simplicity of the site in general. One of our main goals was focusing on mobile first.

Ethan:

Like I said, thanks so much for taking some time with us, guys. One thing I’d love to hear about—I really enjoyed the first major iteration of qz.com, it was really beautiful. What really struck me about the new, latest responsive redesign was just how you guys managed to pare down what was already a pretty minimal experience. It still feels very warm and very open, but at the same time, it strikes me as this perfect example of this really mobile first design mindset. I’d be a little interested to hear about how mobile, in general, influenced the design, if at all.

Daniel:

One of the main goals we had with the site was just not losing the simplicity of the site in general. One of our main goals was focusing on mobile first. We had a bunch of features that we were really excited about when we were rolling it out. A couple of them were being able to tap to zoom on our charts. Right now, they’re unreadable; they’re kind of hard to see because they’re smaller, so we wanted to improve the experience. So the user can now tap into the chart and pinch to zoom. We tried to get to as close as an app-like experience as possible. With a lot of stuff like that, we wanted to carry it directly into desktop as well, so with images, you can also click on them to zoom them as well, if you want to really dive deeper into details.

We mostly did focus on mobile a lot, whether it was creating our own icon font to fix share icons, to utilizing the whole screen, basically, and having the nav bar disappear as you scroll down the page and reappear as you scroll up. I think that definitely reflected on the desktop a lot.

Zach:

In August, for the first time, the majority of our traffic came from readers on mobile devices, both phones and tablets, though the majority of that is phones. So two years ago when we were launching, we tried to be as cognizant as we could about a trend toward mobile. But two years later, there’s not really a question. That’s the majority of our audience. If we have to choose one platform to ignore, it would be desktop, frankly.

Part of the idea was just not to screw anything up, right? We had a design people liked and we wanted to see if we can pare that down even further, focus on it, make a few things even more beautiful than they were previously.

Karen:

Can you talk a little bit about how you planned and scoped this project? Having been through several other large-scale redesigns, what was different about the way that you planned out what had to get done or maybe how you estimated how long things would take or who would be involved in them? Did anything change?

Zach:

It probably didn’t feel this way to Daniel, but we had a little more breathing room than we did when Quartz launched and the whole site was developed over the course of eight weeks. This project, the development time was pretty constrained ultimately, but the genesis of it came maybe a good eight months prior to when it launched. One thing I think about sometimes is, like Daniel was saying, part of the idea was just not to screw anything up, right? We had a design people liked and we wanted to see if we can pare that down even further, focus on it, make a few things even more beautiful than they were previously. That was scary, but it also helped solve this question you’re asking. There was no need—we didn’t feel a pressure to redesign because we were unhappy with the previous design, so we weren’t probably going to move ahead with any of it until we got to something that seemed like an actual improvement, that it wasn’t just change for change’s sake.

Daniel:

I think we’re pretty smart about it as far as—users were very used to having this queue, which is the left side of our page, which acted as more of a navigational element as you scroll through the articles. So we initially ran some A/B testing on the site and found out that we wanted to utilize more of the full-screen space to tell stories and come out with a better way for authors to tell their stories. So we ended up writing some initial A/B testing on removing the queue and see if that was going to hurt our page views. It ended up not, so.

That’s a little different—but not crazy different—from how people interact or use this site on desktop computers. We worried about this more in the past, that there was a big difference, and frankly I don’t know that there really is one.

Ethan:

One thing that a lot of publishers and other organizations grapple with is, what constitutes a mobile user and a desktop user? That they’re sort of these two different camps and they both have dramatically different needs. Was that ever a conversation that came up, either during this responsive redesign or the first launch of the site?

Zach:

Yeah. It’s a question we ask a lot, and I’ve come around to thinking that the difference is not nearly as great as some people suggest. Mobile first, it’s sort of a buzzword at this point, and might simply mean making sure that the site works as well and looks as good on a small screen as it does on a large one. There are differences in behaviors. Obviously people who come to us on phones read slightly fewer stories per visit. A lot, a lot of that traffic is from within social apps like Facebook and Twitter, so they’re looking for one particular story that caught their eye, and then probably going back to their Facebook news feed for more content, and that’s a little different—but not crazy different—from how people interact or use this site on desktop computers. We worried about this more in the past, that there was a big difference, and frankly I don’t know that there really is one.

The one thing that has changed for us is we focused a lot more on tablet two years ago and I think the original design of Quartz kind of reflected almost the tablet-first orientation, and then it scaled down into mobile and up to desktop, and that certainly wasn’t the case this time around. I think Daniel would agree.

Daniel:

Mm-hmm.

One of the main problems today with responsive design is you’re almost formulating your grid around IAB ads, which are not responsive ads. It’s like a designer’s dream to basically design around this nice, full-width, responsive ad.

Karen:

What about for advertisers? One of the things that I still hear from publishers is that advertisers want to buy for particular device classes, or that they expect viewable impression guarantees across a range of sizes. How do you work with your advertisers? How did the business side influence this redesign?

Daniel:

We worked with them super closely. We have a really great marketing lab team, so we’re building all their ads here in-house for the most part. The challenge was that our ads were going to get a little larger, but Zach and I were really trying to push our team to scaled ads, full-width, full-bleed, and fully responsive, from desktop to mobile. It’s an intriguing format for advertisers to want to advertise on. It’s a really great way to design around, too, because one of the main problems today with responsive design is you’re almost formulating your grid around IAB ads, which are not responsive ads. It’s like a designer’s dream to basically design around this nice, full-width, responsive ad.

Ethan:

That’s great. I guess kind of related to that, I’d be interested to hear—as you started planning the redesign, just broadly speaking, how did you make decisions about what to prioritize on each page? As you’re planning out this grid, thinking mobile first, what would come first down the line?

Daniel:

I think it really just depended on just what page we were talking about. We had a list of goals and new experiences that we wanted to add to the site, so I think those were all reflected in the design of things. We did a lot of research, user studies around the web. We don’t really have a dedicated UX team in-house, so we were doing a lot of our research ourselves, whether it was just looking up on Stack Exchange or people’s blogs and trying to use that information as best as we could for placements at our page. So we look into things like list views versus grid views for scannability of content, typography reading lists, optimal character count for line lengths, stuff like that. Also, best placements for shared tools on mobile versus desktop, where you should place them. So I think a lot of the research that went into it reflected on where we’re going with this stuff.

People talk about mobile first as purely a design question, and obviously there are a lot of ways in which it is, but we also think of it as an editorial question as well.

Karen:

Can you talk about how your editorial goals might have changed during the course of this redesign? And I ask because some publishers that I talk to, the substance of the editorial doesn’t change very much, but in other times doing a redesign is actually an opportunity to rethink what it is that you’re publishing, or the types of stories or the types of templates that you create. How did you think about that problem?

Zach:

Well, one very specific way in which our editorial approach changes changes more than I think we expected going in is, Quartz produces a ton of charts. More than half of our stories contain a chart. Our entire newsroom builds charts in our house style using a tool we built here called Chart Builder. And so we had a house style, and obviously in redesigning the site we had to redesign our data visualization style as well. That was done, the data viz team here in coordination with Daniel turned out better than I ever could have imagined. That changes the aesthetic look of our charts but also, I think, has already led to people using them even more, because they kind of shine even better on the new site. People are going to gravitate to the stuff that’s easy to use and makes their stories look better. So that was one very concrete thing that changed in the process.

The other thing I guess I’d say—I don’t know that it changed so much in this redesign, but that we try to be cognizant of at all times is—people talk about mobile first as purely a design question, and obviously there are a lot of ways in which it is, but we also think of it as an editorial question as well. Like, if you’re thinking about the reader on his or her phone, your style of writing should change. And so we try to avoid what one of our editors here calls “throat-clearing” in our writing. You should just kind of get to the point. We resist flowery ledes and try to say what we’re trying to say in the first sentence or two and then explain it in as concise a way as possible. And that’s—in my mind at least—a mobile-first approach to journalism. Anyway, so as the redesign was happening and more and more of our readers are coming to us on mobile, that just kind of became ever more important.

Daniel:

On the design side of things, Zach and I worked pretty closely on a editorial design style guide. We have a lot of new features such as pull quotes and full-width images and we wanted to educate them on the new templates and how they should be used and where they should be used, and where they shouldn’t be used and the problems that run alongside with that. We ended up creating a document for them with everything compiled into it.

We resist flowery ledes and try to say what we’re trying to say in the first sentence or two and then explain it in as concise a way as possible. And that’s—in my mind at least—a mobile-first approach to journalism.

Karen:

Can you say a little bit more about how that editorial process changed and—I’m particularly interested in what changes you had to make to your content management system or to your publishing system in order to integrate these new designs, integrate some of these new content objects, and train everybody or get them up to speed on what they had to do differently.

Zach:

Our CMS is WordPress and we’ve generally been really happy with its flexibility from the get-go. We made some subtle changes, in respect to the new features, in particular, types of images that we were adding in the redesign. Essentially just trying to make it a little more user friendly, in this case, with the user being our reporting staff. So we named all of the images, t-shirt sizes, from small up to extra-large. Which, you know, is a small thing, but compared to whatever the standard WordPress definition of images are, which are really user unfriendly, I think. It helps just make things simpler but also explain what we’re trying to do with each of these image sizes, what the intent of introducing them in the first place was, and also just to simplify things. You know, even if on the back-end it may be more complicated, the more we can simplify it down into just four different image sizes to the reporters, that’s hugely beneficial to them, just focus on the simplicity of that.

Ethan:

You mentioned tooling a little bit earlier and a Chart Builder for one. I’d be curious, as you guys have been doing more multi-device, more responsive work, have the applications and tools your designers use internally, has that changed much? I’d just be curious to hear a little bit more about that.

Daniel:

We’ve been using some new tools lately. One of them we use is called Flinto for mobile prototyping. And it basically can pull in flat designs easily from Photoshop or Sketch and create hot zones on them. And basically anybody that has the app, you can send it to them and it’ll create animations and everything. So, it’s really great, quick prototyping tool that we’ve started using. Another thing that I use a lot is an app called LiveView, which basically mirrors whatever you have on desktop onto your phone, which is super helpful to see font sizes and stuff like that. Positioning, tap zones, making sure the buttons are big enough to tap on. That’s another great app that I would recommend. And then the third thing that I’ve started to use is called Sketch app. So it’s a vector based app. It’s fantastic. I’m getting out of Photoshop completely and I’m pretty much hooked on this. So, you can basically just set all your headings, H1s, H2s, for a project or remember them. Remember all your colors. When you hand it off to the developers, they can go into the app, right click on the element, such as a button, and it’ll automatically copy the CSS and they can just paste it directly into the browser. So I think it’s definitely been something we’re excited about using for future projects going down the line.

And I think one more thing was Slack, we’ve been using a lot for chatting, but slowly and slowly it’s replacing our email and our products, helping our product team out. I think Zach mentioned earlier the charts redesign went by really smoothly and I think that’s an example of how Slack has really helped us. Because we were sending each other back and forth different ways we can present these charts, different colors, different palettes, stuff like that. So I think that’s why it went by so smoothly.

Karen:

I love Slack. I couldn’t live without it.

Zach:

[laughs] It’s incredible how quickly it seems to have caught on in so many organizations, ours included. And a big part of that, talking about mobile orientation, is that it has such great mobile apps too. It just fits better into most of our staff’s lives, especially outside of the office.

One thing that was really effective closer to launch, once the broad outlines of the redesign were set but there were still lots of details to be determined, was just keeping up a live staging environment of the redesign in progress.

Karen:

So that kind of leads me to ask, how did you get the rest of the organization involved in reviews and feedback? Did you use Slack? Did you print out PDFs? Did you have a prototype that you took around on your phone? How did you ensure that the business side and the other stakeholders within the organization had a chance to review and comment?

Zach:

I think it depended on what stage of the project we were at. We definitely did the big meeting, everyone sits down and we review all the new designs over two hours. They’re not the best kinds of meetings, but useful for everyone being on the same page. But one thing that was really effective closer to launch, once the broad outlines of the redesign were set but there were still lots of details to be determined, was just keeping up a live staging environment of the redesign in progress. We’re a small enough team here that everyone can trust, you know, this is a work in progress, don’t freak out when things aren’t working the way you expect them too. But frankly, just being able to use the working prototype of the site itself generated—at least from my view—the best kind of feedback, the best bug reports, and so on. I kind of wish… we probably should just do that as soon as possible from the get-go for all future projects, because it’s the easiest thing in the world. When people want to be kept in the loop you just say, go to the site.

When we launched two years ago performance was “meh,” I think everyone would agree. So improving the performance has really been a two-year-long project.

Ethan:

One thing I’d be curious to hear about is, not only is qz.com responsive, but it’s also pretty darn fast. Some of that might be the aesthetic but I’d be interested to hear, was performance a consideration when you guys were designing this, when you were planning the new site? “No” is an acceptable answer. [laughs]

Zach:

It was. Daniel could tell you, probably could list some features that were dropped in consideration of performance, I think.

Daniel:

Yeah, I think I had some ambitious goals that were dropped early on. We were experimenting around with using blurs and stuff like that, as much as the product engineer lead wanted to get rid of, that was the one part of the app I really wanted to hold onto, but he was telling us about how bad the performance was doing with that stuff. It was a give and take with a lot of that stuff.

Ethan:

Sure.

Zach:

In general, when we launched two years ago performance was “meh,” I think everyone would agree. So improving—and that’s probably because we developed in such a tight time frame—improving the performance has really been a two-year-long project. The redesign goal was not to degrade the performance in any way, but really that–and I think that work kind of continues too, post-redesign. In the refactoring of the code, that could be smoother, even still.

I think the real signs are probably much longer term, in terms of how does it change people’s behaviors on the site. So much of course is traffic sharing and social media, is it designed well to make that easy and encourage that behavior.

Karen:

And so finally, how do you measure the success of a redesign like this? How do you compare the new version to the old version and tell if it’s working or not?

Zach:

People are still coming to the site, thankfully, so that’s good. We had a few different goals depending on different parts of the redesign. We introduced a homepage for the first time so we’re looking there at measures of loyalty, are people who come to the homepage, which was designed as sort of a news briefing, are they returning to it in the way you would hope it would for a continually updated news briefing. Whereas for story pages, which get the bulk of our traffic, and usually through the side door, referrals from social media largely, there are different kind of metrics to gauge that. One is just, did we not screw anything up.

Like Daniel was talking earlier about pages viewed per visit when we made some major changes to the look-and-feel of the story page, is that going to cause people to view fewer stories each time? The answer so far is no, and that’s a sign of success, and then I think the real signs are probably much longer term, in terms of how does it change people’s behaviors on the site. So much of course is traffic sharing and social media, is it designed well to make that easy and encourage that behavior and so on and so forth.

Ethan:

Well I gotta say, thank you so much Zach and Daniel for taking a little time to chat with us. This has been really great and I can’t wait to see what happens with qz.com next.

Daniel:

Thanks guys.

Zach:

Sure, thanks a lot.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

Ethan:

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’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

Karen:

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.

Ethan:

Thanks again to our sponsor, Campaign Monitor, and we’ll be back next week.