In which we simplify the shift selection process for restaurant hosts on our company's restaurant tablet app.
End-to-end design: generative research, ideation, wireframes, prototype testing, UX strategy, onboarding flow
Create a new feature to reduce churn without sacrificing usability or current efficiency
Product design, product management, engineering, and account management
This app helps restaurant hosts manage everything on the floor: waitlists, diners, servers, sections, and tables.
The company I worked for acquired a front-of-house restaurant app in 2017. The app allows restaurants to assign diners to tables, and manage diners on the waitlist. Diners can waitlist remotely through the company's main app, or join through physical kiosks placed in front of restaurants.
The flow for changing shift assignments — servers and their restaurant sections — could take up to 20 minutes.
Hosts, or whomever is working at the front of the restaurant, control the flow of everything that goes on in their restaurant. Whenever they have to switch server shifts, such as opening, mid, and closing shifts, the waitlist needs to be turned off. The process required several taps per server, and had to be repeated for each sever coming onto the job. Here's what I'm going to cover in this case study:
Hosts needed a faster shift change process, so they wouldn't have to stop taking waitlist requests for too long.
The question became: how might we make this shift change process more efficient for the front-of-house (FOH) staff? The process below illustrates a high-level overview of how our team approached the problem:
The restaurant app was made for experts, which meant that it had to have as close to maximum functionality as possible for the FOH staff. I conducted a usability heuristic evaluation of the existing product, since it was my first time interacting with it. This allowed me to hypothesize where the pain points would be, which would help define my research plan.
In the beginning...
Originally built for instantaneous changes, the app didn't support a robust save feature for servers starting a new shift.
In one of our restaurant staff interviews, we found that shifts were often planned up to two weeks in advance. Although the managers knew exactly who should be working which tables and when, they still had to physically print out schedules for the FOH staff to input into the app.
The only thing that could be saved was a layout that divided groups of tables into sections.
Understanding the audience
We shadowed and interviewed restaurant staff who used the app on a daily basis to see how they currently handled shift changes.
Our design team of two was split between two cities: San Francisco and Chicago. In SF, my PM and I went to restaurants in our vicinity to interview hosts, restaurant managers, and other related FOH jobs in order to see what the process was like in action.
Servers whose shift started mid-day were affected the most, because several tables had to be traded or added.
We validated that restaurant shifts weren't as simple as a AM shift and a PM shift: there were "swing" shifts in the middle, often given to more experienced servers.
This meant that the host would need to reset the existing layout, select the server who just came in, and then tap on every single table that would be theirs for the new shift. Here's a rough wireframe to illustrate this:
Working with constraints
After learning that many hosts developed their own work flows for the app, we decided to explore ideas that incorporated familiar UI.
Originally, this was meant to be a two-week, straightforward project. After finding the problem was much larger than expected, we expanded the research and ideation time to include generative research, ideation, and user testing.
I had to keep in mind that all changes made to the app would affect all restaurants, not just the mid-sized ones we were initially targeting. Regardless of the solution we chased, we had to make sure it wouldn't negatively affect the smaller or more massive restaurants. (Note: Illustrations graciously provided by blush.design!)
Account managers in different locations validated that familiar UI would be preferred over something new.
As the main point people between restaurants and our company, they were a critical piece of the puzzle, playing an enormous role in helping us empathize with the restauranteurs.
It turned out that there was a lot of concern amongst restaurant owners in regards to a massive workflow change, because it meant that restaurant trainers would have to re-train all of their staff.
We took our ideas to restaurants to get feedback.
After exploring a few low-fi concepts, we ran two major rounds of user testing, with gut-check testing in between.
Exploration 1: Shift assignments as a tab
First, we tried UI that was totally new.
One thought was giving shift assignments their own tab; it lived in the "Sections" tab, which showed a live overview of the restaurant's tables and servers. In this concept, we tested a prototype that utilized a separate tab to create shifts, which acted as a schedule for servers.
This round of testing was cut off abruptly when we learned that adding a new tab wouldn't be technically feasible. More tabs were to be added to the app screen, and there would be no room for another one. So, we went back to the drawing board.
Exploration 2: Adding shift assignments to "load a layout"
But the familiar UI won our customers over.
Background story: After opening up the discussion to our full design team, we talked about the merits and demerits of not utilizing the tab feature. We had the hypothesis that having a separate tab would help create a better overall design. In general, there was an agreement that many aspects of the app promoted bad design, which forced users to create these workarounds.
However, the people had spoken:
"Yeah, this is exactly what we were looking for! It's the same thing, but with fewer steps."
— Regional trainer for a mid-sized restaurant during testing
This time, we went for a solution that nestled into the current workflow that mid-sized restaurants seemed to follow in general:
In the updated task flow, FOH staffers would have the same task flow with a slight difference, in that it drastically decreases the number of taps, thanks to the ability for the morning shift to save servers and sections. This way, all the host would have to do is load the saved servers and sections.
The tradeoff: Best practices vs. actual usage
We worked with existing workarounds, even if it wasn't considered best practice, because best practices actually decreased efficiency.
In the restaurant business, workarounds are inevitable. With the goal of helping FOH staff make the shift changes without having to tap dozens of times to assign new servers, we incorporated a solution into their existing user flow.
The truth of the matter was, bad design or not, servers and trainers had already engrained themselves in their personal user flows. Making an abrupt change would actually decrease efficiency, since trainers would have to start all over again and un-train the learned behaviors out of their employees.
Note: This feature has been shipped as of 2020.
Want to talk about other projects? Drop me a line at firstname.lastname@example.org.