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 beside ourselves with excitement because we’re speaking with Dave Augustine from Airbnb. Dave, thanks so much for joining us.

Dave:

Thanks for having me.

Ethan:

Why don’t you tell us a little bit about what you do at Airbnb, specifically what you guys have been doing with responsive design.

Dave:

I’m presently an engineering manager for the core web team at Airbnb. We’re basically responsible for the website as a whole. We do big projects that cut across teams. We launched a big responsive redesign at the end of last year and are still working on it.

Karen:

But before we dive into our conversation, I want to tell you about some exciting news from our sponsor, Campaign Monitor. Did you know that more than half of emails are opened on a mobile device? Making emails look and work great on all the different devices and email clients is one of the hardest problems in responsive design. And that’s where Campaign Monitor comes in. They have an easy to use email builder called Canvas, that creates emails that look great everywhere. In just minutes, you can drag and drop your way to a beautiful email that just works, with images and typography that will scale correctly on every device. Want to try it out? You can see how it works, and you don’t even need a Campaign Monitor account. Just go to campaignmonitor.com/templates and see for yourself just how easy it is. I know, because I use it myself, and I love it.

We were missing a huge opportunity, one of paid marketing. We weren’t really sending a lot of traffic to our old mobile website, we weren’t capturing the types of growth that we could be seeing in other countries by having an excellent mobile experience.

Ethan:

It looks fantastic and I’ve been enjoying seeing your websites evolve, both mobile and desktop, in the last couple of years. I’d love to hear more about the original discussions about going responsive. What were some of the drivers and how did you convince your stakeholders to get on board with responsive design as a methodology?

Dave:

Well, it comes in a couple of factors. From the engineering side, our old mobile website was showing its age. It was three years old, it didn’t support anywhere near the number of features that the main application has, the design was out of date.

From a business standpoint, the growth team actually did a deep dive into the business metrics and the data scientists found that we were missing a huge opportunity, one of paid marketing. We weren’t really sending a lot of traffic to our old mobile website, we weren’t capturing the types of growth that we could be seeing in other countries by having an excellent mobile experience. Especially after our rebrand, it became really clear that this is an important piece of the web that we just weren’t really paying attention to, and it was time to get it under control.

Desktop web, that’s where the majority of our traffic still lies—the mobile share is growing but it’s not quite there yet—and it’s still really good for doing a lot of your trip planning work, it’s where most of our advanced hosting features lie.

Karen:

How does your organization see responsive design fitting into the larger digital ecosystem? Sometimes people tell me that their company has very specific ideas about what desktop users need versus what a mobile user needs, or there’s very specific ideas about what customers should be using an app for. How does responsive design fit in for you?

Dave:

We do have very excellent native applications that we’re really proud of and we have an excellent website that serves a lot of people’s needs, but there are some differences between what we want to use them for. For example, desktop web, that’s where the majority of our traffic still lies—the mobile share is growing but it’s not quite there yet—and it’s still really good for doing a lot of your trip planning work, it’s where most of our advanced hosting features lie. If you’re an Airbnb host, you probably use your desktop a lot for configuring your listing. With the native applications, you get push notifications; it’s faster, people respond quicker. So, we still want to push people to using that when we can, so we do have touchpoints in our web application to send people there.

We didn’t want to cut any features from our existing mobile website, so we made sure we covered those and then we just expanded on top of it.

For the mobile website, we still have tons of new users joining every day and their first experience is likely not going to be installing an application, that’s a pretty big commitment. We have people clicking on links in email, we have people reading tweets, and we have people just discovering us and what we don’t want to do is send them to a three-year-old outdated experience that doesn’t even really tell you on the homepage what we do or what it is.

We wanted to change all of that and we really focused, for responsive web, on the guest side of things, so the booking flow, like the experience of learning about Airbnb, searching for a place, messaging a host and then booking a place. We didn’t want to cut any features from our existing mobile website, so we made sure we covered those and then we just expanded on top of it.

We have this internal style guide in the front end framework called O2. We made the decision to make it backwards-compatible, so the responsive web framework was going to be compatible with the existing one.

Ethan:

I’d like to hear from your perspective about how you guys approached the rollout of this new responsive site. What did you guys decide to do first for a project of this scale?

