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 impossibly giddy to finally speak with Ryan Shafer from MTV. Ryan, thanks so much for joining us.

Ryan:

Thanks for having me.

Ethan:

Why don’t you introduce yourself and tell us a little bit about what you’re working on?

Ryan:

I’m Ryan Shafer. I’ve actually just recently left MTV; I’m taking a year off to spend time with my family in Italy. But while I was at MTV, I was the vice president of design and user experience. I was really trying to figure out how to bring design to the forefront of the organization. When I started there, it was primarily graphic-based design and I really wanted to bring a more user-centered design process to the organization.

How do we make sure that whatever we craft and create for our audience just works, where we don’t have to have a panic attack running around trying to kick up something new to support that new device?

Ethan:

How did responsive design fit into that strategy? Obviously MTV.com has a beautiful responsive site and I’ve been seeing responsive play out in some of your other properties. How did those initial discussions around responsive design go? How did you convince your stakeholders and executives to go responsive? Were there any difficult discussions or concerns about responsive design as a methodology?

Ryan:

I think the starting point was education. There’s a lot of terms that get thrown out there and people don’t fully understand what each of them mean and how they’re actually used. What my boss was focused on fundamentally was “How do we take more control over our mobile future?” I started looking around, trying to figure out how we would go about doing that and the big question that came up in my mind was when Apple or Samsung or whomever releases a new product into the marketplace—a phone, a tablet, what have you—how do we make sure that whatever we craft and create for our audience just works, where we don’t have to have a panic attack running around trying to kick up something new to support that new device? Because we have limited resources and we have a lot of products on our plate.

What I decided to do was poke and prod the concept of responsive web design on areas that were safer—I basically didn’t want to break a multi-million dollar website.

Two big areas our organization was primarily concerned about was ad sales and the sponsorships that we do, particularly around the Video Music Awards or new show launches or whatever other content experiences that we create. In combination with that was content rights management. We’re not just a digital organization, we’re tied to a TV organization, and so we have a lot of negotiation that goes on between the Comcast and Time Warner Cables of the world, so content rights is a real challenging issue for us. What I decided to do was poke and prod the concept of responsive web design on areas that were safer—I basically didn’t want to break a multi-million dollar website. So, looking for those opportunities that had a lot of the similar characteristics that we see within our suite of products but a little bit more open to the experimentation.

We did a digital version of the VMAs called the O Music Awards. I thought “Oh, this is perfect. It’s like a digital-centric experience. How can you not come up with a truly multi-platform design experience for that particular event?” Then we started looking for design agencies to help us with that endeavor. Happy Cog popped up on our radar and I thought “Who better to partner with to try an experiment with a responsive web design within our organization?” That was four or so years ago. It basically knocked down a bunch of dominoes to really start challenging the question of content rights management, we had a lot of music videos in that particular experience, and then ad sales—it was a highly sponsorable event. There were definitely some challenges in there that we sorted out but it was a great testbed to get the organization comfortable with this particular technique. From there, we proved the value of it and started figuring out how to rethink MTV.com.

I don’t boil it down to desktop or mobile, what I boil it down to is “What tasks are those users hoping to accomplish and what is their mindset when they’re trying to accomplish those tasks?”

Karen:

I’m always interested in how media organizations conceive of what they think a mobile user is or wants, and I’m particularly interested to hear you talk about how MTV imagines the mobile context or the desktop context in light of the fact that your audience is already on another much larger screen. How did you describe the needs of the mobile user and the desktop user?

Ryan:

A lot of that was done via trying to understand who those users are, what tasks they’re trying to accomplish. I don’t think it’s a “one size fits all solution” but I think when you’re talking about the base starting point, responsive as a method makes a lot of sense because you can always bifurcate on those particular use cases that make sense. A good example of this is the VMAs. If it’s a more atomic-level piece of content, like a video or an article, from a holistic point of view it’s relatively okay to make that fully responsive.

