Design Critique: Resy (iOS App)


Resy is a digital platform that allows users to seamlessly reserve tables at restaurants or tickets to events/experiences. The platform provides restaurant details, menu highlights, images, and user ratings – all of which enhance the reservation experience. This article critiques the Resy App using the principles mentioned in Don Norman’s “The Design of Everyday Things”. 

1. Search Availability

If I want to filter restaurants based on number of guests, date, and time, I am able to do it through the Search Availability feature. The intuitive icon and labeling allow me to easily discover the feature. It has a number next to a “people” icon, the date, and time. Due to the signifiers (icons and labeling) having the same use in other similar platforms such as Google Maps, I am able to use a mental model when navigating this feature. 

When opening the Search Availability feature, I noticed the search button is grayed out. Using knowledge in my head from previous experiences, I would assume the search button is disabled until a change is made. Once I change the filter criteria, the search button is still grayed out. As a user, this is incredibly confusing and it gives me the impression that no matter what I select, the search button is disabled and I cannot filter my search.


In order to afford the search behavior, whenever a change is made in the filter criteria, the search button should turn purple as feedback. The user can use knowledge of the world to determine that they are able to filter their search once the button has changed color. Additionally, user behavior is constrained to only being able to press the search button if any filter criteria is changed.

2. Search & Location bar

I am afforded the ability to search for restaurants, locations, or types of cuisines. The magnifying glass is a signifier and tells me what the search bar is for. An issue I faced when using the search bar was the lack of separation between restaurant and cuisine search and location search. For example, if I wanted to only change the location, clicking “Location” would take me to the restaurant and cuisine search field. This is where the mapping goes wrong. 


To fix the mappings, the restaurant search and the location search bar should be split up. Not only does this maintain the discoverability of the feature, but it also constrains the user to only enter the relevant information in each bar. Additionally, doing this bridges the gap between the Gulf of Evaluation and Gulf of Execution by ensuring that the user is intentional with which search bar they are choosing to open and edit.

3. Filtering & Sorting

When trying to sort or filter the results in the Resy App, I noticed a rather lackluster user experience. Typically, when searching for restaurant reservations, I follow a mental model that I developed when doing similar searches on platforms like Google Maps. I use signifiers on the interface to tell me what kinds of filters are available to add to my search. Once I select the filters or sorting method, I get feedback in the form of a dynamically updated list of restaurants. However, in Resy, user behavior is constrained to only searching for one type of cuisine or restaurant at a time. Additionally, there is no affordance to sort the searches either.


To enhance the filtering functionality, there should be signifiers on the screen that indicate the filtering feature. By adding quick filter options on the search page, this will not just enhance the discoverability of the filter feature, but it will also encourage users to use it. They can filter their search by price, neighborhoods/area, and cuisine. When the user clicks and adds filters to their search, the list view will change accordingly as feedback. To sort the search, the user will use their knowledge of the world to identify the “Sort” icon which will provide them with a list of different sort methods. Once they select their preferred method, the list will dynamically, as feedback, sort based on method