Simmer List Search for Restaurant Discovery
Overview
The typical search pattern for restaurant discovery relies heavily on the end-user to curate and re-phrase their query to obtain the desired results. Users often have to juggle dietary restrictions, cuisine preferences, location, and reviews to discover and/or choose a restaurant to eat at. These problems become increasingly more difficult when attempting to navigate the preferences of larger groups.
Simmer List, using user data and publicly available information, utilizes AI inference to address these problems by recommending and curating restaurants based on the preferences of similar users, as well as users in an individual’s group. To deliver a satisfactory user experience, users will need to trust the provided recommendations, along with being able to quickly navigate and view individual restaurant listings. Our goal, as an embedded team of designers, was to create a search page, along with result listings, that would allow users to quickly find restaurants that fit their preferences.
My contribution
Product Design User Research
The team
3 x Product Designer 1 x Engineer
Year
2023
Process
Setting the foundations
We broke the project down into a few important chunks of work. This included: an initial search map view, a query loading screen, a query results listing page, a restaurant display card, and finally a filter menu.
When we first spoke with the engineer, the search page was nonfunctional and it wasn't clear what the intended purpose of the search function was supposed to be. The application as a whole encompassed a wide range of features, including a social feed for restaurant reviews, user generated restaurant lists, and a ratings platform. After a few rounds of discussion, we decided collectively that the search page would be the primary touchpoint for users. That is, starting from the search page, users would need to be able to access the other features contained within the app, but with restaurant discovery being the main focus.
This meant that we'd need to design a search function from scratch, but we'd also have to consider how search would integrate with the other core features such as restaurant reviewing and restaurant list curation. The engineer also emphasized that social would be a core component, so we needed to account for sharing and cross-user inter-platform interactions at various stages in the flow.
To validate our assumptions and reach alignment on the intended user experience, we created an initial wireflow walking through the user's journey within the search function. Although items would shift around and change as the project went on, we found that sharing this flow cut down on a lot of back and forth between design and engineering teams. As the old adage goes, "a picture is worth a thousand words."
Challenges along the way: ambiguity and engineering considerations
We came upon some challenges aligning our design considerations with the app's backend functionality.
The engineer's idea was that this search function would utilize natural language processing, augmented by AI, to deliver results that would be more accurate than traditional search. Additionally, a point of contention was the availability of a filter menu for users to manually refine their results. For engineering, the ideal scenario was one where users wouldn't need to rely on the filters to get satisfactory results. Another challenge was that we were tasked with creating UI and UX touchpoints that would help build trust between the user and the returned results.
This posed a substantial hurdle because it wasn't immediately clear from our group discussions what data points were driving the search results nor was it clear how exactly the search was functioning under the hood. The idea of natural language search, with prompting and re-prompting, seemed to be at odds with filtering results via an external menu and delivering singals that would build trust with the user.
Thinking back to our initial design conversations, we decided to create a diagram breaking down a hypothetical search query and share it with the engineer to see if our assumptions about the search logic were correct and what other elements we would need to consider.
I think this ended up being an "Aha!" moment for the design and engineering teams, since before sharing this diagram, we were at odds with what needed to be built and what we as designers could actually solve from a UI/UX perspective. The search feature, despite discussions of natural language processing, which evoked notions of ChatGPT style prompting and re-prompting, was actually set up more akin to traditional search (think: Google). The AI aspect in this case was just parsing the query language and returning more relevant results based on available user information.
It soon became clear that we could consider data points such as cuisines and restaurant themes as individual buckets of information that would get pushed into the AI, combined with data on user preferences and the behavior of similar users, to return more relevant results.
Figuring out user behavior without users
Simmer List had a functioning prototype, built out with multiple features, but the search process wasn't functional and there wasn't an active user base we could speak to. Keeping in mind that this search function was going to be the main touchpoint for users, we struggled with figuring out how users interacted with the existing elements (reviewing, creating lists, social, etc.) and how to integrate those into what was essentially an entirely new function. Based on our experience with this problem and other similar platforms, we had some high level assumptions about user behavior:
- Picking a place to eat is hard, especially if there are dietary considerations
- Getting people together is hard, considering weekends are quite busy for restaurants, making it difficult to find an available restaurant
- People are lazy. Most people would like to eat somewhere nearby to them
To address this problem, we decided to conduct interviews with users who were self-described "food enthusiasts," and designed our questions around their usage and interactions with apps that serviced specific facets of Simmer List (think: Google Maps, Instagram, Yelp). This enabled us to "dance" around the lack of active users and instead use their experience with other platforms to inform our design considerations. Centering our questions around user behavior when it comes to restaurant discovery and the timeless problem of picking a place to eat, we came up with the following user persona...
Although user personas tend to be a bit broad and surface level in terms of their usefulness, we found that the user frustrations aligned with our initial assumptions, namely:
- Finding a place to eat that everyone likes and fits everyones preferences is an extremely challenging task
- Scheduling is a big hurdle, especially for larger groups, and even more so when spread across a wide area
- Users tend to use a mix of apps for restaurant discovery, using their own heuristics to determine what would be a good fit
We also gleaned a few valuable insights to users' aesthetic preferences:
- Images were the most popular means of evaluating a restaurant's "vibe", food, and setting
- Map views were commonly used to gauge the centrality of a restaurant's location to members of the group
- Maintaining a simple, uncluttered UI, while providing a quick way of gauging a restaurant's compatibility was particularly important
Too many cooks in the kitchen
After confirming our insights with the developers, we presented the team with an analysis of similar platforms (think: Yelp, TripAdvisor, Google Maps) to see what they liked and disliked, as well as how we could address user frustrations from other platforms. Although we gained a lot of insight into the engineering team's preferences, we ultimately ended up with a CVS receipt of suggestions and ideas, giving us far too many items to tackle and consider when building our low-fidelity wireframes.
To avoid losing focus on the core product, we broke up the product into six discreet screens:
- Search Page
- Search Loading
- Search Results (List View)
- Search Results (Map View)
- Listing (Restaurant) Page
- Filter Menu
Following that, given the amount of ambiguity around the preferred design direction, and that there were three designers, we decided to create our own individual interpretations for possible solutions based on the available information. After developing our own solutions, we came together as group to discuss which elements we liked the most from each other’s designs and potential areas of improvement.
In the low fidelity frames below, we can see how our user research, combined with our discussions regarding the developer's preferences informed our design decisions. More specifically:
- An open ended search function where users could enter in vague search terms and then would be delivered a list of results that fit their preferences and the preferences of other members in their party. That is, rather than requiring the user to narrowly tailor their queries and adjust with filters, the AI pattern matching would do the heavy lifting, delivering more relevant results based on the available user data.
- An emphasis on image based displays, as evidenced by the card style restaurant listings and the use of image collages or carousels to present the user with an assortment of images, while not being overcluttered
- Keeping the location of the restaurant visible wherever possible. We can see this in the map view with use of location pins, as well as in the restaurant listing with the zoomed-in map view
The core idea driving many of our design decisions was Jakob's law, which states that "user's spend most of their time on other sites." In creating and deciding on our final low fidelity frames, we focused on creating a UX and UI that felt familiar to the apps that users already used for restaurant discovery, with the intended effect of minimizing the user's cognitive load and emphasizing the relevancy of returned results, all while promoting an ease of navigability that still allowed users to utilize the other features unique to Simmer List.
.png)
Outcome
After presenting the wireframes to the engineering team and project stakeholders, we received positive feedback on the flow and design aesthetics.
As an early stage start-up Simmer List had minimal documentation around design guidelines and styling. In order to help with translating our designs for the search feature across the platform's other features, we put together a Style Guide for the developers and future designers to reference. Putting together a Style Guide allowed us to further refine our design decisions and implement color and type hierarchies that would improve the user experience across the entirety of the platform by providing consistency in visual aesthetics.
High fidelity frames and developer handoff
After the positive feedback on the low fidelity wireframes, we knew that we were headed in the right direction. Presenting the low fidelity frames also gave the developer some additional ideas on feature and design add-ons that hadn't came up in our initial conversations.
This process was very insightful as it became evident that a well structured design and wireflow gave stakeholders a better conceptualization of their own platform. Additionally, it provided a framework for developers to suggest design elements based on their knowledge of the platform's backend and how features or functions could be integrated within each other.
In handing off our high-fi frames and style guide to the developers, we learned that it was important for the developers to see side-by-side how the style guide was implemented in the final designs. Beyond seeing how certain types, colors, or buttons were used, it allowed us as designers to convey the logic behind our design decisions and how engineering constraints factored into the choices we made.
.png)
.png)
.png)
Scope creep and working under a deadline: closing thoughts
Overall, the stakeholders were very pleased with the final deliverables and our communication throughout the design process. We delivered on our promises and provided them with a newly designed search feature that addressed the immediate user needs. Curiously, this project seemed quite simple from our first conversations with the team: create a search user flow and figure out a way to add context for AI supported search results. However, as the project progressed, we found ourselves creating not just a simple wireflow, but a detailed design and prototype for a product that would become the core feature of the platform.
With the shift from search being a side feature to a core aspect of the platform, we fielded a number of requests to integrate the platform's other features into the search flow. Although these requests seemed to be outside of the initial scope, it gave us as designers an opportunity to think holistically about the platform and how the user's experience with the search feature would translate over to and integrate with other aspects of the platform. As eluded to earlier, it seems that seeing thoughtful design allowed stakeholders to think more clearly about their app's overall direction and use case, providing a literal visual framework for structuring their ideas.
I'm quite proud of how our team of three designers navigated the initial ambiguity around the product and scope of work, but it definitely added additional complexity and time constraints on our deliverables. In the future, it would make more sense to scope out improvements and add-ons as separate projects, allowing us to focus more clearly on the problems at hand, rather than having to account for changing demands and visions while we were still working on solving the problem we were tasked with from the get go.
Given more time, I think the next problem to tackle would be translating the design and feature integrations we built for search across the platform's other features. Cohesiveness and consistency are at the core of a delightful user experience and it would've been interesting to see how the decisions we made for search would impact the design across the entire platform.