The Scope
People don’t trust the reviews they read online.
And why should they? They don’t personally know the people writing the reviews—and who is to say the reviews aren’t skewed by personal preference or even fictitious tales drawn up for some ulterior motive?
However, people do trust their friends.
100% of the users interviewed stated that they love trying new restaurants based on their friends’ recommendations.
But friends aren’t always around.
So, where do users turn when they need recommendations for where to eat but their friends are absent and crowd-sourced reviews are unreliable?
Well, Circle Reviews, of course! Circle Reviews aims to alleviate the stress of trying to find a new restaurant by creating a space where friends' recommendations are easily accessible and convenient.
Users within Circle Reviews curate a community of their friends, which allows them to access restaurant reviews written solely by the community they trust.
show me the data
show me the data
show me the data
show me the data
show me the data
show me the data
show me the data
show me the data
show me the data
show me the data
show me the data
The Research
overview
To gain an understanding of how users perceive crowd-sourced food reviews, I conducted interviews with six individuals and looked to answer the following questions:
What are people’s perceptions of crowd-sourced restaurant reviews?
Q
How do users use crowd-sourced restaurant reviews?
Q
How do users find new restaurants?
Q
Do users leave reviews & what is their motivation?
Q
pain points
From the interviews, I transcribed the recordings and determined the user’s primary pain points.
Users don’t trust crowd-sourced reviews.
Users feel that food is too subjective to leave reviews on and, therefore, they are wary of them and rarely take them seriously.
Recommendations from friends are not always accessible.
Users love exploring restaurants based on their friends' recommendations. However, these recommendations are not always accessible when needed.
Users have difficulty finding information on crowd-sourced review sites.
The menu, pricing information, information on food preferences and accessibility, location, hours, and even the restaurant’s website are difficult to find.
There is a lack of incentive to write reviews.
Users do not usually write reviews, largely because of a lack of guaranteed reward or large barriers to entry.
personas
With these pain points, I developed empathy maps, personas, user stories, and user journeys. Some highlights are shown below.
Creating personas allowed me to model, summarize, and communicate my initial research data and ultimately allowed me to have a consumable way to reflect on it. With this, each persona represented different pain points and a different end user which than could be referenced easily.
This helped to ensure I was designing with the user in mind.
user journeys
From the personas, I created user journeys. User journeys were created to understand the user’s flow and grasp where improvements could be made.
Let's create a solution
Let's create a solution
Let's create a solution
Let's create a solution
Let's create a solution
Let's create a solution
Let's create a solution
Let's create a solution
Let's create a solution
Ideation
Competitive Audit
By conducting a competitive audit, I was able to research crowd-sourced food review apps and understand areas where the competition was excelling or falling short. Three websites, two direct competitors and one indirect competitor, were analyzed.