We have found a couple other scenarios through research where responsive may not be the most appropriate choice. We do something called All Access, which is basically the night of the live co-viewing experience for the VMAs. I don’t boil it down to desktop or mobile, what I boil it down to is “What tasks are those users hoping to accomplish and what is their mindset when they’re trying to accomplish those tasks?” What we found is the mobile user is more likely to be watching the actual show on television and they’re in a state where they’re more likely to be more focused on the television experience, and they’re just using their mobile device to see “Oh, what’s blowing up on social? What should I care about?” They’re a little bit more of a leaned-back experience.

But when it comes to the desktop user—and I think tablet users fall a little bit more in this category, it could go either way—they’re a little more lean-forward. These are users that usually have multiple tabs open simultaneously, they’re looking at our site, they’re looking at Twitter, they’re chatting with their friend on either a web app or an actual application on their computer, they’re trying to create content on the fly and publish it to Tumblr—there’s a lot of multiple tasks going on for those types of users. Whereas the people that are watching TV, their primary focus is watching TV and their secondary task is more enjoying whatever content we’re promoting on the website.

What we’ve found is the front page experience is pretty much not as important an experience for the user or audience. They’re primarily coming in from the side door, from their Facebook or Twitter or whatever social network feed, straight into that news article.

But I think that’s a special use case. The far majority of our audience is really whatever device that they have available, that’s what they’re going to reach for first. If we can provide a great experience with whatever device that they pick up, well then that’s going to be great for them.

The one counter to what I described with the VMAs was our news experience. What we’ve found is the front page experience is pretty much not as important an experience for the user or audience. They’re primarily coming in from the side door, from their Facebook or Twitter or whatever social network feed, straight into that news article. Because of that, I think right when I was leaving our average was somewhere in the high seventies/low eighties in terms of breakdown between mobile and desktop—much more predominantly mobile because it’s very social-driven and social is very mobile-centric.

Ethan:

I’d love to hear about the way in which you scope or structure responsive projects change might have changed, moving from the O Music Awards up to MTV.com. We speak to a lot of organizations who assume by default that a responsive project is three hundred times more expensive than a regular site because you’re getting mobile, tablet, and desktop for one. How did you guys think about internally?

Ryan:

For MTV, the question for us was “Oh my God, how do we re-architect and restructure and recreate a large financially profitable website that’s been on the web for twenty-plus-years?” There’s a lot of nooks and crannies in a website that old. What we had to do first was a crazy audit of the entire site and we had to align that with “How is the traffic performing for each one of these pages? What is the business value of each one? If we were to kill that page, could we redirect it somewhere else?”

From there, you could really try to understand what the user’s perspective is, from a qualitative or a quantitative perspective, of those areas that you’ve culled down to—what are those priorities to those users? What are those priorities to us from a business perspective? Then that really becomes your “a-ha! moment” of “Okay, we really need to focus in on that particular area and these are the remaining areas that we need to go and clean up” or work into our process. It becomes a game of ruthless prioritization based upon what our business or user needs are.

A lot of the goal that we set for ourselves was, while you’re thinking about layouts, how can you actually make your ads integrated into the site more?

Karen:

You have a large, complex, financially profitable website, and for many of the publishers that we’ve spoken to, the responsive ad problem is one of the thorniest problems out there. How did you deal with that?

Ryan:

I’ve been following you and seeing you talk about viewability—that’s something that we’ve been talking a lot about. One of the big goals that we had set out in the very beginning was to open up a dialogue with ad sales to say that we know from talking to our users and with common eye-tracking studies of users and what not—what we call the L-shaped pattern where you have a 728x90 up in the upper top portion of your site that then would extend down to a 300x250, and right-rail blindness as well—it just becomes this chunk of real estate that you’re training the audience to ignore. So, a lot of the goal that we set for ourselves was, while you’re thinking about layouts, how can you actually make your ads integrated into the site more? So it feels a little less like “Oh yeah, we’re sweeping this off into the corner” but it’s actually part of the experience.

In order to work with our ad sales team with these types of things, I really valued, and made sure the team valued, a design methodology of “show, don’t tell.”

