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, well, there aren’t enough thumbs up icons in the world to express how excited Karen and I are to be speaking with Mike Finch from Facebook. Mike, thanks so much for joining us.

Mike:

Hey, thanks for having me.

Ethan:

Oh, are you kidding? It’s great to have you.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Harvest. I have to make a confession: I hate, hate, hate tracking my time. It always makes me feel like Fred Flintstone chiseling out his time boulder before he slides down that dinosaur’s back so he can go home. But using Harvest doesn’t feel like punching a time clock. Harvest is a beautifully designed tool that lets you track your time on client projects, start a timer from a web browser or mobile device, and it even lets you send invoices when your time tracking is complete. If you’re a responsible business professional you should be keeping tabs on which clients and projects are making you money—and the way to do that is through careful time management using Harvest. So check out Harvest today. Go to getharvest.com and start tracking your time. They’ll give you a thirty day free trial. When that’s up, enter the code RESPONSIVE at checkout and you’ll save 50% on your first month. Don’t hate tracking your time. Get Harvest.

Ethan:

So Mike, why don’t you just introduce yourself, tell us a little bit about what you do at Facebook, and maybe tell us a little bit about how responsive design intersects with that.

Mike:

I’m a product designer on the platform team at Facebook. I’m currently the designer of Facebook Analytics. It’s a tool that’s built for app developers to better understand how their users actually use their apps; it’s great for usage insights, A/B testing, that kind of stuff. In regards to responsive design specifically, we’re in the process of making Facebook Analytics responsive, and I’ve had some reasonable success with a few other projects at Facebook, getting them to go responsive.

Ethan:

That’s really exciting to hear. Maybe you could tell us a little bit about that process of going responsive at Facebook. That could be either with the Facebook Analytics product, or I know you worked on code.facebook.com, I think you mentioned that that was one of the earlier projects you worked on. I’d just be curious how you actually convinced folks that responsive was the right way to go for those products. Were there any questions that came up, or concerns? What were some of the driving factors for going responsive?

Mike:

That’s a great question. Let me rewind for a couple of years: So, it’s 2010 or 2011, something like that, I’m sitting at An Event Apart in Boston and this guy named Ethan Marcotte takes the stage, and he started talking about this concept called responsive web design, the idea basically that you could build your site once and it worked anywhere on any device. And I remember sitting there—and this is a totally true story—I remember sitting there and I really needed to pee…

I’ve basically been a responsive design advocate since that day, honestly.

Ethan:

[laughs]

Mike:

…But I’m listening to this guy talking on the stage and I actually remember having some inner dialogue, weighing the pros and cons of leaving to use the restroom versus holding it in and getting a kidney infection, because I didn’t want to miss a word that the guy had to say. I’m very happy to say that I chose the kidney infection.

I’ve basically been a responsive design advocate since that day, honestly. Every place that I’ve worked, every project I’ve worked on, it’s something that I’ve championed since that day. Really, why go responsive on any project, really? I would say it’s just because it’s the right thing to do. And I think being able to share that passion with the developers and the PMs, the stakeholders that you work with, I think they get it; I think they get it just like I got it at An Event Apart, sitting there, trying not to pee.

I really love the idea of using responsive design planning as a technique of pruning your existing site’s content. I’m not really a fan of removing content for mobile.

Karen:

Let me ask you something sort of broadly about how Facebook looks at the changes that have happened in the industry since that time, around the increasing population of mobile users. I think when Ethan and I talk to companies about responsive design, there’s sometimes this sense from people that they want to point to enormous platforms, like Facebook or Google, that are not responsive for their web front-end and suggest that, “Well, if Facebook and Google aren’t doing it, well, maybe we shouldn’t do it either.” And with Facebook increasingly tipping to—you know, I think you’re essentially a mobile product at this point—can you talk about how you describe the needs of a mobile user versus a desktop user? And are those different, and do they affect the way you think about platforms?

Mike:

That’s a great question. So in our Q3 earnings call a couple weeks ago, we announced that we’ve got now over 1.4 billion people on Facebook on a mobile device each month, and over a billion of that is on Android specifically. Our total monthly active user count is currently 1.55 billion, so we’re definitely a mobile-first company at this point; internally it’s how it’s discussed.

Lately we’ve been focusing on refining our mobile experiences in emerging markets, areas like Latin America and Africa, places like that. Earlier this June, we launched Facebook Lite, which is like a new version of Facebook for Android that uses a fraction of the data, specifically for poor network areas. It’s only like a megabyte in size, so it’s super fast to install and load. And, again, considering that there are 900 million active users on WhatsApp and 400 million on Instagram, we’re definitely a mobile-centric company.

Your content in one place should be your content everywhere, just presented appropriately for its context.

I’ll say it this way: I really love the idea of using responsive design planning as a technique of pruning your existing site’s content. I’m not really a fan of removing content for mobile because it goes back to the outdated philosophy of having separate versions of your website, right? Your content in one place should be your content everywhere, just presented appropriately for its context, the context that it’s shown in.

I think Facebook is starting to come around to that, actually. So, we’re seeing more and more one-off projects becoming responsive throughout the company. There are different exploratory projects in play right now, seeing what else we can make responsive without breaking everything, you know? It’s something we’re constantly talking about. But we’re starting small and trying to grow from there.

The successes I’ve had so far getting teams to adopt responsive design have all come from just starting super small, something like establishing a responsive grid, and just getting that to work properly.

Ethan:

Mike, I’d love to hear a little bit about scoping. It sounds like you’re in the middle of a responsive retrofit right now with Facebook Analytics, but the code.facebook project I think you mentioned was, more or less, a ground-up design project. Just generally, how do you think about structuring and scoping a responsive project? If you’ve worked on subsequent projects or even newer ones, has your process changed for how you structure those projects?

Mike:

The successes I’ve had so far getting teams to adopt responsive design have all come from just starting super small, something like establishing a responsive grid, and just getting that to work properly; no bells and no whistles, just starting as small as possible and establishing a precedent for future responsive design work going forward. Specifically when it comes to our engineering blog, code.facebook.com, I think really we were just concerned with, again, establishing that precedent with something small.

There are a lot of benefits of starting small, right? There’s less to go wrong, there’s less hoops to jump through, there’s less of a risk involved. So, I think when it came to scoping the engineering blog for example, we just tried to go as small as possible to get something out the door that we could build on later.

When we’re showing and displaying work to stakeholders for example, when we’re showing it on a desktop, they don’t necessarily care or notice that the grid is suddenly responsive.

Karen:

Let me follow up on that and ask specifically about your thoughts on how you best roll out or facilitate a transition to responsive within an organization like Facebook. When Ethan and I were out in Seattle, you gave a fantastic talk on starting small, and I’d be very curious to know: how do you think about getting responsive into the water? How do you think about taking an existing product, like Analytics, and doing a retrofit on it? How do those rollout processes work for you at Facebook?

Mike:

Because all of these projects are just smaller one-off projects with really small scopes, we just kind of went for it, to be honest, instead of having a gradual rollout or anything like that.

One thing in regards to stakeholders and getting buy-in specifically on some of these projects: we have a ton of autonomy at Facebook, and our stakeholder buy-ins, they’re a bit more relaxed than some other places. Most stakeholders of Facebook are just interested in the goals and the results and less about the tactical ways that teams tackle those goals. So we definitely have a lot of autonomy and we’re able to chase down solutions kind of as we see fit; we’re largely trusted to do those things in the way that we feel is best.

Because of that, when we’re showing and displaying work to stakeholders for example, when we’re showing it on a desktop, they don’t necessarily care or notice that the grid is suddenly responsive, that it’s on a fluid grid that actually goes down to mobile. Those aren’t things that you just see that are obvious by default. So, I don’t think anyone really, at that level, really cares, as long as things are happening in a positive manner and is positive for the user.

Whether we’re talking about mobile or desktop, everything on the screen should have to fight for its existence to be there.

Ethan:

Mike, tell me a little bit more about the responsive retrofitting projects. I liked what you were saying about putting the emphasis on the needs of the mobile user and just sort of building up from there. So if you’re taking a desktop-specific property, or one that was designed for the desktop, how are you making decisions about what to keep and what to get rid of? Or are you even able to sort of streamline the content to make it more mobile-first appropriate? Tell me a little bit more about that process.

Mike:

Yeah, I think that everything in general, whether we’re talking about mobile or desktop, everything on the screen should have to fight for its existence to be there, I think.

What responsive design does, is it forces you to evaluate the content on your site, on your page, and say, “Is this really necessary?

What responsive design does, especially in the early stages of planning, is it forces you to evaluate the content on your site, on your page, and say, “Is this really necessary? Is this the right content that we’re showing at the right time?” I feel that while different parts of it maybe emphasized in different ways, I feel the content should basically be the same from page to page, whether you’re on desktop or mobile, and not creating two separate experiences.

Ethan:

Let’s talk a little bit more about design process; let’s get in the weeds a little bit more. Mike, you’ve been a long-time advocate of responsive design. Has your design process changed over the last few years? And more specifically, at Facebook, are the applications and tools you’re using to produce a design, to talk about the design, to share it with other people, have those changed as well?

Mike:

The tools that we use at Facebook—again, having complete autonomy over how we work, you get to pick and choose which tools you use and in what manner you use them, there’s no standard across the board. So some people prefer making assets and screens from Illustrator or Photoshop or Sketch—I personally use Sketch.

My design process, I wouldn’t say it’s changed actually that much. The way I kind of design is similar to Brad Frost’s Atomic Design and Pattern Lab that he’s set up. So I start by creating a library of common UI patterns and controls in Sketch, and when it comes to designing in screens, all your little LEGO bricks are already right there, so all you have to do is kind of click and drag elements into place. So, Sketch also has great art board presets for desktop, tablet, mobile, so in the case of a responsive design project, it’s simply a matter of dragging those components into three art boards instead of one. So the process actually hasn’t changed that much for me.

By instituting responsive design, it’s not that anything changes on desktop necessarily, it’s just that now you get mobile for free.

Karen:

Let’s talk about how the process of reviewing your work with the rest of the organization might have changed. So, many teams that we talk to, as they move to a responsive design process, they have moved away from looking at static comps and are now reviewing prototypes, and that changes the way their team interacts. Has that changed at Facebook, or is a responsive review process essentially the same as all the other work you’ve been doing for a while?

Mike:

On most teams at Facebook, there are almost two different kinds of design reviews: there’s one with your immediate design team and another with your cross-functional team, like the PM you work with and all the engineers. The immediate design team review is more of a UX and craft-based critique, and the cross-functional review is more about addressing specific business goals. Neither have really changed much with the adoption of responsive design.

Thankfully, the beautiful thing about responsive design, I feel, is that if your application or your site has traditionally been desktop-only, by instituting responsive design, it’s not that anything changes on desktop necessarily, it’s just that now you get mobile for free. In that, it really hasn’t changed much, I would say.

As far as communicating some of these new design patterns with the rest of Facebook, it’s great. We have a team dedicated specifically to UI patterns that we use across different Facebook properties, and those are built out in different tools, like Photoshop and Sketch, and they’re available for both desktop and mobile screens. So, again, we’ve got quite a bit of UI backing and precedent for making these mobile screens, so the communication process of updating one particular property to be responsive, it actually isn’t that big of a deal in our organization because all of the patterns are still the same.

The performance and load times and everything that we care about and look at regularly actually hasn’t been any worse. If anything, it’s been better.

Ethan:

Mike, maybe you could tell me a little bit about this word I keep hearing, which is performance. Given the fact that Facebook is obviously very focused on emerging markets and lower network constraints, is that something that you’ve found has kind of bubbled up to some of the responsive projects that you’ve worked on? And if so, how do you actually define what constitutes good performance for the stuff that you’re doing?

Mike:

Yeah, that’s a great question. It is somewhat of a cop-out answer, but it completely depends on the product. So, the performance metrics that we might judge, for example, Instagram on—just as an example—might not be the right set of performance metrics to judge Messenger on.

