Episode Transcript

Karen:

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

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week, well, I’m just thrilled to let you know that we are here with Scott Jones and Jason Chandler from Expedia. Welcome.

Jason:

Thank you.

Scott:

Good to be here.

Karen:

How about we just start off by having you guys both introduce yourselves, tell us a little bit about what you do at Expedia. Scott, why don’t you start us off.

Scott:

Excellent. Yeah, my name is Scott Jones, I’m the VP of user experience design for Expedia Worldwide. That basically means I’m responsible for all of the web design and interaction work that we do across anything that is branded Expedia across the entire world.

Jason:

I’m Jason Chandler and I am the dev. manager for the client-side engineering team here at Expedia. It’s a crack team of front end developers working out of our headquarters in Bellevue, Washington, as well as the London office here where I am based.

Karen:

Fantastic. So, I am very intrigued to talk with you both today because I know that Expedia has been going through the process of rolling out some large scale and high profile responsive redesigns.

Ethan:

But before we dive in, I’d like to take a minute to mention our wonderful sponsor, Campaign Monitor. If you need an email newsletter you should absolutely check them out. Campaign Monitor features Canvas, which is their easy to use builder for creating wonderful email newsletters that look great everywhere, even on mobile devices. We’ve actually found here on the podcast that it’s very easy to create an email newsletter in just minutes. They have a great editor with some really decent drag and drop functionality, as well as some flexible, customizable starter designs that allow you to create these lovely looking emails that match your brand and your content. And the nice thing is, you don’t actually need a Campaign Monitor account to check out Canvas or their other offerings. You can actually just go to their website, campaignmonitor.com and start experimenting today. So thanks again, guys.

We have a big test-and-learn culture here at Expedia, and as long as you’ve got good observations, good hypothesis, and sound success criteria, you can try lots of things.

Karen:

Maybe we could start out by having both of you speak a little bit to how you made the decision to go responsive. Were there questions or concerns about that approach or that methodology?

Scott:

I’ll start the conversation. I think ultimately it wasn’t a big decision to try. We have a big test-and-learn culture here at Expedia, and as long as you’ve got good observations, good hypothesis, and sound success criteria, you can try lots of things.

What ended up really happening is the web design team, Jason’s client-side engineering team, we looked at how we were doing mobile and saw that as many organizations who kind of get caught by mobile and get a little flat-footed, they make up for that by stressing individual work to get it done. They splinter the mobile effort into apps work, mobile-optimized work, and then what my main area is, which is what we call core, which other people might have once upon a time called desktop, but it’s everything else, it’s the core experience. We looked at how work was being done and thought that, despite our best efforts, things weren’t rolling out as fast enough, we weren’t always having the right functionality.

If you look at even our early app efforts, whether it was initial itinerary-only apps or even our first serious app, where we released a beautiful, critically-acclaimed—Apple loved our first serious app—it only had hotels. All it takes is talking to a few users and a few other people and they say “Isn’t Expedia more than this? For God’s sakes, you have a plane in your logo. Where is everything else?” You’re putting all this energy into this core experience but it’s not making its way to the other experiences, and you couple that with the trends that everybody in this industry sees—the growth of mobile, the growth of tablet—and you look at our conversion and our traffic, and we’re not getting it, and the traffic we are getting we’re not converting on.

People said—surprisingly—”Okay, let’s go do it.” So, then that’s the hard part. Getting the okay was the easy part. Then it was up to us to actually execute.

Lucky for me, I have a crack team who likes to spend time reading articles by people like you two guys, and Luke [Wroblewski], and Brad Frost, and they say there’s got to be a better way to do this. So, they do what designers do: they started designing. Jason’s team started helping build out the framework and we built a proof of concept, and they came and showed me—”Hey, we can actually do this. We can do responsive design.” I said “Oh, I don’t think you guys understand. It’s going to take years for us to do this. But if you’ve got the wherewithal, we can try to make this happen.”