Then combining that with more performance-based solutions, like deferred loading, which then ties into the viewability question of, if something is scrolling up and the space for that ad is about fifty-one percent into view, can you load that ad into view? So you get a decent viewability score and you’re not making all those heavy ad calls at page load time but after the page is fully rendered and people start using the page. The challenges there though are the speed at which the ad server works and how quickly it can recognize that you’ve scrolled that object into view and it makes the roundabout trip to come back.

In order to work with our ad sales team with these types of things, I really valued, and made sure the team valued, a design methodology of “show, don’t tell.” Instead of showing comps and talking to these static comps and saying “Okay, well the ad would be here and it would pop in like this,” you actually do prototypes and those prototypes are rooted in HTML and CSS so that you can allow the ad sales folks or whomever to load it up on a device so they get more of a tangible sense of what we’re really trying to solve and how we think our solutions may or may not benefit the organization.

Mobile was a separate silo in the organization. We had separate leadership and production teams managing our M-dot sites. We even had a different logo for MTV on mobile.

Ethan:

I love hearing about prototypes and incorporating them into the design process. Is there any other way in which the design process at MTV has changed as you guys have started doing more multi-device responsive work?

Ryan:

When I first started we had these silos, and the silos were structured across the organization in a lot of different ways. We were talking about mobile earlier and how mobile fits into us as an organization. Mobile was a separate silo in the organization. We had separate leadership and production teams managing our M-dot sites. We even had a different logo for MTV on mobile.

The fundamental change—and we were going to make this change anyway—small teams, cross-discipline, cross-skilled, blurring the lines as much as you can so that everyone was responsible for the end result.

Similarly within the development, design, and product management perspective, it was very siloed, where product management would define what the product was and then they would do wireframes. Those wireframes would be kicked over to the design team, the design team would do some styling work on those wireframes but not really deviate too much from them, and then that would get kicked over to the development team.

The fundamental change—and we were going to make this change anyway, responsive was just a natural “Oh, well this even works better if we’re going to work this way from a methodology perspective”—small teams, cross-discipline, cross-skilled, blurring the lines as much as you can so that everyone was responsible for the end result. It’s not “Well, this person developed it this way and this person designed it this way, and this person defined the product this way.” It was more everyone could ask each other questions that shared knowledge amongst the team.

The designer was challenging the developer, the developer was challenging the designer, it wasn’t a game of throwing something over the wall and just hoping that it landed properly.

When you’re talking about design and prototyping, what we set as a goal for our early first releases of what we termed the “UI kit” was just a pattern library, a visual style guide that was fundamentally rooted in HTML and CSS, that both the designer and the developer co-owned. Those types of things were really beautiful to watch happen for a couple of different reasons: one, the designer was challenging the developer, the developer was challenging the designer, it wasn’t a game of throwing something over the wall and just hoping that it landed properly. It was much more of a conversation in design and technology. Two, that shared knowledge that I mentioned is really great just to keep the project moving along, but also trying to understand, going back to the user perspective, that shared empathy, that shared understanding of what needs the users have.

If you’re not working at that more focused, small team approach, then quality is going to suffer and the end user is going to be the big loser in the process.

One of my most favorite moments was seeing a developer challenge a designer and using research and actual comments that we heard users say in terms of trying to win his argument with the designer. I thought that was beautiful. It means that it’s not just the user experience designer’s role to care about the user but it’s a team effort. That, as a basis, was key to making a responsive design process work because there are a lot of different devices that you’re trying to support and if you have these starts and stops because everyone is working independently, you’re not going to get very far very quickly. If you’re not working from a user-centered perspective where you’re trying to define what the need for the user actually is; making sure that you’re prototyping and working through and testing whether or not you’re going up that chain of “Is it useful? Okay, it’s useful. Now is it usable? Okay it’s usable. Okay, how do we feel about it from a visual perspective?” and then pushing it out the door and doing iterations down the line. If you’re not working at that more focused, small team approach, then quality is going to suffer and the end user is going to be the big loser in the process.

As we started building out this UI kit framework, that became our sketching tool because all of those patterns were in existence and we didn’t really care about the fine high quality details.

Ethan:

As you guys have become more cross-disciplinary, have you found yourself hiring for different roles? Have the applications and tools you guys have been using as you’ve worked more with the UI kit changed as well?

