Episode Transcript

Ethan:

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

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, we are quite literally beside ourselves to be here speaking with Ryan Mannion from OZY.com. Ryan, thanks so much for joining us.

Ryan:

Hey guys, great to be here. I appreciate it.

Ethan:

So Ryan, why don’t you introduce yourself, tell us a little bit about OZY, and tell us a little bit about how responsive design plays into it.

Ryan:

Sure. So, I joined OZY… I guess it’s been about ten months now. I moved my family from the east coast in Maryland all the way out to the Bay Area. Prior to joining OZY, I was at Politico for about seven and a half years and was one of the original founders there; a technical cofounder. I built a team of me all the way up to about forty when I left. So, I left a lot of good friends there and definitely colleagues who I tap on the shoulder from time to time for some advice as well.

OZY is a site that launched a little over twenty months ago, we’ll have our two-year anniversary in September of this year. It was cofounded by Carlos Watson and Samir Rao. Carlos is an ex-CNN anchor, also had his own show on MSNBC, and then had a few other startups, one including an education startup that he eventually sold to Kaplan about two years ago. We’re really thankful to have a host of great investors, including Laurene Powell Jobs, Axel Springer, Dan Rosensweig, Larry Sonsini, Louise Rogers, and others. So, we’ve been really blessed there, they’ve been extremely helpful in opening up doors for us, and so that’s been great.

OZY in general is a news and information site which takes about twenty to thirty stories a day. First, we’ll start you off with ten to twenty, which we call our presidential daily brief, and they’re news summaries where we curate from all over the web; we’ll catch you up, we’ll get you up to speed, we’ll tell you about all the news that you need to know for the day. And then we take the next eight stories and vault you ahead. So, we tell you about new people, new places, new things that you’ve never heard about the past. So, that’s it in a nutshell.

Basically from the get-go, both me and other advisers were urging them to go responsive.

Ethan:

That sounds fantastic. And frankly, as we mentioned to you earlier, it’s a beautiful piece of responsive work so it’s really exciting to hear a bit more about it today. As you guys are coming up on your two-year anniversary, I’d like to hear a little bit more about the origin story, at least of the responsive design specifically. How did you convince your stakeholders and executives internally that a responsive design was the right approach? And when you were having that conversation, were there any concerns or questions about responsive design as a methodology?

Ryan:

I was lucky enough to advise OZY before it started, I was an advisor for about eighteen months before joining, and it was never really a conversation that needed convincing. Basically from the get-go, both me and other advisers were urging them to go responsive. To be honest with you, working in other news organizations where you have tens of thousands of stories, or some of them have hundreds of thousands of stories, plus a lot of legacy code or technical debt, coming in from literally on the ground level and being able to just start from scratch I think was a huge advantage for us; basically, starting from that blank slate and building up from there. So in terms of trying to convince people, there really wasn’t any convincing. I think it came down to, from a workflow standpoint, making sure that that’s all ironed out—that was a few of the obstacles that we came up against.

In the past, however, trying to communicate what responsive is, why it’s important, how it saves money—that’s been difficult, especially for some news organizations that want to be controlled down to the pixel.

But yeah, it’s been great. It allowed us to basically make the design as beautiful as possible. We care deeply about elite design when it comes to presenting our news to our readers and to our watchers. So, that was basically our first principle—make sure it looks beautiful, make sure that the content is displayed in a way that the readers want to see it and they want to use it. But from an overall perspective, it was pretty easy for me.

In the past, however, trying to communicate what responsive is, why it’s important, how it saves money—that’s been difficult, especially for some news organizations that want to be controlled down to the pixel for every single form factor. So, I think that’s been challenging in the past. But at OZY, it was actually pretty simple.

There’s a tendency to want to answer this as, “Yes, we customize the experience for each platform and customize content for each platform.” But to be honest, the answer is no, we don’t.

Karen:

Ethan and I have talked to some publishers that seem to think that mobile users and desktop users want different things or they cite data that shows that people use different devices at different times of day, and we’ve talked to other publishers—we talked to the BBC a couple weeks ago—that basically said, “No, we believe that users basically just want the same things on every device and you can’t really guess what somebody’s going to want based on the type of device that they have in their hand.” How do you talk about that at OZY? Do you think there’s a difference between what mobile users and desktop users need?

Ryan:

That’s a good question. We do talk about that a lot, and I think there’s a tendency to want to answer this as, “Yes, we customize the experience for each platform and customize content for each platform.” But to be honest, the answer is no, we don’t. A couple of things go into that. One is there’s definitely the argument that people want to read more news nuggets or Twitter-style content on mobile or tablet devices, but I’ve been turned off by places that offer inferior experiences on mobile. So when I go to a mobile site, I want to read the entire article. I don’t want something that’s either a dumbed-down experience or something that’s, again, inferior to what I can get on a desktop.

But from our perspective, it also comes down to us being a lean staff. We don’t have hundreds of people that can churn out mobile versions of stories. So, I think that’s going into it a little bit. The other thing that we keep in mind is basically looking at bounce rates, looking at scroll data; we make sure that we’re producing content that actually gets read, and so we take that into account when we’re producing the content that makes it out into the web and to our devices.

We want to make sure that the content is available on all sizes.

Ethan:

One thing I’d like to hear a little bit more about is how do you actually make decisions about how to prioritize information on different sizes of the design? You mentioned beautiful presentation of content as being very important to OZY, and I’ve got to tell you, there are definitely some viewports or breakpoints on some responsive designs where they just feel like the awkward haircut. I have to say, the design just feels “at home” on pretty much small or big screens. How do you actually decide how to prioritize information and figure out what’s the most important piece of content across different layouts?

Ryan:

: I think that’s a good question and it’s something that I don’t want to say we struggle with but we’ve, again, thought deeply about it. We want to make sure that the content is available on all sizes. But a couple of things that we’ve done is basically if you look at our homepage, at the bottom we have “most read”: at the desktop size, we show you four elements; at a mobile size, we cut it down to two. Same thing with our staff at the bottom. If you look at it from the perspective of our story page, we’ll cut down some of the elements at the bottom just to make sure that we’re loading quickly and that we’re not overwhelming people with content that make the experience as good as it could be. So if you go to our story page on the mobile site, we have infinite scroll, and so it’ll just scroll you into the next story very naturally. But on the desktop, we offer you four choices—so, you can either click to a new story or you can continue to scroll to a new story.

To get back to the question that you asked: in terms of prioritizing content, we have sort of a natural flow to where if you look at our desktop version of our homepage, we have our top stories and then we go into our video and into our most read, and we basically fold things under as they happen, both from left to right and also as you scroll down vertically.

When we’re designing the site, we need to make sure that we establish a character count for headlines, for teasers, not so much for story content, but also we look at the photo sizes that we need to crop.

Karen:

Talk to me a little bit more about the editorial direction. How did defining the core content types, the editorial presentation—how did that fit in with your responsive process?

Ryan:

I think a couple of things. One, since we’ve always been natively responsive, it’s never felt out of place. But second, when we’re designing the site, we need to make sure that we establish a character count for headlines, for teasers, not so much for story content, but also we look at the photo sizes that we need to crop to ensure that, again, they look great on all devices. So, I think those are probably the two areas that we’ve spent most of the editorial tweaking around.

We’ll definitely do the majority of the design work in PSDs. Then when it gets down to the nitty gritty of implementing and doing different breakpoints, we try to do it within the browser.

Ethan:

Ryan, I’d love to hear a little bit more, as you’ve been building this cross device team internally at OZY, have you noticed that the team works together and collaborates differently than it might have in other organizations that you’ve worked with? Are you hiring for different roles for designers who need to be comfortable thinking more fluidly? Tell me a little bit more about how your team works.

Ryan:

Sure. If you remember back in the “olden days,” you basically had designers that would work in their own bubble and then they’d sort of have it land on the developer’s desk and say, “Here you go!” And then what’s the typical response from a developer? “Well, number one, what you’ve designed is completely impossible, and then number two, even if it was possible, the ability to actually maintain it is another whole thing.”

So again, this is probably not revolutionary but it’s sort of a tried and true process that we use: we’ll definitely do the majority of the design work in PSDs or in Photoshop just to make sure that we set the design direction and that we can get general approvals moving forward. Then when it gets down to the nitty gritty of implementing and doing different breakpoints, we try to do it within the browser. And so from that standpoint, you’ll have your designers that are working directly with front-end developers who are working with the back-end developers to ensure that every step of the process—they’ve bought in and they understand it. It’s a super collaborative way to keep people not only engaged but it prevents people from, a week or three weeks before launch, saying, No, this isn’t going to work because of X.” I think a lot of software projects in the past have failed because it didn’t have that collaborative process and it didn’t really focus on keeping people engaged and bought in. So, thats’ been really effective.