Lucky for us, literally a few weeks after the proof of concept, I was in a strategy session where we were talking from a business perspective about this challenge, about the graphs—everybody knows what a graph looks like, when it’s up and to the right then that’s good, and we looked into the traffic and we looked at our conversion and it was going the other direction. “What do we do about this?” I said “Alright guys, we’re going to pitch responsive design,” and people said—surprisingly—”Okay, let’s go do it.” So, then that’s the hard part. Getting the okay was the easy part. Then it was up to us to actually execute. That’s kind of how we got it going.

Apps are great for targeting loyal customers or customers who have very specific needs, where you want to provide that extra oomph, that extra value.

Ethan:

One question I’d love to hear you guys talk about a little bit is, obviously Expedia has a pretty wide-ranging digital ecosystem, you have this new responsive website, you also have a number of apps and you also have, interestingly, a standalone mobile website, I believe. How does responsive design fit into that larger equation?

Scott:

The best way to think about that is ultimately we’re looking for what is the best solution around effectiveness and efficiency and solving each of those pieces. I think what’s happened over the last few years while we’ve been going down this journey is really understanding what the role of each part of this system is. Ultimately, apps are great for targeting loyal customers or customers who have very specific needs, where you want to provide that extra oomph, that extra value.

What it showed was if you give people all the functionality and you work on focusing the experience to do everything that it needs to do for everybody, that’s going to probably play out and it’s probably going to win.

The mobile web, honestly we just started competing against it from a responsive perspective. To put that in context: we’re not competing against people, we’re competing against ideas. So, the mobilized web was what we got to first because that’s how we specialized, and that’s how we focused, and that’s how we got traction, moving from the old m-dot scraping technology that took up most of our mobile experience two or three years ago; optimized web was the fastest way to get traction there.

Responsive has been that going back and looking at the core experience, looking at what we do, and saying that we “put all of this energy into the core experience, so why is mobile not core?” I think as you think about it, responsive will be competing with optimized mobile web. Our first head-to-head contest was literally two or three months ago, and I think the analytical/technical term was “responsive kicked its butt.” Whether that’s because it was missing functionality, or all the content wasn’t there, or there was something about the design usability, those are the things we’re understanding. But from my perspective, what it showed was if you give people all the functionality and you work on focusing the experience to do everything that it needs to do for everybody, that’s going to probably play out and it’s probably going to win. That’s how we’ve evolved the strategy over the last few years.

The scalability and maintainability of a single code base has its challenges but I think the benefits are definitely there.

Jason:

I’d like to add that obviously from an engineering perspective, having separate code bases is probably not very scalable. We’re a global company, we have experiences that span the globe, and so if you just think about the technical challenge of scaling to meet all of those customers’ needs around the world, having multiple different experiences that have their own code bases becomes more and more difficult as time goes on.

I think that one of the true values to responsive design in general terms is that it sort of centralizes a lot of that. That’s really what this core group was focusing on, was “How do we centralize our efforts so that we can scale as the business needs grow and as we move from one national presence to another, and so on?” I really think that the scalability and maintainability of a single code base has its challenges but I think the benefits are definitely there.

I believe that people will do anything on any device if you give them the functionality and you make it easy enough.

Karen:

Let me follow up with sort of a related question, which is that when people talk about their mobile strategy, their digital ecosystem, one of the topics that tends to come up a lot is the difference that the organization makes of what a “desktop user” wants and what a mobile user wants. I don’t think I’m spoiling anything here if I say that as a general rule, I think most organizations put a little bit too much into the difference between desktop and mobile, and in many cases they’re better off just serving the same stuff to everybody. That said, there is one industry where there is a definite and specific mobile use case, and that is the travel industry. So, can you speak a little bit to what you think the difference is between a mobile and a desktop user, and how do you frame those discussions as you are planning out your strategy?

Scott:

That’s a great question and those are things that we talk about internally all the time. In fact, part of this journey we’ve taken over the last couple years is actually working through that. I subscribe to exactly the same theory that you have, which is I believe that people will do anything on any device if you give them the functionality and you make it easy enough. God knows I see what’s on Reddit every day and people do crazy stuff.

I also know that when it comes to travel and travel planning, people might have said once upon a time “I might book a car, but I’ll never book a flight,” or “I’ll never book a complete vacation package.” I’m pretty sure I can go to a restaurant almost every single day and I see people looking for reasons not to talk to their families, and if planning the family vacation is part of that, they’ll do it.

What we’ve discovered as we do a lot of our ethnography research, a lot of our lab studies, as we watch the mechanics of our sites from an analytics perspective: people make the same decisions regardless of the context.

So, our big examination, our big exploration over the last couple of years is really understanding that, and figuring that out, and what we’ve actually learned is while there are trends, there are definite enhancements—yes, if I’m mobile I tend to be more likely to be booking for today. But it’s not like it’s a majority. A majority of people on mobile are still booking out. Yes, if I’m using my itinerary, maybe I’m reviewing my travel plans before I go, maybe I’m accessing them real time, those are very specific ones.

But what we’ve discovered as we do a lot of our ethnography research, a lot of our lab studies, as we watch the mechanics of our sites from an analytics perspective: people make the same decisions regardless of the context. I think this is actually what the responsive strategy and the responsive thinking has done for the organization, to kind of open that up and not over-index on these unique cases. But understand how, if you have the right framework and the right foundation, you can then choose—if you’re smart, if you’re clever—how to enhance those. If you can be smart enough through defaults or Geo. But I would argue that, as we all know and you guys all know, I should be able to do some of that stuff from a “desktop site” too, depending on the right functionality and the right kind of computer.

I think once that opens up and once people see that, when I put on my business hat and I look at the balance between business want and real business need, and user want and real user need, and I try to find that middle ground and that happy spot in the middle, learning that allows businesses to make a much more educated decision about what’s worth investing in.

But while I do think travel has some specific things, we’ve learned that it’s more the same than it is different and we just have to be wise about how we solve it. The way the technology is progressing, it’s very hard, as everybody knows, to understand what’s really mobile and what’s not really mobile. It’s more about what you can do and how easy it is for you to do it.

We tried to stay away from saying “Well, this content is not important for mobile users or for tablet users.”

Ethan:

One thing I’d like to hear a little bit about, and maybe Jason you can weigh in here, is as you guys started doing that first responsive prototype, the first proof of concept, how did you make decisions about what to keep and what to get rid of? Was there some sort of content prioritization that you had to go through? How did you make decisions about what stayed and what went?

Jason:

So, obviously everything was formed in a hypothesis, we had hypotheses around basic decision priorities. We had made some hard proposals on certain things that needed to be removed or prioritized higher than others. And, of course as Scott alluded to, we have a very strong test-and-learn culture, so any decision that we needed to make that was difficult, we could actually test production traffic against it to see if it was the right decision.

From my perspective, we tried to stay away from saying “Well, this content is not important for mobile users or for tablet users” I think because in the very beginning of working on the proof of concept and some of the ideas, was because the idea was “If it’s useful for desktop, maybe it’s valuable for a mobile user.” Or if we started thinking about “Well, is this content necessary for someone using a tablet?” Well, we could ask the same question of “Shouldn’t we just remove it from the desktop experience as well?” So, we could test out those theories as well.

I also think that when we got to the point of rolling out, or before we even started on the roll-out, we put all of that knowledge and sense and direction and ideas within a centralized framework so we could start there. We could put our design thinking into this, we could say “Okay, here’s our hypotheses, here are the things that we want to accomplish. What are the things that we don’t have today that we should have?” I think that just in working really closely with our partners, it made a big difference in showing us what was out there, trying to understand what was already there, what features we had to meet with parity from the desktop experience as we expanded that thinking all the way down.

