Google Design Exercise
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. Provide a high-level flow and supporting wireframes.
I chose this prompt because of the complexity I see in it. It involves 3 types of users with interconnected goals and workflows: servers, restaurant managers and diners. This prompt also asks the designer to consider the employer - employee and employee - customer dynamics, which is an example of complex problems I like to solve.
First, I read up on the restaurant industry and interviewed a few people familiar with the industry for some preliminary research so that I can better understand the problem.
Servers are trained uniformly in a restaurant, but they have different strengths and weaknesses, which only present themselves in practice.
Managers use observations to provide feedback and help them improve, but it is second-hand knowledge.
The lack of direct and actionable feedback from customers prevents restaurants and servers from knowing what to improve on, and it hurts customer experience and a restaurant's bottom line.
Casual style and fine dining restaurants that are independently owned.
In fast food restaurants and cafés, servers don’t interact with customers as much and customers don’t expect as much service.
Most big chain restaurants already have ways of soliciting customer feedback on servers.
High level overview of my process for this project. There are steps I wish I could have taken if there were more time and resources. I've listed them at the end of this case study.
To understand the causes of the problem and to find potential solutions, I identified 3 personas involved with server feedback and interviewed a couple of frequent restaurant customers, servers, and one restaurant manager in the targeted market segment: casual style and fine dining restaurants that are independently owned.
Due to the short time frame and limited number of users I interviewed, instead of building full-blown user personas, I created these lite-personas that are just enough to guide most my design choices.
Of the 3, a restaurant manager is the only persona that has enough motivation to seek a solution.
She is also the only decision maker who can implement the solution most effectively.
What's more, servers would trust the feedback and act on it more if it’s delivered through the manager.
Before laying out a product strategy, I made the following assumptions:
Based on the persona analysis and assumptions I made, I decided that the solution should be an added feature in Google My Business, geared toward a restaurant manager. She uses it to:
From my research, neither servers nor restaurant managers expressed needs for customer feedback as a factor in a server's search for new employment. Besides, the new employment piece of the puzzle can only be solved after the solution itself is widely adopted. So, I decided to punt this feature for future consideration.
My competitive analysis covered the following tools in 3 categories. I analyzed the pros and cons of each tool to inform my design decisions.
Taking the persona analysis, product strategy and competitive analysis into consideration, I set these design goals for each persona's experience.
The first user flow is for the majority of diners who don't regularly review restaurants online. Diners are passively asked to respond to surveys when they read the bill and receipt, so there's no added human interaction and diners don't feel interrupted.
I explored the option of a pen and paper survey, which some restaurant chains use. It was ruled out because of its potential to be immediately read by servers and cause the kind of conflict the diner wishes to avoid. Surveys in paper also need to be tallied and documented manually, which adds cost for the restaurant.
I landed on the unique URL on the bill/receipt approach to reduce the questions the diner has to answer, so that they don't feel burdened. If it's a generic URL or a step-by-step guide to use a Google app, the diner would have to answer the restaurant name and name of the server.
The second user flow reflects how a user rates the server if they post a public review of the restaurant on Google.
I decided a diner should only be asked to rate the server AFTER, not while they submit the restaurant review because I feared the added questions will decrease the existing review finish rate. Also, server reviews are meant for a different audience: restaurants, not the public.
Server selection is optional, for 2 reasons:
Restaurant Managers do most of the heavy lifting through the setup process because they are the ones who are the most motivated to implement it.
I've chosen to integrate the solution inside Google My Business because they already use it to manage something of a similar nature - reviews.
To make the feedback informative and actionable, the restaurant manager creates a list of desired attributes so diners can pick the ones a server needs to improve on.
Restaurant managers see servers face-to-face frequently, and have weekly or monthly reviews with them. The survey responses would be an added data point for both to track and act on.
They are not required to actively participate in the implementation of the solution due to their lack of motivation and limited decision power. All their work is still offline - serving the diners - and the only thing that's changed is another source of actionable feedback.
I wireframed and prototyped diner's flows first, because the. solution is only meaning for if restaurants can gather enough informative feedback. The design choices made in these flows will inform the rest of the design.
The wireframes are in mobile because diners are most likely to open this URL while in the restaurant or on the way out. Besides, I found that even Yelp, where users write a lot of free text, gets 65% of its reviews from mobile.
Among all the customer rating UX patterns I explored, I found Uber's pattern requires the least amount of work from users, and customer feedback is structured so it's more actionable. I utilized a similar pattern in my design because it fits my design goal well.
A diner uses a unique URL, the URL opens a survey in Google Maps (or on a mobile site, if Google Maps isn't installed):
Click on the image to view in full screen.
A diner reviews a restaurant on Google Maps and then responds to a survey:
Click on the image to view in full screen.
A restaurant manager sets up the survey in Google My Business.
Click on the image to go to the next screen.
A restaurant manager analyzes diners' survey responses on both the restaurant and individual server level. Some of the UI patterns are inspired by Google Analytics, which also has the concept of comparison between data from one time period over another.
A server receives a weekly (or monthly, if the number of responses is low) email, which highlights the average ratings of the past week.
It does not show the all-time average, because over time that score will become stable. Servers with high ratings might become complacent, servers with low ratings might become discouraged.
If I had more time and resources, these are the next steps I would take: