Resy

Website for wheelchair users to select appropriate restaurants for a comfortable meal with friends.

Background

Resy

The Problem

Resy does not have any accessibility accommodations

Role

Tools

Team

Timeline

UX/UI Designer

Figma, Figjam

Matthew, Karla, Rutuja, Krishna

2 months

Resy is a software created in 2014 to power dining experiences and connect restaurants to a network of engaged diners. In New York City, Resy has quickly become the platform where restaurant owners choose to list their restaurants. As this is the case, me and 3 other designers and researchers teamed up to improve their usability by assessing its accessibility accommodations.

After conducting an initial evaluation of Resy’s website, we couldn’t find any accessibility considerations. Wheelchair users who visit Resy would have to conduct their own secondary research to ensure that the restaurants they want to visit are accessible. While the website provides a good experience for others, it isn’t equitable.

How might we redesign a website for wheelchair users to select an appropriate restaurant for a comfortable meal with their friends?

Research

Interviews & Contextual Inquiries

We used several methods to gather information. All 4 members of the group conducted interviews with at least one wheelchair user and 3 members conducted field observations at restaurants while 1 member conducted a contextual inquiry with a manager of a restaurant. We created protocols for each of the methods used to ensure that all of our data are consistent.

Research Synthesis

What do wheelchair users need?

Given the data we gathered through user interviews, we found that:

  1. Transparency about accommodations should be prioritized.

    1. A lot of what makes a good restaurant experience is the experience outside the restaurnat.

Design Requirements

What does our design need?

After understanding what wheelchair users need, our next task was to establish what that’d mean for our design. The design we create should address the insights we found from our interviews and observations.

Design Requirements 

  • Provide users with a bunch of guides on different restaurants. We will expand on this in our features. (Secondary research on evaluating Resy’s website)

  • Allow users to search for restaurants (secondary research on evaluating Resy’s website)

  • Allow users to filter their search of a restaurant based on cuisine, accessibility features, ratings, price, neighborhood (secondary research on evaluating Resy’s website, secondary research on ADA, primary research with users)

  • Provide users with access to pictures of the bathrooms (secondary research on ADA laws and primary research with users)

  • Provide users with access to pictures of the restaurant’s entrance (secondary research on ADA laws and primary research with users)

  • Provide users with access to pictures of the tables, chairs and dining area (secondary research on ADA laws and primary research with users)

  • Provide users with further details about each restaurant such as cuisine, contact details, price, menu (secondary research on evaluating Resy’s website)

  • Confirmation for users when they reserve a place at a restaurant (secondary research on evaluating Resy’s website)

Low-Fidelity

Sketches & Gallery Walk

We created low-fidelity wireframes using the content of our Sitemap as reference. We chose to focus on three main sections of our website redesign, i.e. the Home Page, the Restaurant Listings Page, and the Restaurant Page. These are the pages we felt were most intuitive for a wheelchair user to reference when searching for accessibility information. Some of our sketches can be found in the appendix.

On October 8th, our team presented our work in progress in the form of a Gallery Walk (Figure 3 below). We showcased our work ranging from our research to our information architecture, sitemaps and navigation. We were able to not only practice communicating our work but also asking informative questions to our peers who were presenting their own works. Namely, this is where we received clarification on how to improve our Information Architecture & Sitemap to include more specific information on where to include the exact design content requirements we had in mind, as opposed to listing it as broad “accessibility information.” This was insightful feedback for us to learn how to properly construct a Sitemap and aided us in improving upon what we originally had made. Because our wireframes directly fed into this content, we were able to focus on what ideas to tackle and create for. We also received feedback from our peers regarding a variety of ideas. For example, we were given the idea of including an accessibility meter, which was a great way to think of labeling accessibility beyond a binary fashion (accessible vs not accessible) and, rather, think of rating a restaurant more on spectrum. We were also given the idea to incorporate reviews of accessibility features listed on a restaurant’s page. We liked that this gave wheelchair user’s a central voice and would help others decide whether or not a restaurant would be appropriate to dine at. Another piece of feedback we were considering was on expanding the scope of accessibility to web-based accessibility to include visual and hearing impaired people as well. Although our design frame gave us constraints to work within wheelchair accessibility specifically, this is definitely a point to consider beyond the scope of this project. We thought about ways restaurants can incorporate braille on their menus, for example. Many pieces of the feedback we received helped us iterate our previous designs and build upon our original concepts. For instance, the feedback prompted us to think about how reviews could serve as a confirmation from the wheelchair user themselves, and how important it is to design not just for the user but also with the user.

Design

What is our solution?

After getting feedback from our peers and understanding what our users need, we proceeded to continue with the redesign process by laying out what we have to work with on Figma. We started by taking screenshots of every page and section on Resy that we deemed as necessary to our solution. As seen on our information architecture diagram, we were proposing to add features onto the homepage, the restaurant listings page, and the restaurant-specific page. 

We concluded that the features needed to be implemented heavily involved providing transparency about the restaurant to the users. Our first solution was to create a way for users to filter out inaccessible restaurants by adding an accessibility tag. On the website currently, Resy allows users to filter by tags such as: “Top Rated,” “Climbing,” “Vegan Gems,” and much more. We proposed to add another one that’s for “Wheelchair-Friendly” restaurants. With this added and along with a toggle filter, it would narrow down the restaurants to the ones that are rated highly accessible.