The stipulations I had were we could do no harm to desktop. No one said it had to be exactly the same, but we could do no harm. The challenge came to be “What does that really mean?” So, we chose to design mobile up but implement desktop down.

Scott:

I’ll add a little bit of extra color. As we implemented, we were very thoughtful—and I know that people have used the term of “Is this a responsive retrofit?” What I would say is we’re probably a little bit different. We designed mobile up, we used the best futuristic practices, but the big challenge—I got the big yes, to say “Yes, let’s go do responsive,” I got product owners who said “Yes, I want to do it. Can we do it in three months?” I had eager candidates wanting to do this. The stipulations I had were we could do no harm to desktop. No one said it had to be exactly the same, but we could do no harm. The challenge came to be “What does that really mean?” So, we chose to design mobile up but implement desktop down.

I knew we actually had to win not just from an efficiency perspective but from a performance perspective.

The other kind of caveat that came up as we went along, and it goes back to Ethan’s question about optimized web experience, as much as we wanted to ultimately use this to solve the problem, or thought we could solve the problem using this, the real gap was on tablet. So, we were also challenged with saying “Hey, before you worry about winning on the phone, let’s prove that you guys can win at the tablet.”

So, we had a two-pronged challenge—don’t do harm to the desktop and win at tablet. Well, anybody who knows anything about business math, it might be great to do no harm, but if you’re spending a lot of energy just to hit equality, that’s not a great story when you walk into the executive boardroom. So, I knew we actually had to win not just from an efficiency perspective but from a performance perspective.

The brilliance of the fact that we had done so much work on the desktop was that we knew what good looked like, we knew what we had to do. So, while we had some very critical decisions about if we could make these trade-offs, what we’ve actually learned over time by implementing it is there’s a lot less missing from the mobile site than we thought when we originally started. There’s a lot more content there because these decisions have to be made. It became more of an art of how do you provide the right scent through other pieces—navigation, elements of how to reveal content, because the decisions need to be made and the content needs to be made regardless of whether it’s a smartphone or the desktop. But luckily with the way we built the framework, we were able to actually prove that and it wasn’t just us hoping that we were right.

The way we went about it was teeing it up knowing that we could get the site live, we could start funneling, as Jason said, production traffic.

Karen:

One of the things that I find fascinating from all of the different companies that Ethan and I have talked to on this podcast, is that there’s so many different ways to approach how you roll out the responsive redesign. So Scott, as you mentioned, some people do just a straight retrofit where they just take everything exactly as-is and kind of make the front end responsive. Other organizations pick a specific section, sometimes even just a specific page to start with. And still others wind up doing a long-term beta process, where they essentially are running two different websites in parallel and using that to test and learn and gather feedback on eventually moving the responsive site over to take over everything. Can you talk about how those conversations happened within Expedia?

Scott:

Absolutely. It was critical to our success and it was critical to how we learned how to do this, because I’d be lying if I said we got it right perfectly as we rolled it out. What we planned on doing is not necessarily what we ended up doing.

From a business perspective, and a business protection perspective, which is something that I have to be very aware of, we were lucky enough that two of the big business units that wanted to try this were kind of at the opposite ends of the spectrum. I had the hotel business—which, to kind of almost repeat our app strategy—if you can’t make it work at hotels, it doesn’t matter. That’s where the bread-and-butter of the business is, is in hotels. But we also had the cars business, which not only is a simpler and smaller business, but also you could argue, or at least people believed, there was a sharper mobile use case. So, we actually got the luxury of running both of these in parallel, knowing that one was less risky than the other but knowing the other one was the one that really had to prove itself.

