Where should we eat?
Design for where2eat, a collaborative meal-planning app
It’s a scenario we are all too familiar with: you and your friends are making a plan to get dinner, when someone asks “where should we eat?”
Suddenly, everyone is indecisive; no one wants to make a decision even though everyone has a strong opinion about where they want to eat.
How can you channel these strong yet unvoiced opinions into a fully planned meal? Enter where2eat…
The Concept
where2eat is a desktop application that allows groups of friends to plan meals and collectively decide where they want to eat. An organizer can create an event and share a link with friends, who can then search through restaurants and vote for their favorites. After voting, people can see the most popular restaurants in the group to make their choice about where to eat!
In this design, users can vote for restaurants located in the Providence, RI area.
The Process
To start, I analyzed the design of when2meet, a similar website for collaboratively scheduling meetings, and interviewed potential users about what they would want from a meal planning app. Using data gathered from the when2meet analysis and user interviews, I did initial sketches for where2eat in Balsamiq, with the following key design elements in mind:
- A clean interface that allows users to see event details such as date and time in addition to voting for restaurants.
- A lightweight URL navigation system and minimal onboarding process. Users did not want to have to create an account to use the site, but rather wanted to share links to start the voting process.
- Limited restaurant choices. When I proposed a design that had users nominate restaurant choices, users stated that this was not fixing the problem of indecision; users had an easier time picking from a limited set of restaurants.
The Design
where2eat uses a cohesive visual design language to create a uniform and intuitive user experience. The app utilizes the large blue banner logo throughout, which ties each page together and provides easy navigational access to the create new event page. Information on the app is laid out in grids to highlight and visually organize important information and interactions. Designs for the four main pages are below, along with more detailed design choices for each page.
The create event page is considered the “onboarding” page for where2eat, as there are no traditional accounts. With this in mind, this page is meant to have a very simple flow to reduce user dropout; users only need to input three pieces of information to get started. The date and time fields have associated calendar and time pickers and error checking to make input very simple, with no ambiguity about required date and time formats.
This is the main sharing page for an event; it shows important event details and launches users to other actions. This page is simple and lets users see all available actions in the button bar from one page, making the interface more learnable and intuitive.
From the initial interviews, users wanted to be able to quickly share events without creating an account, as an making an account seemed like overkill for saving results that would be discarded after a decision was made. The note to user to “share this page’s link” was added in a second iteration to tell users how to actually share the event with friends, as users were unsure about how to share events without the more explicit note.
The URLs actually provide navigation structure, as they contain the page’s purpose — either meal, vote or results. While this may not be explicitly obvious to users on first use, this provides easy navigation for power users while still keeping the links readable and shareable for all users.
The page for voting for restaurants is organized in a grid for easy visual navigation. The page is filterable and sortable to help users narrow down their choices. In an earlier iteration, users could sort restaurants by distance from a central location instead of by number of votes. This often led to no clear favorite restaurant emerging, as users would spread their votes out over many restaurants. When the sort by votes option was added, a clearer consensus was often reached, as users could narrow down to a smaller subset of restaurants to focus on upvoting and downvoting.
The results page again features a grid to show the ranked restaurants. The page uses a two tiered ranking system; restaurants are first ranked by total votes (no. upvotes — no. downvotes) and ties are broken by number of upvotes. Only a limited number of top restaurants are shown; three to start, with more if there are ties among restaurants. In an earlier iteration, all restaurants were shown, but users complained the page became unnecessarily long, especially given that users only cared about the top few choices, and many restaurants received no votes.
Finally, the results (and voting) page again feature the navigation button bar at the bottom, so that users can easily navigate to any page from anywhere in the application. This is especially important given the no-account nature of the application; users should not lose their spot or get trapped in any screen in the application as they may permanently lose their place if they have to exit out of the app.
In Conclusion
I found that the hardest design decisions to make for this application was the decision to go with the lightweight, no-accounts structure and the decision to limit user choice by limiting available restaurants for voting. In the end, I think that the decisions to remove user accounts and to limit the restaurant choices ultimately served the purpose of the application, which is to provide a quick way to collaboratively choose a place to eat; this doesn’t require the record keeping that accounts provide. Similarly, having users nominate restaurants goes against the purpose of the app, as it prevents a group from reaching consensus on one restaurant. Making choices with the ultimate goals of the app in mind, and iterating over user feedback to mitigate the possible consequences of these design choices was essential in ensuring that the final product fulfills the purpose that it was designed for.
The Product
Plan your meals at http://cs1300-where2eat.herokuapp.com/home!
Here’s an example event: http://cs1300-where2eat.herokuapp.com/meal/0PC3sj2
Please leave feedback using this form!
