I don't really like to cook so I usually go out to eat. Since I live in San Francisco I'm surrounded by restaurants but for some reason I can never decide on a place to eat. I have a handfull of go-to restaurants, but if hunger strikes and I'm not in the mood for any my favorites it can be frustrating to figure out where to go. "Why don't you use Yelp?" you might say. I do, but I have a problem with Yelp. For some reason, it's just never helpful. It's great if I want to look up information or reviews for a restaurant but when it comes to find a place to eat it doesn't do it for me. I'm not the only one with this problem. I learned that it's fairly common when I asked around. My friend and fellow designer Austin McCasland is plagued by the same issue, so we teamed up to solve it.
When we set out to design this project we had two things in mind: Keep it simple, and make it fun. Since the service itself is very simple and has been done before we needed to make our design stand out in a big way. The experience of the app rides on the simple and beautiful design, sleek animations that captivate the user, and a cozy and personal narrative experience.
Eat Roulette is currently in testing and development and is slated to release in 2019.
🔊 Video has sound
These are the final screens for Eat Roulette. I'll explain the process we took to arrive at this design.
Identifying the problem
The problem behind this issue is simple: oversaturation. When you look at Yelp to find restaurants you're given two views to look at – a map and a list – and both show you a lot of restaurants. The map view shows 20 and the list view shows 23 before giving you the option to load more. It's a lot to consider if you just want to get something quickly. We believe that by eliminating all of the clutter and simply showing you one place at a time it'll make decision-making much easier. Basically, we'll just tell you where to go.
Since we wanted to keep interaction light and decision-making easy, the user flows are quite simple. From the main screen the user has three buttons that they can tap: location centering, search filter, and the search button. Aside from being able to set your search area (similar to Yelp's 'search within this area' function) we wanted to give users the ability to filter between restaurants, bars, and restaurants with full bars. We debated quite a bit between even allowing the user to filter between bars and restaurants but through interviews realized that people do want to have this control. This works for us as it makes the app be more useful than just finding food, but is also great for finding a place to drink on a Saturday night. I think the saying goes "if you build it, bar flies will come."
Finding a restaurant
While the idea is simple, there are a number of different ways we can present the UI. We went back and forth on a number of designs and mostly struggled with finding the proper way to show the "searching" state. We looked at ways to create a fun and elaborate sequence that involved rotary cards similar to a roladex, a box that had restaurant names quickly cycle through, map pins, or a stream of line items that cycle down the screen like the Price is Right wheel.
When we originally toyed with the idea of Eat Roulette, it was in the form of a skeumorphic interface with a wheel of fortune style wheel that users would literally spin to discover where they would be going. We initially thought this would be a fun interaction for a simple tool, but as we started to validate the concept with other people, we quickly realized that we had stumbled on a funny, but real, problem, and that many people would be interested in a more useful interface for simplifying their decision making.
Sort & presentation
We briefly considered the blurring out the map on the main screen until the user hit 'search' in an effort to remove all forms of decision-making, but we quickly realized that this would cause more problems than it fixed. While the 'center location' button is easily accessible, there's no real reason to hide the map. This would likely cause confusion and leave the user wondering if their location was known by the app, or force them to squint and try to catch geographical details underneath the blur to see if the location was captured. Stupid.
We eventually settled on a solution similar to the map pins but simpler. While searching, dots around the map signifying potential locations fade in and out. This creates anticipation of potential results and shows the search area on the map so that the user gets an idea of where they may be going, and gives them a chance to back out if the result is unsatisfactory.
The most important part of the interface was, as expected, the most difficult to get right. We needed to identify what information we presented, which came down to identifying what the app's purpose really was. Should we simply show you the name and location on a map and call it done? Can we include supporting information to help the user if the result we gave them is good enough? If so, what should we include? We knew that other than the name, the hours of operation were important to know (we aren't going to show a search result for a location that's closed but if the user performs a search at 8:52 PM and the location they're served closes at 9:00 PM that's important to know). When it comes to other information we (wrongly) suspected that the user wouldn't care too much. We quickly found out in our testing that this was a bad assumption.
We identified that the most important information we needed to include was the name, address, hours of operation, reviews, and pricing. This isn't too much information but it's difficult to present it all and keep with our clean and minimalist style. We played around with some iconography for the ratings and cost, but ultimately reverted to sentence structure to maintain our narrative experience (which I talk about further down the page.)
Originally, once a restaurant was chosen that was the end. The only other option was to search again. This left us feeling like the experience was lacking. After some discussion we realized that this shouldn't be the end of our relationship with the user. Rather than simply give you a place to go and calling it a day, we want to increase engagement and see our job all the way through. It was after realizing this that we decided to build in one more step to the flow – navigation.
When a location is served there are two options: "redo" the search and "go". If you tap "go" the screen transitions into a "navigating" state. We show some more details about the location – hours, contact information, the option to see the menu, etc. – and use the top portion of the screen to show the navigation on the map. The user can use this to walk to the chosen location and see supporting information on the location they're going to.
Getting the filter down correctly was a difficult task as well. With our initial idea we weren't even going to include a filter. We figured keeping this soley for restaurants would be enough – at least for an MVP. But when we put the idea in front of some people every one of them wanted the ability to search for other things and have the ability to manage that filter. This wasn't a shock to us as everyone is conditioned to being able to do this in every other similar app they use. We decided to create three categories for two types – food, drink, and food and drink together.
One method we looked at a fully-visilbe tab button on the header or footer. This solution doesn't really stick with the most common uses for this UI paradigm and could lead the user to expect that tapping on different buttons would change the screen. We didn't stick with this solution long enough to clarify what the different filters were with iconography. After a few iterations we decided to put the filter under a single button that expands out other options when tapped. This works better because it simply displays which filter you have selected and is consistent with the location center button on the opposite side of the screen. Initially we were only going to let users select one category to search for but realized that we weren't solving for each use case. There are chances that someone would want to search for restaurants that also serve alcohol, or hit up a bar that also has drinks. By letting the user select multiple categories they can select different combinations to find exactly what they want.