Fun Facts
  • I played soccer for 25 years. If my knees allowed I would still be playing. My new interest is bouldering. 
  • My favorite song is Into Dust by Mazzy Star. It’s hauntingly beautiful. 
  • I can wiggle my ears simultaneously and independently.
  • I listen to 417 or 528hz frequencies to calm my nerves and help me focus.
  • My comfort show is How I Met Your Mother. I’ve re-watched all 9 seasons 4 times.
  • I met Dwayne “The Rock” Johnson when I was 8 (I was a WWF fan. Don’t ask me why.) He signed my beanie baby. 
  • If you met me before the age of 22 I go by and refer to myself as Lizzie.
  • My ideal retirement plan is to own a ranch near the mountains where I rehabilitate and train dogs who have been abandoned or abused. 
Oct 2020
Case Study

Understanding a POS System

I was chatting with a friend who works for a company that is in the process of establishing cloud kitchens and we somehow fell down the rabbit hole of POS systems for their internal use. Naturally, my curious mind led to a lot of questions. What are cloud kitchens? How does a POS system come into play? Having never worked in the restaurant industry and only recently learned of the cloud kitchen concept I decided to investigate a little further.

I did some research on the concept and spent a couple hours creating a basic mockup to answer some of the problems my friend's team is currently facing.

This mockup is the result of my design process and not in anyway associated with my friend's employer. I took creative license when it come to design assumptions and needs.

  • 6 hours
  • Figma
  • UX skills
Basic Research

What is a cloud kitchen?

Cloud kitchens are commercial kitchens built for the sole purpose of food delivery. There’s no wait staff or patrons, just the cooks; a concept that has exploded since the rise of COVID.

 

These kitchens host either one restaurant group that runs several food brands or several different restaurants. They pull orders from all types of aggregates including third-party delivery systems like UberEats, Wolt, Foodora, and sometimes the actual brick and mortar restaurants themselves. The goal is to be more efficient from an economical and logistical standpoint.

 

Cloud kitchens remove the logistical headache of timing food delivery while attending to in-house patrons for many brick and mortar restaurants. It also lowers the barrier to entry for those looking to break into the restaurant industry but don’t have the capital to start with their own brick and mortar. 

 

Sidebar: if you want to check out one of my favorite “cloud kitchens” that is customer facing, check out Aster Hall in Chicago. It has some of the most delicious eats surrounded by beautiful art deco style interiors.

What is a POS system?

POS stands for point of sale and it’s the system where a customer purchases a product or service at your store. It’s very common in the restaurant and retail industries. In a fast food restaurant this system is typically in place when you pay at the counter. In sit-down restaurants it might be used behind the scenes after the server takes your order. Or, in some restaurants, at the table where the customer gets the change to interact with the system directly. So how does this relate to the cloud kitchen, which doesn’t directly involve customer to server ordering?

 

Well, POS systems in these scenarios have to account for incoming orders, organization of those orders and the processes involved from accepting the order to dispatching it for delivery.

 

In addition it might include business metrics like sales, inventory and the like. From my research I found most of these systems tend to lack functional and aesthetically appealing designs. I think this might be (in part) due to its user base being business-focused, not customer centric. In other words these weren’t designed with optimal user experience in mind because the end customer isn’t the one interacting with these systems directly. However, with the rise of UX-UI design and businesses beginning to understand how valuable a well designed system is – not just for customers, but for internal use.

Project Brief

Here's what I did

My friend explained three primary challenges with their current interface (which will remain private for obvious reasons). Granted, we could not go into very specific details so I held a lot of assumptions in this case study.

  1. The chefs need to be able to see all incoming orders in the queue while looking at the current order, which must list out all ingredients and special notes. Bonus if the interface can support the chef working across multiple orders at once.
  2. The chefs need to be able to prioritize incoming orders and begin working on direct-from-restaurant orders first.
  3. Each step needs to associate with an output that sends an update to the customer. For example: when a chef accepts the order, begins working on the order and dispatches the order there should be an actionable task from the chef that sends an update to the customer.

One thing worth noting is that while I made some conscious UI decisions (particularly type size, button size and color, which I’ll explain  later on) the UI was not the sole focus. I gave myself a time cap of 6 hours and during that time I focused on researching a POS system, cloud kitchen processes, and layout and functionality of the software to address the three challenges stated above. A follow-up to this case study might involve a deeper dive into the UI elements. 

Challenge No. 1

  • Optimize layout so order queue and current orders are both visible

I decided to make maximal use of the screen in a way that follows the same natural path we take when reading: left to right. In this case the setup is arranged in a way that information goes from the more general to the more specific as you move from left to right. 

I decided to make maximal use of the screen in a way that follows the same natural path we take when reading: left to right. In this case the setup is arranged in a way that information goes from the more general to the more specific as you move from left to right. 

The navigational panel on the left hand side allows for quick easy access when needed but does not impeded the scroll functionality that is necessary for a long order queue or list. 

As you move onto the middle portion of the screen, this contains the order queue: both orders that have been accepted (as indicated by the start button and time set to remaining) and those waiting to be accepted (indicated by the accept button and time counting upward). Within this panel the chef will be able to organize the orders in a variety of ways which will be talked about in the next section.

