OpenTable Case Study
OpenTable is the all-in-one platform for dining out at restaurants, allowing users to browse menus, photos, reviews and even book reservations easily through the site. As a large player in the restaurant industry, OpenTable is committed to providing users with accessible dining options for everyone.
5 weeks
The identified issue is the lack of connection with other users of OpenTable's app. This is leading to a lack trust in restaurant reviews, as users would like the option to view reviews from known sources such as friends and family. From a business prospective, solving this issue will lead to increased bookings on the app by allowing users the ability to share their dining experience with other users.
Ultimately there were three key features my design partner and I decided to add that meets the frustrations of the users and the goals of OpenTable. First, was a friend map, that allowed the users to see where friends had been dining on a local map, and a link to both the restaurant page and their review. Second, was a feed that included all the activity of friends within the app. Third was a filter included on the review page of a restaurant to only see friends reviews. This combination gave users a way to trust in booking reservations because of the source of the reviews provided (both by searching indirectly for restaurants or directly looking at restaurants where a fried has been). By increasing this trust, it will lead to a higher amount of reservations within the app.
First, my design partner and I took the current review flow of OpenTable's app, and went through each screen, highlighting any pain points or wow moments throughout the experience. This was important to do to have a true understanding of the base line of the process as it stands currently, and what we could potentially improve on.
This process allowed me to understand the process of navigating the app from new eyes, and what did and didn’t work in a user’s perspective. It seemed like there was a lot of information that was trying to be conveyed too early, which can lead to the user being a bit confused. There needs to be a balance of amount of information provided and what the user needed to see.
Primary Frustration
When deciding on reserving at a restaurant, users are not invested in the reviews currently given to them which results in a lack of trust in them leading to lower bookings.
Secondary Frustration
When searching for restaurants to eat at, users are overwhelmed by the amount of options initially presented to them which results in a lack of a clear path to find and reserve a table with confidence.
Our next step was looking at direct and indirect competitors using the SWCDUO method of evaluation. There are many ways to be able to display information easily for users to understand, the direction a user takes on the app should be what dictates the design and not the other way where the design forces what the user does. That could hinder the user from meeting their goals.
Doing the benchmarking allowed me to better understand the market and how it typically presents information to audiences who are looking for restaurants. It was a way to see what flaws we can improve on depending on things we see that are good, and what to avoid depending on what we see that hinders the user.
We ultimately understood that there was a lack of ability within the app to form connections to other users that regularly use the app. This means that there may be users who have people they know that also uses OpenTable, but no way of showing that within the app or connecting with them. From this, we decided to form a problem statement around how OpenTable may implement features that share these user's use of the app and their dining experience using the app.
How might we make it easier for returning users to find reviews of their friends?
We started by doing two brainstorming ideas, crazy 8's activity separately and a mind map together. The ideation phase was helpful to not worry about what the specific idea is but rather conveying it enough to be understandable. It was a difficult process though because when I started an idea and wanted to continue on it, I had to force myself to stop and think of another completely separate idea that may solve the same issue.
Afterwards, we took all the ideas we had, narrowed them down to their core way of implementing a solution, then created a priority matrix based on them. This was an additional way to organize our ideas, but also see the impact for each individual solution in order to gauge what might be worth the effort. The ultimate outcome of this gave us a chance to get our ideas prioritized on what we would like to work on.
A separate page where users can see friends' interactions within the app
Implement a filter button that includes friends' reviews specifically
We started with the end goal of a returning user viewing the reviews of a specific restaurant. We had in mind that these reviews will be linked to if the user makes a reservation. Interesting enough, there is a robust flow in place already to urge users to reserve through OpenTable, but a lack of emphasis in the reviews in this process, let alone user's friends.
With our improved user flow, we wanted to implements the features we brainstormed, but also have the emphasis change from reserving immediately, to leaning on user's friends to encourage them to try the same restaurants. This meant our flow was focused on the interactions users may see from other users within the app.
This was the first major step in laying out our ideas to learn exactly what changes we were looking to make and what each screen would generally look like. This gave us a visual representation of what the solution would look like implemented. It made us really think on how the features we intended to implement will be incorporated into the app seamlessly. The low fidelity models set the foundation, while the high fidelity showed the design as it would look in a published app.
OpenTable is a company with strong branding, which we used to our advantage to help with the returning users comfortability with any potential changes our solution introduced. Creating this toolkit helped tremendously when creating both our high fidelity screens and our prototype. By having this set up, changes were easy to implement if needed.
There was a still a gap between the high fidelity screen designs and the high fidelity prototype. Much of this came from establishing our components first before integrating them into the prototype in a thoughtful manner. Luckily, this was often easy to fix, and gave me the chance to learn about how interactive components truly work with different screens and such. Having this prototype as close to a well designed fully functioning app made the process of getting feedback from users smoother.
For our testing script, I wanted to make sure to try and get the best feedback possible, with open ended questions to the tasks that we provided. We started with an introduction to our test, a few background questions to establish demographics, then our three tasks each tester should complete. We did have more questions and the tasks initially were more segmented, but due to the limitations we had, we needed to condense them to get as much as we can in our test. This meant that unfortunately, we were unable to get wrap up questions included.
There were many successes from our designs, but also some failures. The biggest unexpected outcome was the feedback on our friend map feature. It seemed like many didn't feel the feature was necessary or was lost on the point of the feature. A triumph of the design was the almost universally positive feedback on the friend filter feature that was implemented. Lastly, our design included a specific search overlay feature for inviting a friend to a reserved restaurant table. It seemed like this feature didn't work well with our testing software, Maze, and their prototype feature.
1. The way that the design process occurs can be cyclical and iterative, many time going back to different phases help improve the end product.
2. Designing for the user can be challenging when you don't have a full scope of the user's thoughts, many times the assumptions one makes to bridge this gap can fail and lead to features users don't want or need.
3. Visually designing or redesigning a product can be meticulous, it can easily become tedious if there isn't a foundation to work from.
I would continuing the testing process, by returning to our initial script and breaking up the tasks for tester, to get more granular feedback to work off of. While that test was being conducted, the product would get another rework, by highlighting the friend filter feature, reworking the features included on the friend page. I'd then start the think on some more ideas to implement, such as a improved profile page or an improved social login feature to link apps. Those would be designed and go through the process until they are added to the prototype and included in the next iteration of our full usability test.