Platform Creation  |  UX/UI Mobile Design  |  May 2016

GrubHub has monopolized on the takeout experience, completely understanding the delivery needs of restaurants. However, delivery and takeout restaurants are finding the need to be accessible from a variety of venues (Doordash, PostMates, Eat24, etc.) to help increase revenue. Since each one of these delivery platforms has its own interface, there is a need to consolidate the delivery service interface and the in-house POS system.

3.4 Ordering Screen 4 Copy.jpg


The Challenge

In 2 weeks time with teammates Shawn and Smriti, It would be our challenge to find a way for Grubhub to break into the point of sale market. However, we would discover later that breaking into POS sales would be a secondary opportunity. We knew that we wanted to stray away from featuritis, highlighting too many features and not focusing on the essentials that were needed. There were so many uses for this POS system, front-of-house and back-of-house, that focusing on a single aspect of the business would help us stay focused on the task at hand. We wanted to make sure we weren’t biting off more than we could chew.

(3 Photos Above - Investor Presentation Feb 2016)


The Process: Background Research

Screeners & Surveys

In conjunction with comparing our competitors, we also wanted to gather real feedback from users of in-house POS systems. We wanted to gather insights from people who have worked in the restaurant industry or who have used an on-demand food delivery service to see what feedback we could gather.

Over 4 days, we gathered 21 responses. Of the survey group, 76% had worked or are working in the restaurant industry. Of the total responses 82% percent had used an on-demand food delivery service. Only utilizing the screener would only be able to shed light on an aspect of what these users experienced. We had to delve a little deeper.

We asked some of the users to fill out a survey about their experiences. A major pain point that we noticed that stood out to us was that 80% of users said they had to split the bill more than they could count during a shift. Knowing this, we had to make sure our designs reflected an improved bill split option.


When trying to understand the purposes of an in-house POS system, we needed to brainstorm all of the features that the front-of-house employees would need it for. With Shawn and my experience combined, we were able to pull together possible topics that could be related to the system as a whole.

Competitive & Comparative Research

We starting with understanding the POS market as that would be the landscape we would propose Grubhub to enter. We began by investigating iPad POS systems, as we wanted to allow the staff to take orders at a table, as well as have the ability to process payment table side without having to leave. This inspiration came from my experience traveling to some European countries as well as Canada.

The iPad POS landscape was pretty vast, but we were able to narrow down our competitors to 7. Due to access to certain systems, as they were either payment or live demo (which could have possibly lead to sales inquiries down the line).

However, with deeper investigation, we discovered that there were multiple users for these systems — hostesses, waiters, bartenders, managers, kitchen staff. We knew we had to continue refining our focus for this project.

Technical Research and HIG Standards

Once we identified that we wanted to consolidate both systems, we really needed to understand the platform. So we proceeded to research the iOS Human Interface Guidelines. We knew we wanted to design for a platform that was in landscape view because what restaurants were already using were platforms like Micros and Oracle, that already have a landscape view. We were aiming to design something that wouldn’t completely introduce something new to users. We chose the iOS platform so that waiters could bring the tablets to the tables and potentially check out the customers at the table without leaving.

Technical Background Research PAGE 2.png

However, this wasn’t all. We needed to investigate the gestures that would be required for interaction as well as how we wanted to organize icons and design. We wanted to be able to enable the users to fast switch as well as multi-task in their high paced high volume environments. So we chose a tab bar at the bottom of the screen as well as scope bars so that users were able to filter and sort as easy as a tap.



The Process: Contextual Inquiry

Through comparing features of each POS system, we knew it was needed to see how users interacted with these systems. Our first location that we chose to investigate was Jack’s Sliders and Sushi. They were customers of a competitor of Touch Bistro, so we would be able to observe how the staff interacted with the interface as well as inquire how easy the product was to use.