Dave:

This is a topic near and dear to my heart. We actually have a history of really tightly planned rollouts at Airbnb. The rebrand in July was a work of perfectly calculated art, so we wanted to model ourselves after that and make sure there was no hiccups and that it was a smooth rollout for both our users and the developers and designers here. The last thing we want to do is interrupt everybody at the last quarter of the year when everyone is trying to get their stuff out.

First and foremost, we have this internal style guide in the front end framework called O2. We made the decision to make it backwards-compatible, so the responsive web framework was going to be compatible with the existing one. This was a huge decision and it was technically pretty challenging to do without stepping on toes. But we pulled it off, and that allowed us to sort of lay the foundation ahead of time and then move on to the actual pages and components so that we were able to get it out there and test it and nobody would ever notice. For timeline’s sake, we basically started development in mid-to-late September/early October and ended up launching at the beginning of December, which was actually an accelerated time frame for what we anticipated.

We were able to completely change the website fundamentally while engineers are still building on top of the existing pages, without stepping on anybody’s toes.

Once the front end framework was updated and out there in production, then we divided the work into pages and components that you could rank from high to low impact. Some high risk pages would be our core flow, which would be the homepage to booking screens and all the pages in between. A little bit under that in terms of risk is our header and global navigation, because on the smallest screen there’s actually a fly out hamburger menu that’s totally new to the website. Then there’s a dozen smaller components that we could roll out whenever we wanted and if people noticed, it was okay. So they get a better experience—that’s not a bad thing. Some examples of those would be our footer or maybe the date picker, the login screen, the messaging page. We organized ourselves around that and it worked extraordinarily well. We were able to completely change the website fundamentally while engineers are still building on top of the existing pages, without stepping on anybody’s toes. We did it right under everybody’s feet and then we were just like “Ta-da! It’s all done!” I’m still so impressed with the team and how they pulled it off, it was really impressive.

We were effectively able to dark launch without anybody really noticing. That meant we were able to test for a full two weeks before anybody knew that the whole website was completely responsive.

But what this meant was that over time, as we got closer to the launch date, there was less moving pieces. At the every end, for the last couple of weeks all we had to do were these core pages, so basically five things. At that point, we made the call to just merge them all into one big change and launched it out there—at this point, we’re talking late November/early December. The great thing about this was that we still had our redirects in place to send the traffic to our existing mobile website, so we were effectively able to dark launch without anybody really noticing. That meant we were able to test for a full two weeks before anybody knew that the whole website was completely responsive. That just makes things so much easier, because then we could really hit the device lab and make sure and polish before we flipped the switch and started to send users there.

In my mind, after seeing a lot of launches at Airbnb, this is one of the quickest and smoothest launches that we’ve had.

Karen:

One of the things that made my ears perk up was when you mentioned that you were on an accelerated timeline. One of the things that Ethan and I have both heard is this notion that responsive design has to cost more and has to take longer, because you’re building three websites, right? Did the scope of this change for you? Was it comparable to previous desktop-only redesigns in terms of timing and budget?

Dave:

This is a tough question because I think the timing was right for this to happen. After July, our rebrand, for the first time we had every page on this framework and things were pretty straightforward in terms of the level of commitment from the engineering point of view. It definitely went a lot faster than I expected; the design and prototype phase was effectively around maybe one to two months, and then the development time was around two months with some holidays thrown in between. There weren’t even a lot of late nights or grueling pace-type work. In my mind, after seeing a lot of launches at Airbnb, this is one of the quickest and smoothest launches that we’ve had.

If you design mobile first and then expand outward, then every page shouldn’t be wildly different.

But speaking to other companies or other situations, if you were approaching this as a redesign as well, then yeah, I think this might be quite a big undertaking. But I don’t think it has to quite be that way. If you design mobile first and then expand outward, then every page shouldn’t be wildly different. You’re just taking into consideration what more real estate might mean. For us, it just worked really smoothly, and maybe it was because our design was already really able to be responsive in terms of us not needing to rethink a lot of things. From my experience, it was went about as smooth as any project could go.

For our prototypes, this whole thing was done in code for the most part. We didn’t really receive Photoshopped docs of what it looked like at different breakpoints; we received code, like an actual functioning website that’s like “It should basically do this.”