value proposition
So, what makes this app different than Yelp?
Great question.
1
The reviews you see are written by your friends, not strangers.
Community Emphasis
Users can build a community of their friends.
Customizable Community
Users can categorize these friends into groups (aka "circles").
Customizable Feed
Users can give weight to their circles, which determines the hierarchy of how they appear on their feed.
Reliable Reviews
Reviews are verified by proof of purchase.
2
Accessible information on restaurants
Never wonder about restaurant accommodations.
Restaurant profiles clearly indicate food and physical accommodations, pet and child-friendliness, and the parking situation.
All the information you need
Restaurant profiles require the restaurants to enter their website link, hours, embed menu, and a photo gallery.
3
Writing reviews is incentivized
Variable Reward
The app works with various restaurants to develop a unique reward system. Each restaurant determines five rewards the user can receive after posting a review. Each time a user posts a review, a random reward is generated and given to the user.
Reward of the Hunt
Users gain rewards as they post reviews, which allows them to gain some level of monetary value.
Reward of the Tribe
The user’s friends can like, comment, and share your reviews, further incentivizing leaving well-crafted reviews.
user flows
Understanding the user’s motivations and intent helped to shape how each of the following flows worked. Two rounds of usability studies and iteration upon iteration brought the following core flows to fruition.
post a review flow
The post a review flow was designed with the intent of taking a daunting task and breaking it down into bite-size bits.
Many users in the initial interviews expressed that they didn’t regularly write reviews. Specifically, the users stated that they didn’t know what to write about.
Circle Reviews breaks down the review process into three main categories: food, service, and ambiance. From here, users can rate and comment on each category.
Although the review could be as simple as rating the three categories, users would be motivated to receive more likes, comments, and approval from their community. This would incentivize a more thoughtful review with clever comments and aesthetic photographs.
However, the choice is the users'.
reserve a table flow
Although the app is focused on crowd-sourced reviews, the reserve a table feature was added in order to provide a holistic experience for the user.
The goal of the reserve a table flow was to be painless. The flow allows for a reservation to be made quickly, as well as viewed, edited or canceled with ease.
Users make mistakes, plans change, reservations should never be carved in stone!
sketching & wireframing
testing & iterating
sketching & wireframing
testing & iterating
sketching & wireframing
testing & iterating
sketching & wireframing
testing & iterating
The Design Process
ideation cycle
My design process was broken into two cycles: the Ideation Cycle and the Testing Cycling. The Ideation Cycle went back and forth between sketching and creating digital wireframes in Figma.
Each instrument had its own benefits and drawbacks. Sketching allowed me to quickly illustrate my thoughts and ideas, whereas creating digital wireframes resulted in cleaner results.
The two worked together to lay the groundwork for the site.
sketch
Sketching consisted of building the information architecture, developing the hierarchy, and considering the layout. This manifested itself in sketches, scribbles, and wireframes.
Initial Sketches and Paper Wireframes
testing cycle
The Testing Cycle focused on iterating through user-generated feedback. I gathered user-generated feedback by conducting two rounds of usability studies. By testing the prototype, I gathered insights through the user’s interactions. These insights fueled actions that were used to improve the design.
testing
A usability study plan was written for each usability study done. Within this plan, I outlined the research questions, key performance indicators (KPIs), methodologies, and information pertinent to each participant.
Once the plan was established, I outlined a script to be delivered during the usability study. The script included an introduction, an explanation of the usability study, a scenario, and various prompts. This was created to ensure all the questions given to participants were consistent.
Each session was recorded through a voice memo application. After each usability study, I transcribed the recordings into actions to be done for the next iteration. I organized these actions into a table that categorized each by the specific page they affected, the urgency, and the type of correction. As I went through the iterations, these were either marked as "Completed" or "Left as is".
iterating
At the end of the testing cycle, I had an improved prototype. This would then lead to another testing cycle to further improve the site. After three usability studies, the pain points were few and far between.
FINSHING TOUCHES
FINISHING TOUCHES
FINSHING TOUCHES
FINSHING TOUCHES
FINSHING TOUCHES
FINSHING TOUCHES
FINSHING TOUCHES
FINSHING TOUCHES
FINSHING TOUCHES
FINSHING TOUCHES
The Final Product
in conclusion
in conclusion
in conclusion
in conclusion
in conclusion
in conclusion
in conclusion
in conclusion
in conclusion
in conclusion
Reflection
This case study was completed as a part of the Google UX Course through Coursera. The case study, although hypothetical, was an opportunity to grow.
Over the course of this project, I expanded my ability to think and design.
However, there were ups and downs. At one point in the design, I became stuck. Everything about the app didn’t look right. For weeks, I struggled to make it look "better" and to get my vision onto the screen. And yet, nothing clicked.
Finally, on my most frustrating day—I took a step back and asked myself, "What even is the goal of Circle Reviews?"
Then, amid my anguish, I remembered that the value proposition for Circle Reviews was to offer users a custom community of their friends where they could reference restaurant recommendations.
Taking a small step back allowed me to refocus. Suddenly, the answer was clear—it wasn’t strictly a restaurant review app, it was a social media app.
And like that, I was inspired. The app I had muddled with for weeks came together in a matter of days.
Color, layout, text, flew from my mouse and I created the final product you see today. Through this experience, I grew as a designer. Not because I suddenly could create something visually appealing, but because I understood how to approach design problems. Instead of focusing on UI elements to the point of exhaustion, I remembered that these elements are simply a medium for the project objectives.
Project goals drive UI elements, not the other way around.