Episode Transcript

Ethan:

Hi, this is a responsive web design podcast, where we interview 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 ridiculously excited to have Expedia back for a second round of chats. More specifically, we have Travis Fleck and Tyler Fleck from Expedia. Thanks for joining us guys.

Travis:

Thank you for having us.

Tyler:

Excited to be here.

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.

Ethan:

So, if you guys wouldn’t mind, maybe you could both introduce yourselves and tell us a little about what you’ve been working on lately. Travis, why don’t you go first.

Travis:

Sure. I’m Travis Fleck, I’m a principal interaction designer here at Expedia; I help the team that’s responsible for designing and maintaining and evolving our front end framework, called the UI toolkit, and I also help manage a team of interaction designers.

Tyler:

And I’m Tyler Fleck, and much of my role mirrors my brother’s. I manage a team of web designers and I also work on the core team that manages and maintains our UI toolkit, our front end framework.

Ethan:

That’s fantastic. We’ve already heard a little bit from Scott and Jason last week about how Expedia’s responsive work came to be but I’d still like to hear about it from your perspective. How did you guys actually start having some of those original discussions about going responsive? How did you convince stakeholders and the rest of the company that this is the way to go?

Tyler:

I think Jason and Scott talked through some of that story, and really I think some of the key decision points came when we really built out our front end framework. So, it was somewhat a proof of concept, kind of bare bones; a grid system, a typography system, a few enterprised components. We brought that to our leadership team and I think they really saw the value in it, to say “Hey, we’re going to centralize the front end experience and expertise that we have and really figure out a way to leverage best practices at the core of what we’re doing.”

Travis:

The team also went through a process of identifying and consolidating the core UI patterns that were on the site and then added those to the toolkit to allow everybody to share components.

We started with a fairly comprehensive UI audit of what I’ll call the legacy pages, the non-responsive pages, and through that work we kind of identified lots of different common patterns that were in use out there.

Karen:

Talk to me a little bit about how you planned this initial work. As you’re working on this framework, as you’re scoping how you’re going to attack the responsive project, how did you plan and scope time for your team?

Tyler:

It was largely just proactive effort. We started with a fairly comprehensive UI audit of what I’ll call the legacy pages, the non-responsive pages, and through that work we kind of identified lots of different common patterns that were in use out there on the site with minor differences in interaction, in visual treatments. As you can probably imagine, a fifteen-plus-year-old website, that kind of stuff is going to happen over time. But we really knew that going responsive, as difficult and as complex of a challenge as it is, we really needed to consolidate all of that stuff.

I think the scope of work was about six months to begin with and then over the course of about three months, they tested it against the legacy site.

In terms of scoping the effort, it was a daily effort by some people and a weekly effort by others. It started with really just getting the buy-in and working with the UX, product, and engineering teams and saying “Hey, these are the common components, we can rally behind them.” After we built out that initial proof of concept, it was about going through the actual real work of it and making it real and then working further with the engineering teams to make sure that the components were solving their problems.

Travis:

The second part of that work was the product teams prioritizing the work—so, using the toolkit that we built to then redesign their pages and working closely with business and their partner engineering teams to scope that work and then kind of weave it into their sprint schedule. Ultimately, I think the scope of work was about six months to begin with and then, speaking of our hotels path, they launched a version and then wrapped it in A/B test. Then over the course of about three months, they tested it against the legacy site.

One of the things that we’ve been really focused on is getting into code much quicker and usually that just gets everybody on the same page.

Ethan:

I’d like to hear more about your design process at Expedia. As you’ve been doing more multi-device work and rolling this framework out across your different lines of business, has the way in which you think about design changed?

Tyler:

Yeah, I think so. The responsive design strategy presents new challenges and new requirements, and so the process definitely needs to adapt to that. One of the things that we’ve been really focused on is getting into code much quicker and usually that just gets everybody on the same page, whether that’s the design team to our product partners and engineering partners, seeing it in an actual browser, and more recently on actual devices, is one of the big things that we’ve been working on, is getting a device lab together. Actually seeing these design challenges in their native environment has just been huge in terms of streamlining the design process, making sure that we can maintain our velocity and our agility when taking on this newer complexity that we’re taking on.

We coach people to use the best tool to communicate their intent. So, we really want to facilitate designers and engineers speaking the same language.

Ethan:

To follow up on that, as you guys are trying to get into the browser a little earlier, have the applications and tools your team uses changed significantly? Have you thrown Photoshop out of the window entirely? What kind of deliverables are you talking around?

Travis:

We certainly haven’t thrown Photoshop out of the window entirely. Tyler has worked with a few of the front end developers that we now have on the UX team to build out prototyping framework for our designers, so we get a lot more people in code faster and that’s kind of a piece of the skill set that we look for. But I think we coach people to use the best tool to communicate their intent. So, we really want to facilitate designers and engineers speaking the same language.

