Episode Transcript

Karen:

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

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week… Well, this has been a long time coming, and I’m really excited to introduce Tom Stovicek from OpenTable. Welcome!

Tom:

Hello.

Karen:

So Tom, why don’t you start us off by introducing yourself. Tell us a little bit about what you do at OpenTable and why you’ve come on the show today.

Tom:

Of course, I’m happy to. My name is Tom Stovicek. I’m the head of design at OpenTable, and I lead the design discipline here, and that’s across the product, UX, and brand experience design.

It became evident that we needed an easier way of developing, and that led us down a responsive path through most of the platforms.

Karen:

I’d love to hear a little bit about your design, or the decision at OpenTable, to go responsive. Were there broader questions or difficult discussions about the methodology?

I know one of the conversations that we had leading up to this podcast was that you have a hybrid strategy, where some sections of the site are responsive and then you still are maintaining an m-dot. So, maybe you could talk a little bit about how that fed into your overall strategic discussions.

Tom:

Sure thing. So, when we started having discussions about where we wanted to go and how we could improve the experience, it was evident that we wanted to serve our customers in the best way, and make things available on multiple platforms and multiple device types. So, from our old site to our new site, it became evident that we needed an easier way of developing, and that led us down a responsive path through most of the platforms. It was a large undertaking for us, but it was pretty evident that we needed to go down that route.

For the main website those use cases are a little bit different on mobile versus desktop, and so we needed to optimize the experiences that people have on those different platforms.

It is true that, for the mobile platform, we do have an m-dot that we maintain for certain parts of the website. And so the ones that are content-centric, that don’t necessarily change in terms of use cases for the users, we use fully responsive when we can do that. But for the main website—and OpenTable is a booking system for people who are looking for great dining experiences—those use cases are a little bit different on mobile versus desktop, and so we needed to optimize the experiences that people have on those different platforms.

While it’s true that a lot of the information that people are looking for in order to make their decisions are similar, how they’re using the different devices are slightly different.

Ethan:

Tom, I’d love to hear a little bit more about what those use cases actually were. I mean, Karen and I speak to a number of organizations, and we ask them about how they think about the needs of the mobile user versus the needs of the desktop user, and many organizations actually think that, more or less, they need to complete the same transactions, they’re looking for the same features and functionality. It sounds like OpenTable might’ve arrived at a slightly different result. Could you tell us a little bit more about that?

Tom:

Absolutely. So, what we’ve learned through talking to our users and running the analytics that we have is that there are slightly different use cases, and while it’s true that a lot of the information that people are looking for in order to make their decisions are similar, how they’re using the different devices are slightly different.

For mobile, which is a very large and important part of our business, people are booking on the fly and making more immediate reservations. Whereas on the desktop, they sometimes take a little bit longer to make their decision, and they’re sort of making their plan or their reservation booking a little bit more in advance, so they’re taking their time to pick the right occasion or the right place for a specific dining event.

And so, because those two use cases are slightly different, we want to present to our users a slightly different focus, even though a lot of the information might be similar.

We rolled it out to a small percentage first in order to make sure that it was working properly before we rolled it out more broadly and globally.

Karen:

Can you talk to me about how you made those decisions about how to prioritize what you were going to make responsive and what you weren’t? And how did you roll out the responsive redesign? Did you do it all at once? Did you do it piece by piece?

Tom:

The responsive rollout was… We wanted to make sure that we were building the right experiences for people, and for us, it was a really big change. I don’t know how many of you remember the old site versus the new site, but the old site—

Karen:

I use it all the time.

Tom:

All the time, right. But it was very different from the new site. And the new site, to do it we brought on a design team in-house that had been working on it for a while, and it was a really big change for us.

So, we wanted to roll it out in one sort of big reveal because the experiences were so different. In order to do that, we rolled it out to a small percentage first in order to make sure that it was working properly before we rolled it out more broadly and globally. So, we had to stagger that a little bit.

In terms of what we did in order to prioritize the use cases, we had done a lot of analysis on how people use the old site, and how people were using our mobile platforms that we had up until that point, and that was some data analytics as well as qualitative research that we did in talking to users to understand how they were using it, and we usually used both of those methods in order to make product decisions.

When we’re designing a feature or an experience, we do some initial concepting on one of the platforms that make the most sense, and then we expand it to the other platforms to make sure that it’s working appropriately.

Ethan:

Tom, tell me a little bit about the design process at OpenTable. I’d be really curious to hear that as you and your teams have been doing more multi-device work, has the way in which you think about designing visual frameworks changed significantly?