The way we went about it was teeing it up knowing that we could get the site live, we could start funneling, as Jason said, production traffic, and actually didn’t have to make the the decision of whether we were going to do a “long beta,” or a massively fast switch over, or let it just kind of figure itself out over time because by slowly releasing, and in fact all the functionality wasn’t really available to hotels when we started running traffic to it, we got to actually understand how close we were. That actually has become kind of our default strategy. While we had some missteps while we were doing it—flights almost had no problems—hotels took us awhile to make it work and to figure these pieces out.

The punchline of that is while our initial challenges with hotels and our original responsive design took a few months, and in the grand scheme of things it still was only a six month effort, we still did it very fast.

Through that, that’s actually become kind of our base strategy for how we roll out these other pages, whether they’re the home page, or they’re landing pages or they’re businesses that we haven’t fully gone to yet, like flights or packages, the idea is to build that stream. It’s almost classic iterative design. How do you get those pieces across? What’s the minimum functionality? Do you make changes to styles first? Do you bring the framework in to prove you’re not going to cause any damage to desktop first but yet lock the thing down so you can’t actually have the breakpoints, you can’t actually make it responsive? Let that compete, let that burn in. Make sure that you don’t have any change fatigue. Try to change as little as possible but it actually allows you to start moving faster.

The punchline of that is while our initial challenges with hotels and our original responsive design took a few months, and in the grand scheme of things it still was only a six month effort, we still did it very fast, but I think spent probably two or three months really trying to slog it through and work it out.

When finally decided not to just go from desktop to tablet but tablet to phone, which is what we did last quarter, that happened in an amazingly fast amount of time because everybody at that point knew the playbook. We knew how to get the traffic on there, we knew what patterns we needed to test, we had an acute understanding of what role each part of the view or the experience played, what part the visual played, what part the interaction played, what part the content played, so therefore we knew what was at risk and what wasn’t at risk. The challenge from tablet down to mobile was a matter of weeks versus the original slog from desktop to tablet which took about six months. I think that just shows that we’ve gotten better at this process and that, for us anyway, this is the way to get it done.

By focusing a lot of the efforts between engineering and UX on a central toolkit or a framework, it meant that we could actually front-load a lot of those challenges and hand them off to a smaller core team working really closely together.

Jason:

When we decided to start rolling this out, when we were planning out how we were going to roll it out, by focusing a lot of the efforts between engineering and UX on a central toolkit or a framework, it meant that we could actually front-load a lot of those challenges and hand them off to a smaller core team working really closely together on solving some of those problems and getting it to a point where it was ready to then be moved onto the first adopter to start doing some testing. But by moving everything into that centralized framework, it meant that whatever we learned from that experience could then be looped back into the toolkit and we could then apply that knowledge back to the next process.

So, if you can imagine, as we added more and more tests and as we migrated more and more of the pages and the paths, then the decision-making and some of the challenges started to be reduced over time. We had new challenges of course, but over time the overhead was reduced, so we could start to move faster. There was a lot of upload cost because we focused on the framework, but I think looking back, had we not done that, we would have had to recreate the exact same experience multiple times and that would have been a much slower process.

Ethan:

As more and more of Expedia’s website has been moving into this responsive framework, has that changed the way in which your team works together and collaborates internally? Have you found yourself hiring for different roles or organizing teams differently?

Once you see a prototype, once you see something being designed in code, people don’t go back to static Photoshop comps.

Scott:

Absolutely. It’s not like it’s a surprise. I think all of us know that our best work is done when design and engineering and product are all working very closely together and iterating as fast as possible.

Tactically, what this meant for me is in working with Jason’s team, and even working with stakeholders, is once you see a prototype, once you see something being designed in code, people don’t go back to static Photoshop comps, they’re not satisfied, and that doesn’t matter whether they’re me as I’m judging design solutions, or it’s my boss, or it’s the head of Expedia. Once you get spoiled and you understand and people start saying “What is this going to work like on the phone? What is it going to work like on the tablet? How is this really going to work? What’s it going to really look like?” You don’t get to go back to static.

