Objective: to create easy and non-intrusive experience for customers to choose business establishments based on server reviews
Strategy: by designing interface & notifications that encourage users to think back on their restaurant experience and leave honest reviews
John Sullivan, 27
Tech-savvy mobile user
Works in tech marketing
Busy but optimized and organized, opinionated
A typical restaurant experience: having dinner with GF, looking for restaurants that impress, looking for experienced servers with wine knowledge.
Mom of 3 kids
Brings kids to restaurants with her partner
A typical restaurant experience: choosing the best options suitable for her kids, looking for servers or restaurant who are patient with kids and energetic.
Sarah Hampton, 37
Study & Research
Objective & Strategy
Low Fidelity Wireframes
High Fidelity Design
Designing OpenTable Server Review System
I like to take on design challenges on my own time to exercise how I think about products and how I can improve or build on top of them. This OpenTable redesign project is my attempt to redesign a less familiar product back in December 2016.
The challenge that I set up for myself is to create a review system for service provider within 3-4 hours (a Saturday afternoon for me) using my design system at the time. I decided to refer waiter/waitress as servers here as an attempt to be inclusive of all genders (this change was made following the completion of the whiteboard sketches so it’s not documented in the photos).
The big question that I really wanted to understand from users is about whether server’s quality affect people willingness to book a restaurant. From the 10 people I had a short in person and online chat with (5 male-identified and 5 female identified users from 18-25 y/o) chat with here are the findings:
7 - Post Mortem
Final key screens as a result of my design
OpenTable, as well as similar products in the market, currently does not allow a customer to leave specific reviews for individual servers (waiter). Create a UX solution for the current app.
Defining the Scope
In a real-world situation, designing for a feature in an established app like OpenTable would usually take into consideration of all the business decisions, OKRs, development constraints and team feedback before starting any research work. However, since this is a personal project, I took the liberty of design freedom and focus solely from the UX perspective and my observations of the current app at the time of my design.
Understanding the existing OpenTable interactions
Being new to the app, I try to spend about an hour drawing out the existing flow of the application. I pay particularly close attention to how the current feedback/review system is implemented for businesses.
The feedback system is implemented both within the app and directly within automated emails.
There’s a 50 character minimum for reviews
The review system is only available when a reservation is made
Noise level was one of the metrics
Here are some of the key findings —
As a way to further familiarize myself with the problem space, I tap into some big questions I have, that if given the time, I would use as an objective for any research I would conduct—
How do people remember the noise level? How accurate is this metric?
How important is the quality of the waiter in user’s decision making in deciding on a restaurant to go to?
How does information affect customers’ decision making for booking?
Does the quality/validity of the reviews themselves makes a difference? (at the time Opentable review does not require signins)
For users who are familiar with the OpenTable review system, when are they most likely leaving their reviews.
What attributes make a server a good server?
For most of the interviewees, seeing negative reviews about the service (“the server was rude”, “we have been ready to order for 20 minutes and they did not bother to check on us”) wouldn’t be a deal breaker for them when deciding whether or not they want to book a place.
About half of the interviewees did mention instances where good service seemed to be a driving factor for booking a reservation when asked about a recent experience booking a restaurant (through apps, phone calls, or in person)
Based on the people I talked to, I consolidated 2 simple personas to capture the two types of users I ended up designing for.
Objective & Strategy
Based on my initial ideations, I narrowed down my project focus to the following objective & strategy—
Based on user stories, research, competitive analysis and assumptions, I generated a list of requirements as follow
While it would be cool to put this interface to the test. Here are a few concluding notes:
Features like reviews for servers can potentially be a little bit more hidden to align with the original intention of being “non-intrusive”
More interviews and use cases can uncover server’s characteristics— what’s important to the customer
There are still a lot of opportunities to explore different user journeys and touchpoints where users would be required to recall information they have about the servers.
My study on the existing flow and ideation for improvement (on white papers)