Ethan:

You mentioned the O2 framework and how that was a key part in getting this redesign out the door as quickly as possible. How are your designers and developers collaborating internally right now? What kind of tools do they use to talk about design? Is it mostly the framework or are there other deliverables that are used to talk about responsive layouts?

Dave:

That’s a great question and I think we’re still figuring it out, to be completely honest. This really landed at the end of last year and this month has been pretty fast, so we’re all sort of just getting back into it and figuring out how we’re going to work together moving forward. I do know that for our prototypes, this whole thing was done in code for the most part. We didn’t really receive Photoshopped docs of what it looked like at different breakpoints; we received code, like an actual functioning website that’s like “It should basically do this.” That’s not very typical, at least not for our process yet, so I think we have a lot to learn in terms of getting engineers and designers on board with asking the right questions in time and producing deliverables that we can all work with.

So far, what I’ve seen post-launch is a lot of working together at the desk and just trying things out. A designer will sit with an engineer and will tweak it until it looks or feels right. I guess my answer is “TBD.” We still have to figure out what the future looks like.

I think it’s just a matter of over-communication.

Karen:

What about collaborating with the rest of the team? How did your conversations change with other stakeholders or other people who might need to weigh in or approve your decisions?

Dave:

They went pretty well. I think it’s just a matter of over-communication. From my end, it’s just producing document after document explaining what the impact is going to be for the product and engineering organizations, how you’re going to test your new feature in the future, and really setting everybody up for success as much as possible and not surprising anyone.

In terms of product decisions, again I don’t think I have a good answer for that yet because we’re still coming off the launch, still polishing the pages that we did and haven’t begun to tackle a new set of tasks. But it’s just a lot of explaining to the product and engineering organizations, that there are extra considerations, testing has to be done across more browsers and even at different sizes—that’s a new thing. How you develop your page, the framework is changing, so you have to understand what that’s like. It’s just trying to nail the how-to and then talking with people, visiting every team and saying “Do you have questions? Is there anything I can help with? If the team is available, if you need help, just come over and sit with us and we’ll show you what’s going on.”

It’s educating the engineers who are developing the site—in addition to your usual cross-browser testing, now there’s cross-device testing and providing documentation for how to do that.

Ethan:

I know a lot of organizations are still trying to figure out how they define support in the context of responsive design, specifically talking about how their QA process has changed when they’re thinking in a more multi-device context. Have you found that to be the case at Airbnb?

Dave:

Yeah, things definitely changed. Again, I do expect this year to be pretty transformative in the way that people do development for the web. But internally, we built out a device library. There was a small one that existed but we expanded it and turned it into something a little more proper, so we got used to doing that. We also partnered with an external QA firm that we used for testing our native apps. They also test responsive websites, so it was great; I was able to partner with them, they understood our product already and understood the flows, concepts, and terms and all I really had to was develop some quick test plans and they turned them into an amazing comprehensive test plan. We said “Can you test it on these mobile devices, these tablets, and these desktop browsers? Can you do different orientations?” the whole nine yards, so they run through twice a week full-on through the website.

On top of that, it’s educating the engineers who are developing the site—in addition to your usual cross-browser testing, now there’s cross-device testing and providing documentation for how to do that, both in browser with, say, Chrome developer tools and with the various simulators. Finally, how to test on actual devices in the device lab, what sort of hoops you have to jump through to get that to work. It’s going to be an interesting year to find out where the pain points in that process are because up until now it was just our small team learning as we go and hammering it out.

MVP is really just baseline performance, like “Make sure it’s not absolutely terrible.” That sounds really bad but it’s the truth.

Ethan:

I think a lot of companies are doing that right now too, so you’re in great company. How much of a focus has there been on performance specifically on the client side? This is a real area that people are interested in, especially in the context of responsive.

Dave:

Absolutely. We opted for MVP for launch day, which is what we consider what we launched in, and MVP is really just baseline performance, like “Make sure it’s not absolutely terrible.” That sounds really bad but it’s the truth. We wanted to perform really well, like as good as our current mobile website offering, but there’s so much more work to do in terms of optimizing image sizes, which is technically really challenging. This is a huge area of interesting challenges because our website has been growing for years, there’s a focus on performance, for particularly our traffic outside of the U.S., but it does affect desktop and mobile. So, for this project we decided “Let’s shoot for baseline, let’s get it to feel right, to feel good, particularly on and off Wi-Fi, make sure nothing breaks.”