I’ve actually started hiring people who are specifically prototypers so that we can kind of run the gamut based on the demands of the specific project. It has definitely changed how we work.

So, the punchline has been I either have to turn my designers into coders or start hiring coders, and we’ve done a little bit of both. We get more and more of our designers to be very acute and knowledgeable about code. We have some who are very comfortable designing in code. The framework is built to where if you’re not comfortable doing code, you can at least know how to use the pieces. Then I’ve actually started hiring people who are specifically prototypers so that we can kind of run the gamut based on the demands of the specific project. It has definitely changed how we work. Of course, the side effect has been that Jason’s team and my team have to spend a ton of time together because we’re the ones that started this mess and so we’re stuck with each other.

Some of the concepts of responsive are quite complex, and so having a group of people come into the room, what we don’t want is basically a hit-and-miss where no one can speak the same language, because that really kills productivity.

Jason:

Copious amounts of time. When I hire new developers, I try to find developers who have either come from a design background of some kind or have an understanding of some of the concepts because I find that that also helps, working as closely as my group does with Scott Jones’ group. I think it really helps so that everyone is on the same level playing field in terms of vernacular.

Some of the concepts of responsive are quite complex, and so having a group of people come into the room, what we don’t want is basically a hit-and-miss where no one can speak the same language, because that really kills productivity. So, in order for this to work, it really required really close integration between our two groups. Like Scott said, we did cover the engineering, we covered the design, and we also included aspects of the business and the product.

It’s much simpler to send a URL and have somebody bring it up on their phone or bring it up on their desktop and just have them look. Even the feedback cycles start happening faster.

Karen:

I’m very curious to hear a little bit more about how you managed the stakeholder review process. I love what you’re saying about how the prototype really gets people excited. What else had to change? What was different in how you showed work in progress to your team members? And one specific follow up: I know Expedia has a really focused test-and-learn culture, and I’d love to hear how you may have incorporated A/B testing or other forms of testing into that review and approval process.

Scott:

That’s the thing that’s still very much in play and very much in trial. For the first part of the question: in managing stakeholders, it was something that sort of happened over time. It wasn’t like a big shift in “This is how we’re going to present.” Now, obviously it started with discipline on our side. With my design leadership, am I seeing that true mobile up, that true responsive thinking? What’s the easiest way to show that? What’s the fastest way to show that? Well, let’s get it into prototype, let’s get it into live code. Then once you have those assets, you naturally start showing them to the stakeholders. It’s much simpler to send a URL and have somebody bring it up on their phone or bring it up on their desktop and just have them look. Even the feedback cycles start happening faster. The natural side effect is nobody wants to go back. It’s not a matter of a mandate—they just don’t. You can’t have the same conversations if you’re not doing it.

You now have to shift your thinking to say “How do I solve this problem across a bigger scope?” So, it adds complexity. But once people’s minds start going there, I’ve found that it becomes very easy for them to understand.

As far as the test-and-learn piece of it, I think that’s the biggest change in mentality and I think that’s actually why showing designs, at least in prototype form, and when possible in code form—because we’re designers, you can talk about this stuff all you want to, our job is to show, our job is to communicate through doing.

The quickest way to change a business owner’s mind or the quickest way to help understand with maybe the deep back end of engineering of why you really need something to work this way is to literally show them. That changes the mentality even from a test-and-learn perspective because now we’re no longer solving for how every piece of pixel has to be optimized. You now have to shift your thinking to say “How do I solve this problem across a bigger scope?” So, it adds complexity. But once people’s minds start going there, I’ve found that it becomes very easy for them to understand, not because we told them they had to but because they’re now seeing it across these pieces and it’s no longer good enough for them. That’s the best thing you can ever do from a business perspective, or a product perspective, or an engineering perspective, or a design perspective, is when you look at it across these pieces naturally, are you sure this is how it’s supposed to work?

New projects have definitely gotten faster. I think the first roll out took nearly a year, and then since then, we’re talking a couple of months or a few weeks, depending on the scope of the project.