Finally, on the far right is the current order view, which contains the list of ingredients along with special notes. Chefs can swap back and forth between active orders by hitting the order tabs at the top of the screen. This allows chefs to batch orders together, which is helpful when fulfilling orders that have the same item(s). A circular checkbox allows the chef to keep track of what has been completed with a simple tap and what is still pending within the order. 

Color is used to draw attention to necessary items, such as new orders coming in as indicated with a bright blue ‘accept’ button or time remaining on an order until it needs to be dispatched as indicated in red.

Challenge No. 2

  • Prioritize incoming orders

My first thought was that the software itself can handle the algorithms needed to prioritize incoming orders so that orders directly from the restaurant are listed first while third-party aggregates like Foodora come second. However, I can understand how there may be a need for this to be done manually, or over-ridden by the user. 

For example, let’s say there’s a couple orders in the queue from Foodora. Suddenly, it’s dinner rush and an influx of orders direct from the restaurant come in. This would push the existing Foodora orders to the bottom and perhaps increase the wait time for the customer past the threshold of acceptable waiting times. A manual override would alleviate this. 

Plus, manually prioritizing requires the chef to pay attention to incoming orders and understand the entirety of the order queue, perhaps making it more difficult to overlook an order.

My first idea for this problem involves a simple drag and swap function. The chef can simply press and hold the particular order they want to move and drag it up or down in the order queue. However, swiping functionality might not always be feasible for a chef. While touch screen technology has greatly improved, gloves or greasy hands can make this function challenging. 

 

An alternate solution might involve a tap or hold on the order item, which expands to an up and down arrow, allowing the chef to tap up or down for movement (no swiping involved). Another tap closes the arrow box.

A third option is that, a chef can accept an order anywhere in the queue at any time, which would automatically move the order up in line, just below that last accepted order. This way, the chef can easily prioritize by which orders she accepts first. This would be the quickest way to prioritize, while the other two methods would allow for alterations after orders have been accepted. 

The swiping ability is something that could be easily flushed out with user research, i.e. talking to chefs who work with digital systems in the kitchen.

Option 1: drag/slide orders

Option 2: tap and move with arrows

Challenge No. 3

  • Actionable steps that provide the customer with updates

There are three actions the chef completes throughout the order process that send periodic updates to the end user.

First, a chef accepts an order. While it’s unlikely an order would be rejected, the option needs to be there for the extreme cases, i.e. inventory runs out or someone gets sick and orders cannot be filled. While an order is waiting to be accepted, a clock runs up to let the chef know how long it’s been sitting. I imagine a timer goes off at some point to alert the chef to an order that has been sitting for too long or automatically bumps the order to the front of the line. Once the chef accepts the order, a modal pops up for the chef to input an estimated time until dispatch (food is made and ready for delivery/pick-up). At this point an update is delivered to the customer with the estimated time frame. 

After accepting the order, the clock begins to run down in red showing how much time is left until the chef is supposed to dispatch the order. The chef then starts the order by tapping the ‘start’ button. At this point another update is sent to the customer and the order moves out of the queue and into the current order section on the far right.

Finally, the chef fills the order (using the circular check boxes if needed as a guideline of what’s completed and what remains to be filled). When the order is complete the chef hits dispatch, which sends another update to the customer letting them know their food is ready for delivery or pick-up. 

I can also see an algorithm automatically tacking on time to the orders based on estimated delivery by pulling the user’s information. However, this was not be something expected of the chefs to include in their estimated time frame. 

Step 1: accepting an order

Step 2 + 3: starting and dispatching an order

Evaluation

I enjoyed this challenge because I was able to familiarize myself with a system I knew little about, yet one that is vital in a growing economy. I would have loved the opportunity to chat with real chefs who work with POS systems to learn more about their behavior and user experience journey. 

Uncovering more nuances about their work routines would help flush out the fine grain details for this system. Regardless, even though this was a surface level exploration, it was still very informative. 

I’d also like to go back and spend more time on the UI elements. As stated above, this was not the sole focus of this exercise and I left little time for UI decisions within my six hour time cap. Initially, I was using the blue and red as branding ‘guideline’ colors. However, I would change around some of the color usage so that it’s more effective. For example,  I’d use a soft black for the active icon in the navigation panel instead of red. I’d also consider changing the red in the order tabs on the top right hand side of the screen. There’s no need to draw attention to these specific elements and I think they are ultimately distracting. 

Other elements I’d love to test in real use application would be the size of the buttons and type. Depending on how close – or far – the chefs are standing from the tablet makes a big difference.

Overall, I was going for a clean – distraction free look. Chefs in these environments are working fast to fill orders and there needs to be limited distractions and plenty of visual hierarchy to help the user quickly find information.  While there are areas that can be touched up, I think this layout, for the most part, achieves this while addressing the three major challenges at hand. 

This was a great study that definitely put me in the mindset of a user I had very little experience with before starting. I enjoyed uncovering the challenges and pain points a chef might face in the kitchen with a digital system like this and hope to expand on it in the future.