If you do a bunch of work and then wait a month or two before revisiting, it’s going to be as bad or worse than it was before.

We’ve had to get clever with reducing things like scroll handlers that impact perceived performance and scrolling. We’ve selectively turned off pieces of content to improve page performance. We’ve done a small amount of very targeted work to improve the performance, but the real grunt work of pure optimization is coming this year, where we start getting down to the nuts and bolts of pure JavaScript page size, image loading performance, like when we cut contact, how to load content after the page loads, stuff like that. It’s a long road and it’s something you have to keep working on. If you do a bunch of work and then wait a month or two before revisiting, it’s going to be as bad or worse than it was before. So, you always have to have a focus on it. We have a couple of engineers dedicated to performance in total, but I think as an organization we need to set some guidelines, like “This is how fast these pages should load and if you start breaking that, then we need to revisit whatever the change was.” But it’s a huge challenge. Personally, I think it feels pretty good right now but it could be better.

Our first question is “Is it an improvement over what we used to have?” and we’re still waiting on the data to find that out. But my gut feeling is yes, it’s going to be better.

Karen:

Let me ask more broadly about how you measure the success of this redesign. How do you compare the responsive website to how the site performed on a variety of business metrics? How do you know if it’s working?

Dave:

That’s a great question. We’re still collecting data, so we’ve only begun to dive into this question. But generally speaking, we’re very experiment-driven, we want to be scientific with our changes, so we have a ton of tooling in place that’s set up to answer these questions for us and cut across devices. I think the answer is just going to be the typical things, like engagement conversion, bounce rate, stuff like that—we’re going to be able to cut across that pretty quickly. The gut feeling here is that there’s no way it’s going to not perform as well as our previous offering. The question is going to be “How do we want to start optimizing this experience? Where are people falling off?” and then rethinking it as a brand new thing.

But our first question is “Is it an improvement over what we used to have?” and we’re still waiting on the data to find that out. But my gut feeling is yes, it’s going to be better and it’s not like we’re going to undo this work. It’s going to be more about finding bottlenecks or where the user experience is falling off or what’s confusing.

You have to get everybody on board as early as possible—“everyone” meaning stakeholders, executives, designers, engineers. Everybody has to be in it to win it or it‘s not going to work.

Ethan:

As you guys are starting to look ahead, do you have any advice for other organizations who are just starting to embark on a responsive redesign?

Dave:

Communicate early and often. You have to get everybody on board as early as possible—“everyone” meaning stakeholders, executives, designers, engineers. Everybody has to be in it to win it or it’s not going to work. You really have to make it clear how things are going to change and how you are going to effect that change; so, how people are going to work in the “new world.”

Take it from experience—we had the separate web application and it turned out to be a lot of work to maintain and it totally drifted away. Nobody wanted to update it.

The third thing is don’t compromise. This is an excellent user experience and it simplifies so much to have a single codebase that can do it all. Take it from experience—we had the separate web application and it turned out to be a lot of work to maintain and it totally drifted away. Nobody wanted to update it because you had to learn a new thing and it just fell really out of date, and you don’t want that. Mobile is so important to your business that you can’t afford to be sending people to a poor experience. So, my advice is to avoid building a separate web application just for mobile sites. Just go responsive.

It really helps to have a consistent framework, to have every page be coded in the same way so that making big sweeping changes is even possible.

It can be challenging; the funny thing is three years we wanted to make our website responsive and instead we built a separate application. Why did we do that? It’s because nothing was consistent. We didn’t have this front end framework baked in yet. So, it really helps to have a consistent framework, to have every page be coded in the same way so that making big sweeping changes is even possible—it’s not like looking to the top of a mountain. You’re like “Oh, I can do this.”

Ethan:

Once again Dave, thanks so much for taking a few minutes to chat with Karen and I. This has been really exciting and we can’t wait to see where the Airbnb site goes next.

Dave:

Thanks so much! It’s been my pleasure.