bsleycasestudies

[bsleycasestudies]

Resy

Portfolio: Resy

I spent a year at Resy, helping them relaunch their guest experience on iOS and Android. I've taken a stab at summing up what me and my team did below.

I left Starbucks in January 2018 to join the Resy team in New York. I'd worked with my friends at Canlis for years and gotten a glimpse of what good software could do to a dining experience and buisness. Resy and only a few other players were at the center of that.

In the reservation space, OpenTable had long been a monopoly and Resy was challenging the behemoth, going after some of the best restaurants in America.

Resy had spent most of their time focusing on their primary product: the restaurant app itself. Reservations, hosts, and servers used Resy to take reservations, cater to guests, and organize their inventory for years. This was the bread and butter and what ultimately sat at the center of their business proposition.

The next big step for Resy was the guest side of things. The iOS and Android app had been largely underserved and the user experience hadn't seen much change since its launch.

I worked along side of John Neidermeyer, on the heels of the work he and the engineering team did in relaunching a new resy.com. I began revisiting their iOS and Android apps for the best reservation experience and updating the whole suite to feel like one cohesive brand. I dig into some specific features below.

I worked closely with the Tomor Molovinsky (Product Manager), Tobin Schwaiger-Hastanan (iOS), and Rob Glover (Android) to prioritize where we wanted to put our focus the most. Core parts of the app were litered with dsyfunction and we had to juggle a big pile of low hanging fruit along with some bigger aspirations like a rewards model and smart ways of personalizing the app.

Component-Based Design:

Product designers tend to like systems but beyond a loose ideal, I learned the value of a component-based design system at Starbucks. I was at the center of developing a design system for our web and ultimately all native platforms.

First on the list at Resy, regardless of the feature we needed to tackle was to reign in dozens and dozens of styles and build a small system of reuable parts. This included typography, color, UI components and some rules around when we used custom components vs. just relying on tried and true native interactions.

The challenge was that iOS and Android had a wildly different look and feel from the newly redesigned resy.com. We wanted to leap forward into the future of what the app could be but we also didn't want to c reate scenarios where brand new screens that looked entirely different than a screen you'd just screen would disorient you and ultimately impact our user e xperience.

The compromise was to settle on an interim design languagen that used the same font as the existing UI and a dark theme. Later, I'd go through these same set of components and revisit them to reflect the visual choices on resy.com. In fact, this was consistently updated in tandem.

Performance:

Resy app was built when Resy was small. So many of the issues we had were a direct result of growth that wasn't kept up with. It's a soapbox of mine, but user experience isnt limited to visuals and the things a designer is typically assigned to. In this case, our biggest issue was performance, specifically when you opened the app. I worked with Kevin Schumacher and other back end engineers to take our 16+ second load time down to 4. From there, Tobin and I built in ways to load the content incrementally, not letting things like large images and big map areas block loading content that could be immediately visible.

Sign up:

As far as features go, we started with the top. A lot of users were bouncing due to a difficult sign in process which required an email, full name, location etc just to look at what restaurants we had in the app. I simplified this a ton, asking for just a phone number, then using Twillio to send the user a code, that they could easily pop into their app and become a user immediately. This increased new user conversion a ton, drove up our app store ratings, and gave us a much more dependable phone number for guests that we'd later use for reservation confirmations.

You can see this feature live by downloading the Resy app here: XXXXX

Profile:

There was a lot of appetite for change in the app but when it came to making big shifts in the UI, allegiance to the way things were became a barrier to getting things done. One of the ways me and my team navigated this was by choosing a relatively isolated part of the app, Profile and proving we could make big, meaningful improvements without interupting the core experience of browsing restaurants. I have Tomer to credit for driving this strategy.

Profile was all the obvious things you'd expect under "Account" but also managing your reservations, past and present. The existing screen was a flyout menu of titled sections. The terms in many titles were unclear and the most important actions a user would want to take were buried under a couple taps. I worked with real users in testing and data from Mixpanel to identify key actions and figure out a way to elevate those beyond just browsing a heirarchy.

This also required revisiting the whole information a rchitecture and parent/child relationships within Profile. I used a tree test to validate and investigate multiple different models of organizing the sections before landing on the one Resy uses today. Listening to the language real users used to describe their actions was key to clear labels and easy to find actions.

You can see this feature live by downloading the Resy app here: XXXXX

Map vs. List:

This interaction was tough. We explored a bunch of different models. Tested them in coffee shops. Used principle.

Search:

Before leaving Resy to work at Goodthings, my last feature was Search.

Reccomendations

Autocomplete

Filters

Sort

Testing different models of re-arranging the screen.

Everything is search!

Tada!

big image to tie it up.