What we found most intriguing is the multi screen layout that displayed each of their delivery platforms, each on a different tablet device. After the waitress took our order, she immediately left to take a phone call order. We watched her try to manage all of the systems on her own, while also multitasking the in-house dining experience as well. Immediately we knew she needed help.

Thankfully, the waitress shared with us that the restaurants need to have the multiple platforms because a singular delivery platform would not make enough revenue for the independent restaurant to stay in business. Almost instantly, we knew we could help.

We needed to validate our assumptions, so we explored different restaurants within the walking vicinity of Union Square that had delivery with Grubhub as well as dine-in. Our primary goal was to identify any inefficiencies and if we could design something that would improve them. We visited Roast Kitchen, Republic, Coffee Shop and Haru, as well as a pizza shop Talula’s, who used another iPad POS platform.

Once we arrived to each location, we started to notice a trend. When each restaurant would receive an order, it would populate within the Grubhub platform. The host or floor manager would have to print out the order and re-enter the order in to the in-house POS system. Each person we talked to said that their experience with the platform was inefficient and difficult to manage.



The Process: Ideation


Once we had enough data in our hands, we took to the white board. Placing features that we knew that would help operate a restaurant business. However, we had to prioritize our findings. So we placed our ideas on post-it notes and within the mapping, we organized the features as most important to least important and ranking of high effort and low effort of design.

Affinity Mapping

After deciding on the MVP of our new POS/Delivery app, we wanted to make sure that we identified trends to help dictate our fictional personas. We identified these key trends:

  • I need to be more efficient at work
  • I wish I had more control over how I work with Grubhub
  • I can’t focus on dine-in experience when I have to deal with too many delivery and takout orders
  • I update the menu regularly
  • I don’t use a system to track deliveries
  • More often than I can remember, I’m splitting the check

Persona Creation

Within our discovery, we identified a key demographic for target users. Our key demographic are mid 20s to late 30s who have worked or currently working in a restaurant with a mix of full time and part time. We wanted to aim our efforts at three specific users. The floor manager, hostess and waitress. We chose the floor manager as the primary user because we discovered that during our contextual inquiry the floor manager was main person managing the take out and delivery orders. For the floor manager, it is imperative for their restaurant to be operating at an efficient manner. The hostess would be our secondary user because not all restaurants utilizing delivery have hostesses. During our process we discovered that we should create a third persona that would be a user, the waitress.

Ideation & Sketches

The ideation process for the interface took many iterations. We wanted to make sure that we were not completely reformatting what the waitstaff was already used to. So we had to be respectful of the legacy of the operating systems before ours. So we took to our sketches.

We had to look at the functionality of the app. The primary filter that we used while designing and sketching was that this app needed to be functional. It didn’t need bells and whistles, it just needed to work. The app needed to be efficient and easy to use under high pressure and high volume.



The Process: User Testing

Once we had a functioning prototype, we had to test our hypothesis with certain scenarios.

  • Placing an order with multiple items to have the kitchen to start cooking
  • Multitask and address a delivery order that needs to be approved
  • Full checkout process for a table

Insights from User Testing

From our user testing, 3 of our 4 users were current resturant employees. We loaded our prototype on an iPad and placed it in front of the users, and after allowing them to take in the initial thoughts, we received the following feedback and implemented the changes:






Next Steps

After we tested our high fidelity wireframe, we knew that there were still outstanding issues to resolve for our next steps. So we categorized our next steps into short term, long term, and conceptual.

Short Term

  • Continue testing and contextual inquiry of use cases
  • Finish hamburger menu and setting menu
  • Review micro copy with marketing team
  • Begin designing portrait view for Grubhub POS

Long Term

  • Build a BOH interface system
  • Reservation API integration
  • Restaurant floor plan customization


  • Build feature to have different pricing for menu items that relate to time of day
  • Iron out inefficiencies with “add on” approval pricing
  • Scope out sales reports with system integration with Salesforce for business insights and individual performance
  • Scope out physical presentation for restaurants
Read the full retrospective on Medium