You're out at the park with your friends. You've been walking around, everyone is tired and hangry. You didn't make dinner plans, and you know restaurant waits at 5 pm are usually longer than an hour. You love Thai food, but Anna doesn't eat spicy food, and Jon will eat anything but he's the hangriest of everyone and just wants to eat.

How can we help Yelp users choose a restaurant quickly when they're out with friends?

Preliminary Persona

I looked at user data from a few different analytics websites to try to find out who the power users of Yelp were, and the preliminary research showed 4 groups: college-educated people, Asians, women, and people in major cities. There's certainly room for more both qualitative and quantitative research, but this is enough for a proto-persona.

Provisional persona

Based on this preliminary data, I created the persona of Michelle who's out with friends on the weekend and doesn't want to waste time or money finding the best place to eat. To do this, she would benefit from a feature that would let her compare several restaurants without the cognitive effort of holding them in memory while comparing.

A couple of options I sketched out would let Michelle compare full listings, or compare multiple listings on the same screen--something between the full listing and the list view.

I spoke to 4 people to figure out the mental models they used for making decisions and how they arranged subjects they compare in their mental space to see if any patterns started to emerge. At the end of the mental model interviews, I also asked them what information would be necessary to choose between two restaurants.

What users want:

  • Ratings
  • number of reviews (to understand weight of ratings)
  • highlighted words from excerpts of helpful reviews
  • exciting menu highlights
  • pictures, maybe (but they think Foodspotting is better for that)
  • one-finger navigation

Problem, v2: the ACTUAL problem, and a better persona

I received a lot of feedback from other designers that I was trying to solve an enormous problem, so I sought out design mentors' feedback. Kate Rutter suggested that since the use case was of one person trying to organize which restaurant her group of friends should go to, I should play with letting multiple people take part in the decision process. This suggestion reminded me of Stephen Colbert's take onCongress:

"There’s supposed to be three branches of government: Executive, judicial, and spiteful inertia."

Since the initial framing of this feature was "choose," it allowed the possibility of group decision. I realized that in trying to solve the problem of deciding, I was actually solving two problems: comparison and consensus.

Whiteboarding to tease apart "choosing" : is it an act of comparison or consensus? Can the feature I design do both, or should I focus on one?

Instead of solving consensus, which Stephen Colbert rightfully compared to a force of nature, the act of comparing was something that could be solved with design. This reminded me of an insight from user interviews: in a group, usually there is one person who is the "foodie" who guides the group towards certain choices. I refined the persona to be Michelle the Maven, who is asking her group of friends what they want to eat, and is deciding for them using Yelp to compare what's nearby.


I had inspiration from a certain dating app.

A Tinder robot demonstrating the swiping to accept interaction

A Tinder robot demonstrating the swiping to accept interaction

Reading full listings and trying to remember what was important from all of them requires a lot of cognitive effort. This comparison feature solves that on the same principle as bubble sort/Bracketology: instead of comparing several restaurants by holding them in memory simultaneously, compare them one by one and pick the best of the two, and the last one remaining must be the best.

Sketches with interaction

One other change I made was I also tried to move the filter button to be located with the comparison feature in a swipe-out drawer.

This drawer menu and 2 screens fit into the normal restaurant finding process between/beside filtering the list and viewing full restaurant listings.

Initial flow with a slide-out drawer

Revised flow with secondary targets in the list view 

There were two main problems with this drawer, though

  1. Slide-out drawers—and gestures in general—have very low discoverability. A couple of people found the drawer by guessing, but it's not something the general population does. Maybe soon, though. I would like to test this feature to see how discoverable the swipe-out drawer is. The filter feature has a button, so it's easily recognized; the swiping action, however, allows the app to be used with one hand, which is a higher-order goal, but requires different behavior. Still, some apps (Slack, for example) use it really well. There's a trade-off in terms of engagement, but the current UI lacks space for a Compare button, which is why I tried to move the filter button to the drawer with the compare button. 
  2. Even if people did know where to find it, the pattern for slide-out drawers is that profile/app settings are found there, so there isn't much sense to put tasks there.  Also, the Yelp app doesn't allow many common gestures, so even though people have tried to swipe, they've learned that they can't.

So I redesigned access to this feature through secondary tap targets like how users select multiple emails in Google's Inbox app.



  1. Reduced time spent navigating between restaurant listings: users only need to compare two restaurants at a time, which are both visible on-screen.
  2. Reduced time spent scanning listings: users have the information they need the most when comparing two restaurants quickly.

Next Steps

  1. Adjust for various screen sizes + bars and buttons: one of the drawbacks of Android is the diversity of UI sizes and use of buttons. I'd also like this to be an experience that's similar between Android and iOS, which requires a lot of testing on different devices.
  2. I plan to add gifs to InVision or trying Framer JS for more nuanced animations because interaction design, animations, and gestures have a lot of potential to engage users and bring clarity to transitions and other state changes.