Chances are you’ve used OpenTable to find a place to eat and then make reservations. Besides seating more than 17 million diners every month, OpenTable serves over 32,000 restaurants globally with reservation management software. We’re thrilled to have them as part of the InVision community.
We spoke with Thomas Stovicek, Head of Design, and Brooks Hassig, Senior Experience Designer, about viewing your coworkers as partners, designing for 2 very different user bases, and the importance of collaboration.
How’s the design team set up at OpenTable?
Tom: Our design team includes product design, user research, marketing design, and brand design. It’s a big group, and we have to purview into a lot of different areas while still working collaboratively.
With product design specifically, we break up the design team into different domains in order to handle our 2 very different user bases, which are:
- Diners, who search for a place to eat and then make a reservation
- Restaurants, who accept those reservations, capture notes from guests, run reports, interact with people during dinner, and more operational things
Within those domains, we have smaller teams of designers who work on the mobile app or website depending on their skillset.
Why did you end up setting it up this way instead of having just one giant team working on both?
Tom: What the users are trying to do and what the restaurants are trying to do are 2 completely different things.
We can use a lot of techniques to evolve the design and the product, but that’s a user mindset. There’s a slightly a different business behind that, like trying to get people to book tables better.
“We pay close attention to what motivates our users.”
The restaurant side is so different: restaurant owners and managers use our software 6 to 8 hours a day. They wake up and check on reservations for that evening. When they get to the restaurant, they’ll double-check the reservations. Throughout the day, they’re constantly revising all of the data, seating people, taking phone calls, and getting more reservations.
There are thousands of restaurants using OpenTable as opposed to millions of people who use it to find a place to eat and book a table. So the techniques we use to talk to these 2 groups are very different—we pay close attention to what motivates our users.
Do the 2 teams use a waterfall or agile structure?
Tom: More of an agile structure. We try to create project teams where designers, engineers, and product managers work closely together to iterate, go out and talk to customers together, and design together in the early phases of a project. As the engineers work, designers stay involved and help tweak things—it’s a very agile, collaborative environment.
I feel like I’m part of one design team, even though I sit with my product partners rather than all the designers. It’s more important for me to be with my iOS and Android engineers and my PMs. Still, I sit next to the designers who are working on the same thing with me in a little pod, so it’s easy to collaborate with them.
We don’t just stay in our pods—we eat lunch together often and frequently hold meetings as a large design organization.
Brooks: Technically, I think we have 5 teams within the design team: restaurant, diner, research, brand, and UI writing.
Tom: We all come together at regular intervals. We have off-sites together, and we talk about process together. And on the day-to-day we pull in partners from other areas to help brainstorm and review project work.
Tom: While we have larger all-design team meetings, the consumer designers also meet and sync up. I might be doing something on mobile that might affect something on web, and vice-versa. We might share backends and components so that even if I’m working on a different platform, I still understand the use case for what the web designer is doing. Because of that, I’m able to give good feedback.
This becomes more of a challenge when you’re trying to get a feedback towards the restaurant team, and vice-versa. There can still be some good work there, but I don’t meet with them regularly in the same way that I meet with my consumer designers.
Do you find that you iterate and release more often on mobile, and is that tough to sync up?
Tom: We release on web more often because we have a more robust A/B testing platform—and you don’t have to wait for Apple to approve the release and get it out there. Functionally, we’re releasing a lot more web-based products than Apple products. From a design point of view, we’re iterating, and the team comes together at that level to review the things that need to be consistent.
The design team’s great at thinking about what’s important to have consistent across platforms versus what can be different between the different platforms. That’s a constant discussion.
“It’s important to communicate and collaborate to make sure it all comes out well.”
Brooks: An example: I work on mobile payments—I’m a sub team of my own, a one-man team. The nature of my project is that I actually plug into everyone else’s work. So, let’s say we want to work on a new payments feature that’s not just iPhone or Android. We’ll need to start thinking about whether we can set this up on the web and start reviewing things with the web team. The restaurant team might plug into this, so we may talk to them as well.
Each feature has its own considerations, but the point is that each little platform doesn’t operate in a bubble. It’s important to communicate and collaborate to make sure that it all comes out well.
What’s the design culture like at OpenTable?
Tom: We’re trying to cultivate a highly collaborative, open design culture here. It’s about involving as many people as possible in the entire process.
We have a weekly session where we share work from the other teams so that people know what’s going on in other areas and can go talk to that person if they either have ideas or questions as it relates to something that they’re doing.
“Thinking about my coworkers as partners has totally changed the way I work.”
We also do “Design Drinks,” a late-in-the-day working session with beverages where we brainstorm ideas as a group—we include the marketing, sales, and support people so we can hear all kinds of ideas outside of the general product organization. Many people here have a background in the restaurant industry, so it’s great to tap into their knowledge.
Brooks: The idea of partnerships has been a big thing for me here. It’s the idea that there isn’t a project owner, there are partners. Thinking about my coworkers as partners has totally changed the way I work.
Working as partners means you need to be open, you need to share, and you need to come to a consensus. Everyone has their own specialities, but it’s up to us to come to conclusions together because there isn’t just one person in charge.
My mission is to deliver a great product, and if I don’t involve the right people early on, there’s going to be some screw-ups and surprises later. It just makes sense to collaborate with the right people in order to achieve your goals.
Tom: OpenTable’s had a design team for a little over 2 years. Before that, there were no in-house designers. We’ve slowly built out the design team—there were 3 designers when I joined, and now there’s a multidisciplinary team of 24.
Our culture likely developed into what it is now thanks to how interested the various teams were in working with designers in a collaborative way. Collaboration produces a better work environment and better products.
“Collaboration produces a better work environment and better products.”
If you were interviewing and you had one candidate who had tons of experience and an impressive skillset, and then you had another candidate who had less skill and experience but would be a great fit for your culture, which direction would you go?
Brooks: My personal answer: you can’t teach culture, but you can teach skills. If I sensed raw talent, I’d lean towards the culture fit who was willing to learn more and work hard.
What do you think is the most powerful part of your design process?
Brooks: Collaboration. I know I’m doing my job when I’ve spent a lot of my day away from my desk. Sure, I eventually need to sit down and design something, but that’s the last part of it. It’s important to accept that you don’t have all the answers. You get powerful results by talking with developers and PMs, and going out to talk to users.
Tom: It’s about sharing knowledge—it makes better products and better designers. If designers worked by themselves, they wouldn’t learn anything from each other.
What does a typical day on the design team look like?
Brooks: My day is a good mix of working at my desk and going to various meetings: sharing sessions, discussions about direction and concepts, working sessions, and team meetings. Every other day, we meet for a team sync or product planning meeting.
The designers usually all eat lunch together, which is great for communication. While my mornings are typically for catching up, my afternoons are all about banging out work.
Can you run me through your design process from idea all the way through launch?
Tom: It depends on the complexity of the feature, but we abstract the idea down to a triple-diamond model:
- Learn
- Define
- Refine
In the learn phase, we find out more about the problem, maybe by going out and talking to users, and then distilling all that knowledge down into a statement or definition about what needs to be done. Our research team helps the design and product teams do some of that learning, whether it’s quick or it’s more strategic.
The define phase comes next, and that’s where we actually design the thing—we explore different solutions and review them with our partners in order to come up with a solution that best meets the needs of our businesses and our users.
“Users won’t give you the benefit of the doubt. You have to go all the way for them.”
We want to get to a point where our team’s comfortable enough to start building—or we may scrap the whole idea if everyone thinks it’s no good. There may be user testing and prototyping involved.
Once a decision’s been made, the engineering teams start building while working closely with the designer to sort out any issues that come up.
When you build something, there’s inevitably going to be things that need to be changed—and you can work through those. It’s important to look at your work on different devices to double-check that things are working properly.
It sounds like you have usability testing and user research baked right into your design process.
Tom: We also try to do a mix of qualitative and quantitative research. In addition to all the user testing and user research we’re doing, which is the qualitative side of things, we do A/B testing and analysis of usage. We’re trying marry both the qualitative and quantitative when we’re making product and design decisions.
How do you handle design handoffs?
Brooks: It’s up to each team to work with their partners in a way that makes the most sense for everybody. Some teams use Trello, and the mobile team uses JIRA.
Tom: There’s typically some level of documentation for the flow, interaction, and the UI spec. It’s always great for the immediate team to move quickly, but some of the projects have implications for other partner teams. We try to be diligent about the level of documentation just in case another team needs to pick it up or a designer from another area needs to learn about something.
Brooks: We have a well-organized Dropbox. If I need to find a file from another team, I can typically find it without asking them.
Do you have a formal wireframing process for new products and features?
Brooks: There’s a different flow for each problem. With smaller things, the designer will skip wireframing and just do final comps. From there, they’ll sit down with their partner to work through different situations, and the feature will get built out.
“Do the pencils before the pixels.”
My mantra is: do the pencils before the pixels. Computers lock you in. I’ll always draw on either an 11×7 or a dot-grid notebook just to get my idea on paper so I don’t lose it, and if I know what I’m doing I’ll just go straight for the visual design.
How do you identify and prioritize feature requests?
Tom: At the end of the day, it’s really up to the working group—the product manager, designer, and developer—to get together, discuss things, and determine a plan of action.
How do you use InVision during your design process?
Brooks: I use InVision for testing, rapid iteration, communication, and sanity checks about whether a flow feels right or if something makes sense. I’ll use it if I just want to go to the café next door and have users click through what they think is an app.
I went to Dreamforce a couple of weeks ago, and I put together an InVision prototype on the ferry ride there and then tested it with users when I arrived. I took their feedback, made changes, and re-uploaded it through InVision. I did that 3 times in 2-and-a-half hours, and it gave me a tremendous amount of information.
“I use InVision for testing, rapid iteration, communication, and sanity checks.”
My PM loves leaving comments on our projects in InVision. I can use those comments as a working document and go through each one like a to-do list, so that I can make the change and mark it as result.
Do you have any best practices you can share about designing a product that reimagines a very specific user experience?
Tom: The idea of using an app to pay for your dinner started to creep up in different areas, and it was something we wanted to explore. Instead of taking the most obvious path, we went out and talked to users to find out what was important to them and what wasn’t.
“You can’t cut corners, you can’t guess—you just have to do really good UX.”
You have to go out and learn. You have to be open to seeing what the actual problem is—you’re going to find something you weren’t expecting.
What it’s like designing for a relatively tech-phobic audience on the customer side and on the backside?
Tom: Our biggest challenge was reimagining the restaurant product, both technically and from a design point of view. Tech-phobic audiences are used to doing things a certain way, but I think we’ve gotten to a place where it’s much more evident that the improvements to usability and ease of learning as well as some other visual changes that we did have much more successful, long-term impact to our business and their business.
We’re diligent about our design patterns now—it makes it easier for new people to learn the software.
Brooks: You have to be really good at your job if you’re designing for folks who aren’t very tech-savvy. You can’t cut corners, you can’t guess—you just have to do really good UX.
Users won’t give you the benefit of the doubt. You have to go all the way for them.
“Users won’t give you the benefit of the doubt. You have to go all the way for them.”
“Collaboration produces a better work environment and better products.”
Photos by Peter Prato.
UX and Content Strategist at InVision and UX Blogger at UserExperienceRocks.com. Fan of: my daughter, photography, writing, and beautiful usable things.