Ryan:

When we were first starting the early stuff, to be frank, we didn’t know what we were doing. We were experimenting and trying different approaches. Those core principles were still at play, like “show, don’t tell,” and what we found ourselves doing in those early stages where we were still working primarily in Photoshop, was we would do sketches, we wouldn’t spend too much time on the high detail polish. But you’re still working in a pixel perfect-based environment. We would kick out desktop, tablet, mobile, we’d make sure we’d have those three checkboxes covered and then we’d throw it into a product InVision. My concern about that process was you’re still working in a completely different technology and a completely different environment, and you’re not really working in the space that you’re ultimately going to be working in, so how can you get as close to the metal as you possibly can?

As we started building out this UI kit framework, that became our sketching tool because all of those patterns were in existence and we didn’t really care about the fine high quality details, it was just more like grey boxes for images, we tried to use as much real text as we possibly could, and then we did a couple of prototype iterations and we could use those low-fidelity HTML UI kit-based sketches to have a team conversation around stuff.

I think there are a lot of different tools out there. I joked with my team about how we’re actually in a pretty beautiful point in time where there are so many different tools out there for us to experiment with.

Not everybody on the team felt as comfortable working straight in HTML and CSS. There were people on the team who loved it from a design perspective and I said “Go for it.” I didn’t really care what the team was using, just so long as they adhered to these principles and could get as close to the metal as possible. Later on we started introducing things like Webflow as a tool to help the other team people who just didn’t feel as confident or weren’t as efficient, because really it was mostly about how can you sketch, how can you get to the idea as fast as you can and not get lost in the details? At that early stage, the details weren’t the priority.

I think there are a lot of different tools out there. I joked with my team about how we’re actually in a pretty beautiful point in time where there are so many different tools out there for us to experiment with. While I love what Adobe has done over the years, it’s nice that it’s not all coming from Adobe but there’s a bunch of startup companies all trying to solve that particular niche. We had conversations with the people who created Webflow, trying to get a sense from them about where they see their product going, and I think they were still in that mindset of trying to create a tool that’s like the history of Dreamweaver; that idea of WYSIWYG, draw out all these things and hit publish and you can just cut out the developer middleman. But I felt in our particular organization that that wasn’t the point of the tool for us. It was more just a means to sketch and as a communication device, a design tool with our developer counterparts.

My concerns about that as a process was if we start talking about a multi-platform world and pixel densities, layout densities as screen sizes change, or the natural state of changing design layouts—if you have photography, how do you set up and future-proof that, to make it future-friendly?

Karen:

How did the work or the relationships with the editorial team, with the content team change? Did their tools change as well? Did their content management workflow change?

Ryan:

I think because we have a website that’s twenty years old, that was probably the more challenging aspect of what we were working on. How do you take a system that is long in the tooth and start augmenting it so that you can start supporting workflows that make a little bit more sense in this particular age? I would point to two particular tools that we had to craft. One was basically a rights management tool that would be an intermediary layer between the database where all the records were held and the website because while we were doing responsive, we were also doing certain checks to say “On this particular platform, allow this video to play, on this particular platform, don’t allow this video to play unless you authenticated through a TV-everywhere authentication mechanism.” So, that was a particularly important tool to manage this critical business requirement of content rights management.

The more interesting, at least to me, tool was one that I advocated for which we just simply dubbed the “photo cropping tool.” When I started looking at the photos and how they were managed, looking at how the designs were implemented on our site, everything was primarily a 4x3 aspect ratio but just a bunch of different sizes. All those sizes were manually cropped, manually produced, and then they would be attached to a record in the database to live on forever. My concerns about that as a process was if we start talking about a multi-platform world and pixel densities, layout densities as screen sizes change, or the natural state of changing design layouts—if you have photography, how do you set up and future-proof that, to make it future-friendly?

I think that’s a great example of a tool that we built to change the workflow for both the editorial staff but to set up the design team, tech team, and product team to have a lot more flexibility and to be more future-friendly.

