Journey map for a table lifecycle
OVERVIEW
About the project
During some downtime at the end of the year, I chose to spend time preparing for enhancements I knew were on the roadmap. But I noticed that the product needed to be reimagined before it continued to be enhanced. I collaborated with another product designer, a content designer, a lead engineer, and a project manager to update the product as well as build out the already planned feature enhancements.
The problem
As a former server myself, I quickly identified improvements we could make to truly serve our end users. The original product was designed with input from restaurant managers rather than servers who would depend on it to do their job. This led to confusing hierarchy, or lack thereof, and inability to work at the speed servers need to move at.
The goal
Allow servers to work more efficiently and confidently while reducing errors. To do this, we decided to improve the table statuses, add landmarks to help servers quickly orient themselves on the POS, and surface "quick actions" on the floor plan.
Responsibilities
User flows, competitive analysis, visual design, and usability testing
Tools
Miro, Figma, UserTesting.com
Original POS
The initial launch of the restaurant POS provided servers with only the essentials: table numbers, location of tables, and the number of guests seated.
Empathize
EARLY DEFINITION
Before getting into any UI, we developed a shared understanding of how we wanted to approach the problem through definition exercises:
Journey mapping
Empathy mapping
High-level user flows
Empathy mapping
Although I personally had several years of experience as a server, I asked all Clover employees if anyone else had server experience. My co-workers who had experience as a server at one time or another in life helped me create a holistic view of what a shift for most servers looks like.
I asked them to review the empathy map I'd created and to fill in any areas they felt were missing. This way I was able to encompass tasks and pain points across different types of restaurants that I hadn't had exposure to myself.
Empathy map for servers
Findings from mapping exercises
Referring to the map artifacts, we identified some key pain points of the current POS experience.
We weren't showing servers the most useful information about their tables.
We were not supporting relevant actions for the full-service restaurant context such as "Fire next course" or "Print bill" from the floor plan home screen. Instead, servers were forced to tap on a table and go to a separate page to take any action.
COMPETITOR ANALYSIS
Evaluating where we stand as well as where we can differentiate ourselves
There are several restaurant POS systems on the market today. Understanding the common patterns among them helped me assess how Clover compares to similar products.
Not only was this a helpful exercise for evaluating the current landscape, but I wanted to also incorporate beneficial, recognizable patterns to speed up the training process for servers and managers. We recognize that high turnover in the restaurant industry is common, so implementing common patterns could help new servers get comfortable with the POS quicker if their previous workplace used a different system.
Ideate
Sketches
I began the design process with low-fidelity sketches and wireframes to accelerate decision-making through visualization without losing time. My sketches were based on the mapping exercises, enhancement requests, and conversations with friends of mine who are servers. The sketches and (somewhat higher fidelity) wireframes were created to brainstorm different ideas and facilitate discussions between design and product.
At first, I thought we could add some of the most frequent actions servers take such as 'Pay' and 'Print bill' launch from a menu when tapping on any table (second image). But I instead moved into using a drawer so that the server could see a summary of the order when taking their next action to increase confidence. This also helps keep primary actions located in the same place on the screen since we know speed and muscle memory are key to a server's experience when using a POS system.
Continuing to iterate
Since there wasn't much table-level information on the floor plan in the first place, we had to make hard decisions on what we should include on the floor plan view.
To help make these decisions, I wrote out what the purpose of each component should be and from there we removed any information that didn't align with the purpose.
Solving design problems
PROBLEM #1
A server's shift can already be chaotic, but the POS they use shouldn't be
The original floor plan screen provided the server with serval statuses, but the hierarchy or the statuses was out of line with the priorities of a server.
Tables that had been seated for over 90 minutes were bright red despite there not being an error or any action the server could take to remedy the overtime table.
Other servers' tables were not de-emphasized and showed information the server didn't need thus adding to the mental overload.
The 'Paid' status was one of the most prominent although that table needs the least amount of attention.
Solution: Provide the most helpful statuses and add landmarks
The floor plan is the server's homepage on the POS. It should help servers track what's next and provide an overview of their section.
We started by removing all statuses and information and only adding back what servers needed to get a complete overview of their section.
Also, to help increase confidence when coming to the floor plan, we added the ability to add landmarks such as walls and customizable objects. This increases the server's ability to make visual connections to identify the table they need to address even if they are unsure of the table number.
Adding landmarks had been a long-time request from clients, but it wasn't prioritized until we communicated to product managers just how valuable it'd be for our users.
PROBLEM #2
Every time a server taps on a table from the floor plan, they are shifted into an entirely different context
Even though a server may need to simply print a bill for a table, they had to go to an entirely new screen that was focused on building an order.
This context shifting was originally intentionally designed this way to keep a server focused on the table they were servicing. But we know from our empathy mapping exercise that servers are constantly multitasking and usually taking actions on multiple tables whenever they come to the POS.
Once a server was taken to the table's page they need to take an action on all of the actions were presented in one sheet. Some are used more frequently and others on very rare occasions.
Solution: Surface the server's likely next action
We should meet our users where they are during a table's lifecycle and surface their next action - no digging required.
Using the mapping exercises from before, we knew which actions a server would most likely take based on the status of the table's order. If the first course was fired already, we could surface the CTA to fire the next course ultimately allowing the server to work more quickly.
And instead of going to the order building page as it was originally designed, now the server can see a summary of the order and the assumed next action without leaving the floor plan.
Basic flow including list of tables that belong to the server, a brief order summary for selected table, and updated order building screen.
Test
Usability Testing
I created a fully-functional, high-fidelity prototype of the new flows using Figma. Note that these updates were included in a research effort to also test a new feature, Auto Coursing, since the two were closely related.
We started recruiting subjects for the test who fit our criteria. We did 5 usability tests with Clover employees who had server experience and 4 through UserTesting.com after iterating on the issues that we identified:
takeaway 01
Updated statuses and new quick actions were working as we'd hoped
Participants were consistently able to interpret the table statuses with high accuracy. The addition of course statuses, timestamps indicating when items were fired, and the smart quick actions were received positively.
takeaway 02
Control is very important
Participants thought the suggested quick actions were exciting, but they also stressed the importance of being able to quickly get to other actions in case they needed to reorder a round of drinks after all food items were fired.
Research synthesis after testing to highlight key takeaways
Next steps
These updates are being implemented in multiple phases. So far the floor plan UI updates and landmarks have been released and received extremely well. Before making the larger changes such as the new order summary drawer on the floor plan and smart actions, we want to do another round of testing specifically focused on those changes while engineering completes related back-end work.
01
Launch usability tests where the quick actions are more thoroughly tested since it was not the sole focus of the prior research. I wrote the test script for when we are ready to begin recruiting and testing.
02
Iterate on the design based on the additional research and address unique edge cases.
03
Pilot reimagined POS to a small group of merchants and ask for feedback once servers have used it in the environment it's meant to be used in.
LEARNINGS
Before enhancing on top of existing functionality, zoom out and consider how you'd design the ideal experience without the product requirements and technical constraints. Even though it's important to consider those factors, they shouldn't be the dominating force in product design - the user's needs and environment must be prioritized to create a successful product.