The good thing about the test-and-learn rigor that we have is that everybody believes in the math, they believe in proving the business value. Now, instead of looking at it only at “desktop” and only at forty, fifty, sixty percent of your traffic, now you’re actually looking at it at one hundred percent of your traffic. Then a lot of those concerns that may have popped up early about how responsive is too heavy or that it takes too much time, those things start to go away when you say “Yeah, I understand we might have spent maybe a third, maybe half as much more time than we would have otherwise” but now you’re hitting one hundred percent of your audience, and it’s outperforming what you were doing before, so it doesn’t take long for people to get on board. As with any process, if you step and you repeat, you make that cycle faster, even those times I’ve found have gotten shorter and shorter.

Jason:

Yeah, definitely. New projects have definitely gotten faster. I think the first roll out took nearly a year, and then since then, we’re talking a couple of months or a few weeks, depending on the scope of the project. I think the conversations have also changed as well because we are actually testing these things. Once you test it and once you prove that it works, because you it’s centrally located you can rinse, repeat and you know you’re going to get the same value from one project to another.

The ability to test and improve and understand that you’re not just solving for this piece of the experience but you’re trying to find those patterns of how it works across—that was the key for us being able to move fast, the key for us being able to make this work at scale and at our complexity. You have to start there.

Ethan:

Here’s a question for both of you guys as we come to the end of our time: I’d love to hear if both of you have advice for other organizations who are just starting to embark on a responsive redesign.

Scott:

I think that I can’t stress enough that when Jason talks about the framework and about the patterns, because we did that work early, from an engineering perspective, from a design perspective, and we started building these units—atomic units and these larger macro units—as teams get comfortable that it’s working, the ability to step and repeat, the ability to test and improve and understand that you’re not just solving for this piece of the experience but you’re trying to find those patterns of how it works across—that was the key for us being able to move fast, the key for us being able to make this work at scale and at our complexity. You have to start there.

The other piece is you have to be very clear about what success looks like. I don’t know that success will look the same for every company for what the purpose of responsive is. For ours, it became very clear, we knew exactly what the metrics were, and because the team did the homework of doing the framework elements and getting that proven out at the initial stage, we’ve been able to accelerate and make this work. I don’t know how we would have done it if we hadn’t done it that way.

Plan it out not for the short term fix, not for the immediate problems, but for the long term evolution and flexibility of scale, because the web is not static.

Jason:

On top of that, I would also like to say that my experience with the stakeholder conversations and garnering support really comes down to partnerships. If you build those relationships early and across disciplines, then you’ll have these partners to rally support around challenges later on. Without those, I found that early on we spent a lot of time convincing before we actually had enough going on. But if you work towards having all of these partnerships, then when you go to the business and you have a difficult proposition, like “This is going to take X amount of time,” you have a lot more support across disciplines and across different parts of the business, and I believe that the conversation gets a little easier.

From an engineering perspective, I would say early on spend that time to plan out your architecture. Plan it out not for the short term fix, not for the immediate problems, but for the long term evolution and flexibility of scale, because the web is not static and if you build an architecture, it will never be static. You may make a lot of decisions early on and then have to change them early on, so ensuring that you’re also fluid and that you allow change to sort of guide how you maintain and how you continue that trajectory is also quite helpful.

Scott:

At the end of the day, we make stuff. The faster you make stuff, the faster you get evidence that it’s working. People get on board really quickly and I think, as designers, that’s what we do. So, my advice is do it and do it as fast as you can.

Karen:

Well, that is fantastic advice. This has been an astonishingly great episode. And if you enjoyed this episode, come back next week for part two of our conversation with Expedia, where we dive into more of the specific design and development challenges that they faced. So, Scott, Jason, thank you so much for being here today. This has been amazing.

Jason:

Thanks for having us.

Scott:

It was an honor. Thanks a lot.

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.