The big change there was instead of running everything through a photo editor to manually crop seven different sizes that essentially are the same aspect of 4x3, where there’s no source from an image perspective, with the new tool we would upload the largest source file that you possibly could. With our database nowadays, you have everything from a 1080p screengrab all the way up to stuff that’s print quality from Getty Images or something like that. After uploading the largest source file, you then load that image into this photo cropping tool where you can then define coordinates within that image, and then it’s all based upon aspect ratios, so 4x3, 16x9, 1x1. Right before I was leaving, we were talking about adding a 3x1. So, common aspect ratios, and then within each one of those aspect ratios, the ability to do a large and a small so that the photo editor, producer, or editorial staff could go in and define a nice big image for big crops as well as something they could scale down to for something a little bit tighter so that it could be on-the-fly art direction.

The way that worked from a code perspective is you could call in any sort of image, apply any sort of image size parameters on it—and our designs were all based upon 4x3, 16x9, 1x1, 3x1—and then the code would then make that image request and generate it on the fly. If it dipped below a certain pixel dimension, then it would go in and get that smaller one and crop that one on the fly. What that set us up to do was we could do retina quality images, we could say “Hey, today instead of doing a 16x9 image, we want to change the layout to a 1x1 image” and we wouldn’t have to go back and have them reprocess or manually re-crop thousands upon thousands of images. Down the line, who knows where it could go? But at least at the database level, we have a nice huge source image file that we can do whatever want to do with it. I think that’s a great example of a tool that we built to change the workflow for both the editorial staff but to set up the design team, tech team, and product team to have a lot more flexibility and to be more future-friendly.

In a relatively small window, maybe a few weeks before and after the relaunch of News, and we saw a 570 percent lift in referrals from social. Roughly by the time I had left, we had almost tripled MTV’s traffic.

Karen:

You mentioned earlier about having an established, successful, twenty-year-old website and not wanting the responsive redesign to screw that up. How do you know if this responsive redesign is working? What kind of analytics or stats do you look at, and do you look at anything different now that the site is responsive?

Ryan:

It really depends on which particular product that we’re talking about. To use one particular example with News, one of the key metrics that we were focused on was SEO, making sure that when people do a search for Kanye West that we’re highly ranked for it. While SEO is still intensely invaluable, the model and the mindset has shifted. One of the big concerns I had about using SEO and making sure that we were highly ranked for certain keywords that we value was greatly illustrated when one of the Beastie Boys died. My mom called me and said “Hey, I was on your website today.” I said “Why were you on MTV?” and she said “Oh, I was on Google News and I saw that a Beastie Boy had died, and I like the Beastie Boys so I clicked on that article and boom, I was on your site.” I thought “Hm, if we’re trying to go after this particular demographic, I wonder what percentage of our traffic is being skewed by that? Is there a better metric that makes more sense for our audience?”

We did a bunch of research around that and social was a huge aspect of it. We saw in competitors in the space, like BuzzFeed and the like, that were really jumping off and they were primarily doing it through social. So, a lot of the rework that we did with the news was trying to make sure that it was one, more in the proper voice and tone for our audience, and two, that it was much more socially-minded and socially-friendly. One of the big aspects of that was making sure that if you can combine the right tone and voice and you can have a quality experience on mobile, given that most of that traffic is coming in through social is on a mobile device, then you should really be looking at “How are your social referrals doing? What’s the breakdown between mobile versus desktop?”

One thing I want to clarify and point out is that responsive is a mechanism, a tool that helps us, but it’s that in combination with all the research that we did, all the strategy that we put into play that allowed us to see that type of increase in numbers.

We did a look at our metrics and in a relatively small window, maybe a few weeks before and after the relaunch of News, and we saw a 570 percent lift in referrals from social. Roughly by the time I had left, we had almost tripled MTV’s traffic. [More about MTV’s responsive design metrics courtesy of Luke W.]

You look at those types of numbers and you think that obviously stuff is working. But one thing I want to clarify and point out is that responsive is a mechanism, a tool that helps us, but it’s that in combination with all the research that we did, all the strategy that we put into play that allowed us to see that type of increase in numbers. But again, it’s really dependent upon what your business goals and user needs are and trying to make sure that you are defining some sort of KPI from those that is measurable, and that you build towards that. Then you launch and evaluate.