We design from a mobile-first standpoint. That’s sort of a term that’s been beaten to death, but if you know you can deliver on mobile, you’re just going to have it progressively get better and better as the browser size increases.

The other thing that I would say is that we design from a mobile-first standpoint. Again, that’s sort of a term that’s been beaten to death, but it is important to think of it from a standpoint of if you know you can deliver this experience on mobile, you’re just going to have it progressively get better and better as the browser size increases and the functionality of the different devices increases. So, that’s been a big thing.

One thing I will say is while mobile trending, what, fifty to sixty percent depending on what the site actually is, there’s still a lot of attention paid to the desktop. It’s still the flagship or the mothership of, “We need to make sure our design looks fantastic in this.” I think a lot of that is due to most of the stakeholders just viewing the site on a day-to-day basis at their desk while at work. So, I think there’s a lot that goes into that. But we try to break through that and continue to develop mobile-first or design mobile-first and then, in the end, we come up with designs that hopefully please everybody that comes to our site.

What we do is we take feedback from a lot of people and we actively pursue it. We don’t have people say, “Oh, I wish I could’ve weighed in on this.”

Ethan:

That sounds like a great way to structure the projects. I’d be interested to hear a little bit more of how the team talks about the design internally and maybe the tools and deliverables they’re using to do that. Do you find that the team starts a lot of design reviews in Photoshop documents and then moves into prototypes, or are they jumping right into prototyping? Or is it more analog and you guys are going paper and pencil?

Ryan:

We’ve done basically everything that you’ve talked about. We’ve done very rudimentary on pencil and paper just to start off the initial conversations. But we try to include everybody; include all of the major stakeholders and major participants in the project. A lot of people, a lot of companies will go the opposite way—they’ll keep it very small and then they’ll sort of branch out very slowly and also keep that pretty contained. But we like to involve a lot of people, and a lot of people could also mean a lot of “cooks in the kitchen.”

From our perspective, what we do is we take feedback from a lot of people and we actively pursue it. We don’t have people say, “Oh, I wish I could’ve weighed in on this,” and then we get the feedback. We actually pursue people’s feedback. That doesn’t mean that we want to end up with a Frankenstein-type design. We basically take their feedback, we review it, we’re really looking for those two or three super ideas that we hadn’t thought of or that people very close to the project didn’t think of. So, I think that’s one way that we approach.

There’s definitely that iterative collaborative approach, where if you did it in Photoshop it could take you weeks, if you did it in the browser it’s a matter of hours or days.

And then we’ll take it from, again, if we started it with pencil and paper, we’ll take it from that and pull it into Photoshop; we’ll go through and we’ll do some preliminary designs and start to set a structure. Actually, one step that I missed is wireframing. We do wireframing just to say that, and then from the wireframing standpoint we pull it into Photoshop, and then we really try to set the design direction for which way we’re going to go. We’ll do high fidelity designs from the start, we’ll do it from a couple of different renditions from mobile to tablet and then up to desktop size. Once we get down to the tweaking—not only tweaking, but the maintenance and additions to the designs after we’ve launched—we’ll continue to do that active prototyping where it’s much faster. Our designers will sit with our front-end developers and they’ll actually sit there for hours and just design, try things out, tweak the font size, adjust buttons, things along those lines that just make the overall experience a good one. But there’s definitely that iterative collaborative approach, where if you did it in Photoshop it could take you weeks, if you did it in the browser it’s a matter of hours or days to where you get to the point where you need to be.

PDFs—that’s definitely not the way we go. We’ll basically take browser tabs—we’ll open up a load of browser tabs that shows the differences between all of the different renditions.

Karen:

Let me follow up on that and ask if working in that way has changed the way that you communicate with your executive and stakeholders and with the broader organization outside of the design and development team. Ethan and I have talked to some organizations where the designers and developers are super onboard with getting things into the browser and iterating in that way, but that other people in the organization are really accustomed to getting a deck of PDFs to handwrite on, and so having a prototype makes it more challenging to communicate with other people in the organization. Have you found that? Or how did you handle that?

Ryan:

That’s a good question. I think my answer to that question would be different in previous positions, but at OZY we’re all very close-knit, we meet all the time; our CEO is extremely engaged in the product, so we’re lucky to just have him available and engaged and to put so much time and effort into it. So, I don’t think that PDFs—that’s definitely not the way we go. We don’t take it to where the designers will sit there and code in front of our CEO or other executives, but we’ll basically take browser tabs—we’ll open up a load of browser tabs that shows the differences between all of the different renditions that we did, and then we’ll just go from there. We’ll put them up on the big screen, people will take their notes and at the end we’ll collect the notes and then decide what part of the feedback that we’re actually going to take and use and then make the next iteration. Ultimately, it comes down to my decision and also our CEO’s decision on which direction we end up actually going.

A lot of the changes that we’re considering making start out in the A/B testing realm. One of the things we’re trying to do is basically design, build, and learn.

Karen:

So as you have launched this, have you made changes to the design, or to the content, or to any aspect of the site since it launched? And how did you figure out that you needed to make changes, if you made any?

Ryan:

I would say a lot of the changes that we’re considering making start out in the A/B testing realm. One of the things we’re trying to do is basically design, build, and learn. So, we create those cycles to where we’re testing things without a lot of front-end development and we use Target from Adobe or other tools that can help us learn from what our users are doing. That’s been our major focus. But I’d still say it’s definitely in its infancy; we’re still testing that out, we’re still trying to learn exactly what the data says. And then to follow up on the data: once we see what the data says, we’ll actually have conversations with a handful of users to make sure that that data actually corresponds or relates to what they’re telling us personally. So, I think that’s one big thing.

In terms of some of the additional design changes that we’re going to make, we’ll be doing things around localization but also design enhancements based on the time of day.

In terms of some of the additional design changes that we’re going to make in probably the next four to six weeks, we’re going to make additional changes to our presidential daily brief, which is basically our news summaries and it’s a daily email that comes out, it’s also available on our site. So, we’ll be doing things around that for both localization but also to make design enhancements based on the time of day. So for instance, if you’re in California and you happen to wake up at four o’clock in the morning, you may get a dark version of that presidential daily brief. But if it’s eight A.M. in California or eight A.M. in Germany, you’ll get the light version. So we try to, again, make these designs based off of how people use it, what time of day it is, and we’ll make that experience an overall good one.

Ethan:

Your mention of data made my ears perk up a little bit, Ryan. A lot of organizations, when faced with going responsive, there’s that whole massive number of devices that are out there in the marketplace. I’d love to hear a little bit about how OZY defines the word “support.” How do you actually determine which browsers, which devices are actually able to see your site? How do you manage that QA process?

Testing—it can become a nightmare, and quickly. Any small changes that you do to the site, if you don’t test it properly it will 100% come back to bite you.

Ryan:

I would say a couple of different ways. One, we try to set a baseline of what browsers we’ll actually support, and then from there we’ll use progressive enhancement. So for instance, IE8 and IE9, we’ll make sure that the site looks good and actually loads properly, but for us, infinite scroll was not an option for IE8 and IE9; it had major performance problems. So, we took that and basically said, “Okay, we’re not going to stop them from doing something else on our site,” so we still offer them four stories at the bottom of the page. But we also make that experience a good one based on the fact that we’re not forcing that infinite scroll, which is too heavy for IE8 or IE9 to actually perform well. So, we take that into account.

In terms of testing… I mean, this is one of the things that you guys know as well as anybody else—it can become a nightmare, and quickly. So, any small changes that you do to the site, if you don’t test it properly it will 100% come back to bite you. We’ve seen that over and over again. So, what we try to do is use a combination of actual devices and then we use a tool called BrowserStack, which allows us to emulate many of the browsers that we may not have access to natively.

If you have a slow-loading site, people will get fed up within the first ten to fifteen seconds and they may never come back.

Ethan:

That sounds great. The other part of that too is one thing we’ve been hearing from a lot of our guests and from other clients that we work with is this thing that’s really entering the responsive design discussion: performance. It’s wonderful to make this thing flexible, make it look good, but we also need to make it fast. Is that a design consideration at OZY? How does that actually shape the work that you guys do?

Ryan:

I would say the first thing we talked about when we did this redesign was we need to make it fast. Our baseline was we just don’t want to be as fast, to pick a company, the New York Times or the Washington Post, or whoever—we want to be faster than them. So, we basically take it from that standpoint; it’s extremely important to us. I think it comes into the overall user experience as a whole. If you have a slow-loading site, people will get fed up within the first ten to fifteen seconds and they may never come back. And so, part of what we’re going for is we want to make that experience a great one and we want to get people to come back to our site not only a couple times a week but a couple times a day. So obviously, yes, it’s very important.