We try to use the right tool for the right problem, and for responsive problems, even something as simple as a layout becomes more complex and that’s where we’ve had to modify our tools.

As far as the tools specifically, people have been gravitating towards Sketch and then also inVision to kind of design quicker, get to a level of fidelity that they can communicate their ideas more quickly, leading to actually seeing prototypes that are interactive as quickly as possible.

Tyler:

To add to that, we still use all of the same design tools, whether that be sketching, low-fidelity wireframes, prototyping and we’ll still do real detailed visual design work in Photoshop if the audience or the task is right. I echo what Travis said, that we try to use the right tool for the right problem, and for responsive problems, even something as simple as a layout becomes more complex and that’s where we’ve had to modify our tools.

The value of it became pretty self-evident; when we start to roll out our test pages, in terms of getting to a responsive interface as fast as they could, it would not have been possible without that core upfront work on the framework.

Karen:

I know Ethan and I are both curious to hear you guys talk about the responsive framework that you rolled out. Can you tell us about how you communicated that framework or the value of that to your team and how did you train people on using it, how did you coach them on how this would fit into your new process?

Tyler:

Initially, the way we talked about it was a common language between the design team and the engineering team. Once we published our documentation site that outlined all the core components, what you could achieve by using the design and front end framework and how quickly you could assemble UIs, I think people really started to see the value of it in terms of how fast we could actually get to more finished UIs.

From the engineering side, one of the pieces of it was we were trying to build as many best practices we could into the core of the framework. That really set the stage to say as we’re attacking this cross-browser, cross-device strategy, there’s going to be a fair amount of browser testing that goes along with that stuff. That’s a whole lot of complexity when you start to add a bunch of new devices and OS and browser combinations to the stack. Once we had enterprised a bit of it, I think the value of it became pretty self-evident; when we start to roll out our test pages, I think some of the engineering comments, in terms of getting to a responsive interface as fast as they could, it would not have been possible without that core upfront work on the framework.

Ideally in the future moving forward, we’d be able to potentially test a framework change at the framework level and then roll it out for everybody. That would free us up from some of the constraints that we have right now.

Ethan:

How did you manage changes to the individual framework? The best thing about thinking about frameworks is languages because languages change all the time—issues get identified, requests bubble up. How do you manage that process at Expedia?

Travis:

I think that’s actually one of the most interesting things that we are working with currently, is we’ve created this framework, different lines of businesses at Expedia are adopting it and rolling out their new responsive pages, and now we have basically a platform that people are on. One of our biggest questions is “How do we evolve that? How do we take the learnings that people are having on our live site to our testing processes, and how do we roll that back into the toolkit?” That’s probably one of largest challenges Tyler and I currently have and I’m not sure we have a great answer of how it works.

What we try to focus on as we evolve the framework is “What are the common solutions to the common problems?”

Currently, we will sometimes build a new component and have new people test it and implement it on their pages. Ideally in the future moving forward, we’d be able to potentially test a framework change at the framework level and then roll it out for everybody. That would free us up from some of the constraints that we have right now. But I think it’s a great question and not one that we’ve fully answered.

Tyler:

What we try to focus on as we evolve the framework is “What are the common solutions to the common problems?” Whether that’s even just getting core products on the page—a lot of our lines of business are solving some of these similar challenges, whether that’s localization of currency, how to deal with different formats from the way we present products on the site. So, how do we develop utilities and other components that solve the most problems for the most teams? That’s really been our benchmark in how we either add capabilities to the toolkit.

But it does extend. From an engineering perspective, anybody can contribute to the codebase. So, if you were to imagine a feature that needs to be added for our maps presentation in our hotels path, that same feature set might be valuable to another line of business or another page somewhere. In those cases, the developers from the hotels team have contributed that stuff back into the toolkit, done the work once and allowed it to be available for everyone.

What we have seen is more collaboration between designers and developers and really keeping all of the lines of communication open so that we can quickly iterate to the better solutions and not kick stuff over the wall and hope it comes out well.

Karen:

How does this new way of working change the way that you form or construct your teams? We’ve talked to some people who have created new roles within the organization, they are hiring different types of people, they are structuring their teams differently so that people can collaborate more effectively. How has it changed the actual organizational structure?

Tyler:

We’ve definitely added some new roles on the UX team, with a focus on a front end technical skill set. In terms of structure for the rest of the organization, I don’t know that it’s changed that much. What we have seen is more collaboration between designers and developers and really keeping all of the lines of communication open so that we can quickly iterate to the better solutions and not kick stuff over the wall and hope it comes out well—it really doesn’t solve the problem unless you have that skill set either on the team, or if you don’t, then you need to collaborate with partners that can help you solve those responsive challenges.

That really tight feedback loop for all of those groups with a common shared understanding of a common goal really allowed those teams to move quickly and execute at a high level.

Travis:

What we have had is the ability to, in smaller situations, see different ways of working and see the positive effects of those. I think the last time you had Scott and Jason on, we had recently tested our mobile hotels path versus a small breakpoint responsive hotels path. In going through that process, our designers were sitting right next to our developers and they had regular check-ins with our product managers who could make decisions on the fly, and that really tight feedback loop for all of those groups with a common shared understanding of a common goal really allowed those teams to move quickly and execute at a high level. So, I think we’ve gotten some proof points in some different ways of working, and at a company the size of Expedia, changes like that happen much more slowly but it’s been interesting to see how the team has come up with different ways of working and been successful.

The fact is we had to prove this was possible and now that we have gotten over the initial push of it, I think performance has become something that is top of mind for everybody at the company.

Ethan:

As you guys have been evolving the design of this responsive framework across the different lines of business, has performance been a design consideration for you?

Tyler:

It certainly has. One of the first things that we wanted to do was make sure that we were designing and building with as many of the established best practices. For the core framework, performance has been top of mind and our team that manages that is constantly refactoring, making their code more performant. What we have seen too though is that how that is implemented is another big piece—how the UI is rendered on the page and what’s going on as users interact with the page is equally as important, and I think Scott alluded to it in the last segment. The fact is we had to prove this was possible and now that we have gotten over the initial push of it, I think performance has become something that is top of mind for everybody at the company.

When you show people something that’s alive, and if it’s a responsive problem that you’re solving, you can show it change just by dragging your browser—it feels much more live and real.

Karen:

How does the way that you review your work with the rest of the organization change? Do you conduct your design reviews differently? Do you get stakeholders from other lines of business involved in different ways?

Travis:

I’m not sure that the actual reviews have changed, but we have noticed—when you show people something that’s alive, and if it’s a responsive problem that you’re solving, you can show it change just by dragging your browser—it feels much more live and real. So, I think the way people view the work is a little bit different. It kind of nudges everybody forward in the process and gets them talking about the right things at the right time. So, we have seen that change.

Even putting a real live prototype in front of our executives at our monthly meetings can change the conversation.

Tyler:

The way that most of our teams work is just a really small and tight and informal team that has representation from UX product and engineering. Like Travis said, showing design work, showing prototypes really just gets everybody on the same page a whole lot quicker. Really, that’s how the decision-making happens, is in those small groups.

Travis:

I think some of the stuff that we’ve been able to do though is get to what something real looks like a lot faster, and then even putting a real live prototype in front of our executives at our monthly meetings can change the conversation. For instance, the flights team recently was talking about performance and getting listings to the page that somebody could interact with, so a flight listing to the page that somebody could interact with as fast as possible, and we were able to, in a very tight turnaround, show what that would look like and then get it in front of the CEO. It made their conversation about where they were going that much easier.

Having a centralized framework where you can solve these bigger and more ambiguous design and technology problems at the core and let the larger teams benefit from that work has been hugely beneficial for us.

Ethan:

Do you guys have any advice for other organizations that are starting to embark on a responsive redesign?

Tyler:

My advice would just be to vet the designs in the browser and on devices early and often. One of the things that we try to do at Expedia on a UX team is we, as designers, have the ability to show and not just tell, so that’s been hugely beneficial in the communication process.

We really tried to clearly define what success looked like for us. Through that process, we got a lot tighter in measuring behavioral metrics so that we could try to keep our fingers to the pulse of what people were doing on our live site.

I think having a centralized framework where you can solve these bigger and more ambiguous design and technology problems at the core and let the larger teams benefit from that work has been hugely beneficial for us, even though it did require some upfront effort in getting it off the ground. I don’t think we could be doing what we’re doing without that work.

Travis:

Yeah, and then just the experience from going through implementing something like the toolkit at the product level, we really tried to clearly define what success looked like for us. Through that process, we got a lot tighter in measuring behavioral metrics so that we could try to keep our fingers to the pulse of what people were doing on our live site. I think clearly understanding what success for an organization looks like and then measuring as much as you can to figure out how behavior has changed and come up with ideas about why that is, an adjustment that you might need to make. That was all really helpful for us in making the shift.

Tyler:

One of the things that we’ve learned as well over the past year or so from a framework perspective is we’ve got to engineer our architecture around flexibility and long term evolution. The scalability and the maintainability of our code is paramount, and making sure that we think about future states but also build in the flexibility to give us the leeway for the unknowns that come up.

Karen:

With that, I think that’s a perfectly good note on which to end this conversation. I really appreciate both of you taking the time to speak with us today. This has been an exciting couple of weeks hearing what Expedia has been up to and I look forward to seeing what you guys have next in store.

Tyler:

Thanks very much.

Travis:

Thank you so much for having us.

Ethan:

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

We’re really excited to announce that we’re offering public workshops on responsive design, taking place on March 06 in Boston, and on April 2-3 in New York City. If you’re interested in attending, visit responsivewebdesign.com and register for a ticket today!

And 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.