But in the case of Facebook Code, we really just wanted people to come, relax and learn, really, about the open source work that we’re doing. So load times are important, time on site, things like that. But it really does vary from team to team.

You can definitely have very intense applications running, very robust systems, and they can be responsive and still load in a very quick, timely manner.

I will say that looking at the metrics before and after we decided to go responsive on some of these projects, the performance and load times and everything that we care about and look at regularly actually hasn’t been any worse. If anything, it’s been better. So it’s definitely a strong testament to the way that we’re building some of these products that you can definitely have very intense applications running, very robust systems, and they can be responsive and still load in a very quick, timely manner. So, it’s been great.

We have not only a device lab, but we’ve got a different cellular service for those devices. We can actually emulate the service on a particular device in an emerging market like Kenya.

Ethan:

That’s awesome. This might be circling back a little bit on process, but tell me a little bit about how you tend to QA your responsive projects. Are you doing device testing? Do you have a device lab that you work with? Tell me a little bit more about the way you just sort of make sure everything is working.

Mike:

Yeah, we have a great device lab in Menlo Park. Actually, we have not only a device lab, but we’ve got a different cellular service for those devices. We can actually emulate the service on a particular device in an emerging market like Kenya, for example. We can actually pick up the device that is most sold in Kenya, we can experience the speeds, for example, that they would be experiencing there, and we can test accordingly on that.

In regards to our QA process, I don’t think it’s really changed that much. Being mobile-first now for a few years, our engineers have a pretty good cadence to their browser and device testing, and they’ve taken those responsive changes in stride, again, because they’re already accustomed to designing and optimizing for all these different devices all around the world.

Karen:

I would imagine that Facebook has astonishingly robust ways of measuring the success of its applications or its products. Has that changed at all when the product was responsive? Like, do you still evaluate the success of the product by looking at the lens of mobile, tablet, and desktop even though a responsive product works across all of those?

Mike:

So, in our analytics we basically would look at how many people viewed, for example, Facebook Code on desktop and on mobile. And in this case, in the example of Facebook Code, it’s about twenty-five percent of users that view it on a mobile device. We would essentially treat that and those metrics, we would slice that off and treat it like we would any other Facebook product that has a specific mobile site for it. So as far as evaluating maybe Facebook Code against the actual Facebook site, we would look at the number of mobile users on Facebook Code and then compare those stats to the users using Facebook on a mobile device.

It’s easier to get buy-in on anything if the barrier to entry is low; and if your responsive work has unintended consequences, starting small allows you to fix those mistakes easier.

Ethan:

Well Mike, I’ve got to say, it’s been fantastic talking to you today and I really appreciate you taking a few minutes to chat with Karen and I. Before we let you go, I’ve got to ask: if any of our listeners are about to start a responsive project, do you have any advice for them? Are there things that you’ve learned that you would like to share with other organizations who are thinking about a responsive redesign?

Mike:

Yeah, definitely: just start small. I’ve found the most success with responsive projects just starting small. Definitely don’t be like me coming from An Event Apart, all idealistic, full of ideas—you’ll scare people with that kind of enthusiasm. Instead, play it cool and start small with a small goal. You have less to lose if things go badly, it’s easier to get buy-in on anything if the barrier to entry is low; and if your responsive work has unintended consequences, starting small allows you to fix those mistakes easier. There are fewer variables to deal with, with user testing; it’s easier to user test, faster to build. Just start small, really. Just try to get something out the door and use it as a precedent to build on.

Karen:

Well Mike, I’ve got to say thank you for taking the time to talk about your work at Facebook here today. Ethan and I were both so excited to have you on because I think we’re both really impressed with what you’ve been doing.

Mike:

Oh, it’s been my pleasure, really. Thank you so much for having me today.

Karen:

No, it’s been great. So, I look forward to hearing more from you and thanks again.

Mike:

Excellent. Well, take care.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, Harvest. Go to getharvest.com and start tracking your time, painlessly, today.

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.