WAIT STAFF REVIEWS APP
As part of the Google interview process, I was given the challenge to design an app.
The entire process described below was done in a total of 2 days.
Design an experience where diners can submit positive comments and constructive suggestions for the wait staff, and servers can use this feedback to both improve and help to secure new employment.
DOWNLOAD PDF VERSION HERE
As a former server, I was able to relate to the problem presented. To validate my assumptions and obtain better understanding of the problem domain, I conducted small and informal interviews with servers, diners and restaurant managers about the review process in which the following insights were obtained.
STAKEHOLDERS INTERVIEW INSIGHTS
• Usually, restaurants managers require servers to ask their customers for reviews; however, neither the server or the diner have real incentive to perform such review.
• Building a visible and positive database of customers’ reviews could provide servers a platform for new employment, or better benefits at their current job.
• Reading reviews about a server while choosing a restaurant, will most likely not have much impact on their decision. If diners give a positive review it is usually because the server was really good and they felt inclined to let it known publicly.
• Diners are more inclined to review their service if there was an incentive for them, or simply because the server explained the benefits of having a high review rating.
• Managers have very limited information on how to best evaluate their servers. The best shifts are usually given based on seniority. Very rare positive comments about a server are given to managers.
• When hiring new servers, managers can only evaluate the server from their resume. Recommendations could be asked from previous employers but the opinion from those directly impacted from their service (the customers) is not taken into consideration.
To get a better understanding how other companies collect feedback for different purposes, I went through the process of giving feedback for different industries: healthcare, financial and food services.
Bank of America - Financial center review
Keeps their feedback simple with a single question satisfaction scale.
Oscar Health - Doctor’s visit review
Oscar sends an email to their members to review the doctor through a web form, but when trying to find detailed information of the reviews, in the app, they are not available.
Seamless - Restaurant review
Reviews are very important for restaurants in this app; therefore, Seamless aids the restaurants get reviews by sending push notifications after the food has been delivered.
WHAT’S THE USER’S MENTAL MODEL?
Dustin L. | SERVER
• I want my managers to know I do a good job, and customers are happy with my service.
• By knowing improvement areas of my customer service, I can do a better job and possibly increase my tip revenue.
Fernanda O. | DINER
• As a restaurant diner, I received great service from my server and I would like to give them a good review and make additional recommendations for the future.
• This process should not take too much of my time but should provide the value necessary for the server.
Melissa S. | RESTAURANT MANAGER
• I want to be able to not only review negative comments, but reward/appreciate those employees that receive positive reviews.
• When hiring new staff members, the customer voice is important in understanding the customer service abilities of a server.
• Knowing what customers think a server should improve on, could be used as a base for their performance review.
After having a better understanding of the problem domain, users’ mental model, and the competitors approach to reviews, the next step in my process is to define the system of real-world objects that make up the user’s mental model of the problem.
This will allow me to ensure the anatomy of every object is mapped before sketching, wireframes, interaction design or visual design begins.
I do this, by following the Object Oriented UX method, which roots every interaction in a well-defined direct object.
Objects are derived directly from the goals of a system, and goals should be derived from research.
Diners can submit positive comments and constructive suggestions for the wait staff.
Servers can use this feedback to both improve and help to
secure new employment
IDEA #1 - USING EXISTING APPS
This experience was meant to be embedded and work with the user’s existing preferred restaurant rating app.
Review app: if location services and notifications are turned on, a notification would pop-up as diners enter the establishment, asking to review their server in 45 mins.
Check-in app: if diners checked-in, a notification would pop-up 45 mins after diners had check-in, asking to review the server.
Google maps: using location services, a notification would
pop-up as diners enter the establishment asking to review their server in 45 mins.
HIGH LEVEL FLOW
Taking into consideration the work previously done, this flow shows the high-level relationship of the objects and elements within each other.
While looking at the OOUX element audit (ideally done with product managers, researchers and engineers) and thinking how the elements could be implemented with this idea, some questions came up:
• Should only the waiters create their profile or let diners add new waiters into the restaurant profile?
• How would duplication of profiles be dealt with later on? Should there be “verified” accounts created by servers/restaurant?
• What would happen with comments/suggestions associated with non-verified waiters?
• If a waiter profile was created by a diner to review, should the system label that account as a secondary profile and could it be claimed by a server/restaurant if they link that profile to their account? (is this you? Claim your profile?)
• If a waiter/waitress left a restaurant, or works at multiple restaurants, how could they access their aggregated reviews?
• How would the waiter know someone left a review for them? .
IDEA #2: CUSTOMER SERVICE REVIEW APP
The goal of the project was to focus on the server, and creating an application that would that the servers’ community, could have more value than adding a single feature to an existing review app that focuses on locations rather than the person.
This individual application could also be an opportunity to expand to other customer service areas and not be limited to the food industry. It would focus on the person and helping them improve.
Things to consider:
• A profile must be created before using the app.
• Reviews can only be left to those servers with a profile.
• Comments and suggestions are the main feature of the app.
Nice to have: Diners would be incentivized to leave reviews to gain different statuses in the app, based on their suggestions rating
(allow for wait line skip when their suggestions is top on the server’s profile?)
Diners can also create promotions (kickstarter-like idea)
The OOUX process identifies the needs for each screen, after there was more direction with what we wanted the app to do, I reavaluated each object and elements within, and narrowed down the needs of each. When working on wireframes, placement and hierarchy of elements are the main focus, as well as trying to find patterns that can be used through the application.
Below a representation of the main screens a diner will interact with in the app.
For the design portion of this project, I wanted to keep the three user types in mind and represent them somehow within the app. This is where the idea of using three different colors for each user profile type was created. This will allow the app user to quickly know which profile type they are looking based on the color theme combination for each screen.
The overall design for the different profiles is similar, just adding/removing some functionality and information depending on the user. I believe this is beneficial for the developers, as well as the user, as they don’t have to re-learn how the information is displayed on each profile type.
In every step of the development process I always try to do some type of user testing before moving on to the next step. It is important to validate assumptions and test different hypothesis.
Once it reaches the prototype stage, it is important to conduct structured usability tests with real users, focusing on different scenarios and paying close attention to how the user reacts to
the actions they take.
For this step, I would work with interviewers on crafting the perfect scenarios for each user type that would cover most or all the scenarios developed for the app.
A sample scenario for a diner would read like the following:
Imagine, you just came back from a dinner with friends and your server asked you to leave her a review on the new wait staff review app. She wrote her user handle for you to find her.
You already have an account setup, login to the app and find your server, @elizabeth.knight, and write her a review for the great service she provided.
As the user tester is performing the tasks, it is important to have them explain out loud their thought process, and why they click the buttons they click, and choose the steps they choose. If there are unexpected scenarios, dig deeper into what they were expecting and always asking WHY?!
We learn a lot about our users’ behaviors by analyzing data and incorporating metrics into the products we develop. By working with PMs and engineers, I would create a list of the metrics we would like to follow to support future roadmap decisions and implementation of new features.
With this MVP the needs of the diner are covered, they are able to easily provide comments and suggestions to the wait staff with a few simple steps.
How to determine success?
I would determine success of this app by:
Having multiple user types sign up and engage with the app.
If a diner type user signs up and submits 2 or more reviews (comments or suggestions) for different servers.
If a server type user signs up and receives 4 or more reviews from different diner type users.
What are some potential future next steps to take?
I would add more focus on the wait staff profiles, specially on the suggestion feature.
How could we leverage the information provided for the wait staff and create more engagement from those users?
Potential ideas include: alerts, and suggestion grouping based on skills mentioned.
Would be good to add metrics on the feature that allows other users to “up vote” a suggestion.
On the new comment form, I would also add more tiles for the characteristics a waiter is evaluated on. Initially this determines their rating. What other features could we use to evaluate a user’s rating?
In my opinion, the best way to learn where to go next, would be to release this app in a pilot release for a specific period of time. During that period, keep a close look on the app metrics and collect feedback from users on what their joys and lows are while using the app, and if the servers have noticed a change in their day to day because of the reviews they receive .