Launching is just the first step of many. It’s really the evaluation and the changes that you make after things go live.

It’s really about building some sort of sense of “We’re trying to do this a team” versus “I’m trying to ram something down someone’s throat” or whatever.

Ethan:

Do you have any advice for any of our listeners, for people who are working at their organizations and who are thinking about going responsive? What would you suggest that they start working on now?

Ryan:

Get in common agreement about some measurable goal, something that you can all agree on in terms of what you want to see as a result at the end of all of your work. Then position all of your solutions in an objective research-centric manner that is centered around that particular goal that you defined.

I sort of called [Happy Cog] our “digital therapist.” People like to go to therapy because while their friends and family may be telling them the exact same message that their therapist is telling them, your therapist is a third party, they have no vested interest other than keeping you healthy. Those third party opinions can sometimes break any barriers or silos that may exist.

Earlier I mentioned spending time to educate people—there were a lot of concerns, confusion, or just misunderstanding, “What’s that word mean? What’s this?” Just have a conversation with people, do it as a group, do it as a one-on-one, however many different ways that you think it might work. But just let them ask questions. At the same time, be honest. If you don’t know the answer, that’s fine, but provide some sort of avenue and say “Oh yeah, that’s a good question. I don’t know that answer. Let me figure out a way to get it and I’ll come back to you and we can talk further about this.” It’s really about building some sort of sense of “We’re trying to do this a team” versus “I’m trying to ram something down someone’s throat” or whatever.

Pull stakeholders into your process. You really have to work hard to take the mystery out of your design methodology. Don’t go off into a deep, dark cavern and do designs in Photoshop and then drop them on their desk a few months later.

When I pulled on Happy Cog to help us with the O Music Awards, that was a really good approach only just because it was some sort of experimental safespace. If I broke that, people probably wouldn’t have been terribly happy with me but at least I wouldn’t be jeopardizing the established core business. But I think the other part of it that was really beneficial was—I sort of called [Happy Cog] our “digital therapist.” People like to go to therapy because while their friends and family may be telling them the exact same message that their therapist is telling them, your therapist is a third party, they have no vested interest other than keeping you healthy. Those third party opinions can sometimes break any barriers or silos that may exist.

Every minute that it‘s not live is a minute that you’re not actually getting real learnings in terms of how your solutions are actually playing out.

Pull stakeholders into your process. You really have to work hard to take the mystery out of your design methodology. You can do that in a lot of different ways. As I said, “Show, don’t tell.” Don’t go off into a deep, dark cavern and do designs in Photoshop and then drop them on their desk a few months later. Pull them into milestones, invite them into research studies so that they can hear out of their users’ own mouths the problems that they have with IA, content strategy, terminology, whatever the case may be. It’s helpful to put a human face on what you’re trying to accomplish, and it just helps to pull things together. Try to do that as frequently as possible. When you do that and you have those check-ins and you’re taking the mystery out of the design process.

There’s always that fear of the approval process. Towards the end, we technically didn’t really have an approval process because people were just so ingrained in every single step down the line that it more became a question of “How comfortable are we all with the current state? Do we have the right ideas in these solutions that will make sure that we’re getting the learnings that we’re trying to get out of it? How much more polish should we be doing versus how much longer it’s going to take?” Every minute that it’s not live is a minute that you’re not actually getting real learnings in terms of how your solutions are actually playing out. So make sure that you’re releasing quality stuff but your focus is more on answering that original goal that you set up at the very beginning of the process. Those are things that I’ve learned throughout the process and things that I wish someone would have told me from the beginning. That would have helped me out immensely, I’m sure.

Ethan:

I think you made a lot of listener’s lives a lot easier just then. That was beautiful, thanks. And thanks so much for taking the time to chat with us today. Both Karen and I really enjoyed it.

Ryan:

Great. I really enjoyed it too. Thank you very much.

Karen:

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. If you’re interested in bringing us to your company, 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 to our sponsor, Campaign Monitor. Be sure to visit campaignmonitor.com and check out their email editor, Canvas. Thanks for listening, and we’ll be back next week.