We did a lot of work around perceived speed vs. actual download.

The other thing I’d say is we did a lot of work around perceived speed vs. actual download. So, if you do some of the Google speed tests, or things along that line, it will give you an overall score. But a lot of times it may not take into account what the site actually looks like while it’s loading. And so, we’ve spent a bunch of time basically loading our site so that it displays quickly and then making sure that the rest of the site that you may not see in your viewport loads after it, if that makes sense. So, we try to have as limited or no JavaScript blocking our page from loading. We work really hard on ensuring that not only is our site cached within the browser but is cached through our CDNs. Then we do DNS prefetching, which also helps us load the site fast. And then finally, I’d say we use sprites to improve overall load time and then ensure that you download that large image one time and then it’s used multiple times throughout your experience.

The biggest thing I look at when I’m evaluating performance is scroll data. We look at where people are scrolling down to, we look at the bounce rate or where people are bouncing off from the actual site.

Karen:

I’m really interested, given that you have been responsive from the start, how do you look at your analytics data, how do you measure the success of this responsive design? Are you looking at how well the site performs on smartphone, tablet, and desktop, even though the site isn’t really intended to work great on any one particular platform?

Ryan:

Yeah, we do, and we use a couple of different tools. One is Google Analytics, which is standard. We also have Adobe Analytics as a backup, and while they have some overlap, I think each one has their elements that you can use from each. But we also use Chartbeat to show us real time traffic.

But the biggest thing I look at when I’m evaluating performance is scroll data. We look at where people are scrolling down to, we look at the bounce rate or where people are bouncing off from the actual site, and then if we start to talk about video, we look at how much video people watch and then where they bounce off. So I think if those numbers are increasing, then I would call that success. If we see them decreasing, then we need to make changes as soon as possible, and look at where people are bouncing off and maybe offer them something to do in that particular spot or figure out why their interest level is declining at a certain spot on the page. So, I do think that’s one of the things.

One of the other things I would say is we don’t ever look at a design as being complete. We constantly want to change it, we constantly want to innovate, we want to make it better for our readers, and again, it goes back to having those conversations, it goes back to reading and analyzing the data that comes out of each site. So, I don’t know, I think from my perspective it’s sort of an ongoing process that we keep trying to make better, and better, and better.

We had a main site, we had a mobile site, we had about six mobile apps. From a maintenance standpoint, it just became something that was a complete nightmare.

Ethan:

Ryan, I’ve got to tell you, I’ve learned a lot in the last half hour. As we come to the end of our time, I’d love to hear if you have any advice for any other organization who might be listening who are just about to start thinking responsively. Anything you’ve learned in the last two years that you’d like to share with our listeners?

Ryan:

I would say be patient. I would say become an educator or a teacher. I mean, even though responsive has been out in the mainstream for four or five years, or even more, I do think that when you’re making a sales pitch to move to it, people have different perceptions on what it actually means. So, I think trying to use as many visuals as possible—and there’s many out there on the web that you can just pull up and show people.

Make sure that you test, again, not on just the emulators but also on the devices and make sure that you continue to test really well moving forward.

And then also prove the business case. Like, for instance in my last position, they’ve subsequently gone responsive for the main site a couple of months ago, but we had a main site, we had a mobile site, we had about six mobile apps. From a maintenance standpoint, it just became something that was a complete nightmare. You never had your systems matching up, because if you did, you basically did two to three releases a year because it was so much work to get all of them synched. So what I would say is use that as a business case to say, “Okay, if we update one codebase, it will update on all of these different devices, and that way, number one, you can save money, and number two, you make an overall experience that people are getting used to and they expect.”

So I guess education would be the biggest thing, having patience is the second thing, and then testing is probably the third and most important. Make sure that you test, again, not on just the emulators but also on the devices and make sure that you continue to test really well moving forward.

Karen:

Ryan, I’ve got to tell you, this is solid. I have long maintained that when you see a great responsive design, that underneath all of that is a really well-thought-out management process and a really solid approach to how you think about the work, and honestly this interview has borne that out handily. So, I want to thank you so much for taking time to talk to us and our listeners today. This has been fantastic.

Ryan:

I appreciate that. And if I can just say one more thing: we are actually looking for front-end developers, so I think you guys have a great audience for that and if there’s anybody that’s interested, they can send me an email directly at Ryan@OZY.com and we can go from there.

Ethan:

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

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 again for listening, and we’ll be back next week.