Tom:

Well, for the design team, it hasn’t changed that much because, as a team, we’ve been here as long as we’ve been working on the new platform update, and so we developed our processes from the beginning to accommodate a responsive design on multiple platforms.

Some of the features might only be available on one platform, at least for that release, and so we optimize for that.

And so the way that we do that is, ensuring before we start, that we understand the difference between the different platforms technically, as well as what we know about the use cases for each of those different platforms.

Then when we’re designing a feature or an experience, we do some initial concepting on one of the platforms that make the most sense, and then we expand it to the other platforms to make sure that it’s working appropriately. And some of the features might only be available on one platform, at least for that release, and so we optimize for that.

Our philosophy is to use the fastest, quickest way to communicate a design idea to get it out there.

Ethan:

Oh, that’s interesting. Tell me a little bit about the applications and tools you use internally to sort of talk about how some of those changes across platforms might need to be communicated. Are you still using Photoshop comps, or are you still doing more prototyping in HTML and CSS? I’d love to hear a little bit more about the detail work.

Tom:

Sure. I mean, our philosophy is to use the fastest, quickest way to communicate a design idea to get it out there, talking to our partners and product management and development so that we get answers quickly and we iterate very fast. So, yes, some of the things are still either Illustrator or Photoshop comps and wireframes. Sometimes we do HTML/CSS prototypes, or some of the designers are actually using Framer to model animations and those sorts of things. So, we use a bunch of different tools.

But it really goes down to what is the question we’re asking, and what are we trying to prototype? Because some of the smaller features or elements only require a sort of Photoshop comp to understand the layout differences, but when it’s more of a flow or an experience, we try to make a prototype, which might be in HTML/CSS, but it might also just be in something like inVision, that gets the idea of the sequence across.

In a way we had to change those processes and make it much more collaborative.

Karen:

Has adapting to that new way of working, adopting new tools, has that changed the way your team collaborates? Ethan and I have talked to some organizations that say that they have had to restructure the way that designers or developers work or sit together; they’ve sometimes had to hire different types of people or even create new roles so that they can create a new, more collaborative, iterative prototyping model. Has that changed for you?

Tom:

Well, what I alluded to earlier was that we grew the in-house design team over the last few years, and this redesign was one of the larger projects that we started with. And so as we were doing that, we were also changing the processes within the organization in order to accommodate that. So yes, in a way we had to change those processes and make it much more collaborative.

So, within the design team, we were building processes so that we were reviewing between the different designers; and so knowing what’s happening across the design team and across that different product lines so that we have some sort of consistency in the system, and the language, and the branding elements that we use. But also how we work with development and product management—making sure that they get to review the experiences that we create and in an iterative way.

There are times when the designers will sit with the design team to iterate ideas until we have a number of directions that we want to go with. We choose the best way to prototype or communicate that to the product and development teams, and then they’ll work with those teams in order to make sure that things are meeting the needs and requirements that we’ve defined, and meeting the technical constraints that inevitably come with developing software and developing on multiple platforms.

Because we were doing a large redesign that basically changed every aspect of the experience, we were making sure that we were reviewing the flow holistically.

Karen:

Did it change the way that you review the work with the rest of the organization? Like, did you have to engage your product management team or other executive stakeholders in new ways to get them to review prototypes or look at the experience in context on a device?

Tom:

I wasn’t necessarily involved in some of that in the early phases, but I believe that people were looking at things in context already. I think what changed was looking at things broadly. Because we were doing a large redesign that basically changed every aspect of the experience, we were making sure that we were reviewing the flow holistically, or a feature across a number of pages. So, we had to involve a few more people in some of the reviews to make sure that we were meeting not just the needs or goals of that one feature or experience, but across the system.

As we rolled out the redesign, we continued to do usability testing on that site and analyzing the data that came through and how people are using it.

Ethan:

Tom, I’d love to hear a little bit about what you’ve learned from some of your assumptions now that your site has launched. Now that you have this responsive experience sitting side by side with the mobile one, have there been any aspects of the design that you’ve reworked since it went live? And if so, what were some of the drivers for that?

Tom:

There absolutely were some things that we’ve reworked. One of the big goals was not only to do the redesign from the user experience point of view, or a brand point of view, but from a technical point of view. And so it gave us the capability to iterate much more quickly and rapidly than we ever did before. And so as we rolled out the redesign, we continued to do usability testing on that site and analyzing the data that came through and how people are using it, and analyzing flows and what people are clicking on and those sorts of things, and then gathering feedback through other mechanisms. All of that sort of flows into improvements that we’re going to constantly make on the website.

So, there’s a number of optimizations that we have made currently, or up until this point, and that we will continue to make, and that’s sort of our plan going forward for large parts of the site, is to continuously optimize what we’re doing, and we can do that quickly now.

Karen:

You’ve mentioned several times getting insights about the different scenarios of use. Can you talk about the type of user research and usability testing that you’ve done to understand how people are using different devices in context?

The other type of user testing that we do is much more generative, or evaluative, where we go out and talk to people more in context.

Tom:

Absolutely. So, we have, within our design team, a group of researchers that focus on these kinds of things across our product lines, and we use a number of techniques.

The usability testing, when we have a much more detailed idea around what we want to do, or we have a prototype, or even testing an existing site, we’ll bring people in and do specific usability testing on certain flows or certain experiences that we have questions around—or that we’ve identified through some of the data analytics as problem areas, we’ll do the user testing to get another perspective on those problem areas so that we can define better solutions and experiment on that.

The other type of user testing that we do is much more generative, or evaluative, where we go out and talk to people more in context to understand higher level needs and goals and make sure that our products are meeting what our users are trying to do when they try to find great dining experiences.

I know that it’s been easier for us to develop certain aspects of the site; because it’s responsive, developing a new feature or updating a new flow gets applied across more browsers and platforms at once.

Ethan:

The other side of that: I’d be more interested to hear about how OpenTable’s QA process looks now that you’re maintaining a responsive site. I know a lot of organizations actually struggle with moving past this old idea of browsers matrices and “here are the desktop browsers we support” into the wild world of mobile, where things are a little bit more unmanageable. How do you actually test and support this responsive design on different devices and browsers?

Tom:

I might not have the full purview into everything that happens on that side, so I will tell you what I do know. I know that it’s been easier for us to develop certain aspects of the site; because it’s responsive, developing a new feature or updating a new flow gets applied across more browsers and platforms at once. So, it’s actually, I think, made some of the QA easier in that we can test it all at once across the different platforms and devices that we’re looking at for that feature set.

From a front-end code point of view, I think doing polish or UX QA that we’ve built into our processes now to make sure things are tightened up and looking as good as they can—we also roll that into the process. We still look at it across the different devices to make sure that it’s working right, but we’re able to do so more quickly because we build once and it works more appropriately across different platforms.

We didn’t just change the front-end, we changed some of what’s happening on the back-end, and we implemented more analytics and more data.

Karen:

Has the way you measure success or evaluate the success of this product changed with responsive? Are you looking at your analytics differently, or tracking different behaviors now that you’re evaluating how the performance of the site works across different devices?

Tom:

Continuous evaluation is really important for us, and as part of the redesign, we didn’t just change the front-end, we changed some of what’s happening on the back-end, and we implemented more analytics and more data. We’ve changed the way that we do that because we’re doing more of it, and we’re able to cut the data in different ways and understand how people are flowing through the site across different platforms or different cases much better, and so we can be better informed for how people are using it so we can make better decisions for the future.

Building that team culture is very important for these kinds of responsive sites and projects in general nowadays.

Ethan:

Well Tom, now that you have this device agnostic—this really, frankly, beautiful responsive site up and running, do you have any advice that you’d like to share with any organizations who might be listening to this podcast who are just about to embark on a responsive redesign? What have you learned during the course of this that you’d like to share with our listeners?

Tom:

So, there’s two main points of advice that I would give to people, and that’s making sure that the process between the product managers, developers, and designers is in place and it makes them be as collaborative as they can be, because I think building that team culture is very important for these kinds of responsive sites and projects in general nowadays.

The other would be to prototype early and often, because that’s one of the biggest changes, I think, from the old way of doing things, that is important; and being able to see the site on different platforms as early as possible to understand how you need to modify the design to accommodate the different touchpoints that the user will have.

Karen:

Well Tom, thank you so much for coming to talk to us today about the great work that you’ve been doing at OpenTable. I can say personally that I use the site all the time, and I was really excited when I saw the redesign. Both Ethan and I were like, “We’ve got to get these guys on the show!” So, we really appreciate it.

Tom:

And thank you for having me. It was great to talking to you, and it’s great to hear that you guys are fans of the service. I enjoy it myself very often.

Ethan:

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

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. 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.