FinalPrototype-Group:J. S. & Associates
From CS160 User Interfaces Fa06
Contents |
Team Members
Jae: Anoto pen expert, Sushi restaurant connoisseur, development
Sung: Anoto pen expert, Sushi bar expert, development
Anton: GUI Implementation, Eclipse GURU
Suneet: Report compilation, GUI design, development
Johnathan: PDF Generator, Final Report Compilation
Problem and solution overview
Problem
The problem is simple. Ordering food in a sushi restaurant takes a long time, and time is money! Orders can take up to 20 minutes in larger sushi restaurants. By speeding this up, restaurants can hope to make more money by serving more customers per hour. There are a lot of factors that contribute to the inefficiency of the process. Chefs have to wait until a waiter or waitress brings them an order. During busy hours, waiters can't go to the sushi bar right after they have received an order because they have to get multiple orders and take them at once. Further more, sometimes chefs take a long time to read all of the waiter's orders, and often they interpret orders incorrectly. In a busy restaurant the process can be streamlined. When many orders are waiting, finding items that are common across those orders is necessary to quicken the process. A chef can make many of one item at the same time which will take less overall time then making all of those items separately. However, it is hard to find common items if orders are nothing more than a bunch of small slips of paper. This paper based system brings with it even more disadvantages:
- non-digitalized sales records – employee can steal money after trashing order slips;
- lack of statistical data of sales, inventory
- hard to analyze restaurant’s current situation or hard to predict future sales
- uncertainty as to when and exact amount of food materials to order from suppliers.
Solution
Our solution was to create a digital ordering system using the Anoto digital pen. The product allows waiters to take orders with the digital pen on intelligent order slips. When they are finished taking the order, the order is instantly tabulated and sent to both the cashier and the kitchen. In the kitchen orders are tabulated together so that chefs can easily prepare the same items across multiple orders at the same time, thereby reducing the time it takes to make an individual order. Cashiers can easily track their tables and orders and quickly print out accurate receipts. Let's break it down further by role:
Waiters/waitress – Fill out Anoto recognizable and pre-printed order sheet
Sushi Chefs – Sorted orders by table and grouped by common orders to speed up the process of the making food.
Sushi Restaurant Cashier – With the orders digitized, time is not wasted by entering purchased items into the machine, rather all payment information is processed and ready for delivery the instant the saiter/waitress checks the "send" box.
Statistical Package - A set of tools that allows the restaurant owner to observe and capitalize on all the latest trends.
Target user group
Since our problem and solution is well defined, our target user is the medium sized Sushi restaurant owner. When conducting all tests for our project we talked to a small sushi restaurant, and a medium sized restaurant. Our product appeals to both of those types of establishments. It however does not yet appeal to the much larger sushi restaurants or the ones that are parts of a franchise.
All parts and responsibilities that go into making a restaurant run had to be taken into consideration when developing our design. To further our target user group we defined several personas inside a typical Sushi restaurant that our product needed to cater to: water/waitresses, sushi cooks, and cashiers. Improving communication between these different user groups is the core competency of our product.
We decided to focus on these three personas becuase they are the main sources of frustration in a sushi restaurant: Waiters/waitresses need ways to communicate orders to chefs with as little confusion as possible. With our design, they take orders using the Anoto pen and paper interface and, upon completion, the order is instantly sent to the kitchen wirelessly. The chefs needs an efficient way of being able to see all orders that need to be filled. The interface we built allows them to see all pending orders in a first in first out queue on screen. Once the chef has delegated the tasks of filling an order, he instantly sends it to the cashier for further processing. The cashier needs a way of keeping track of who still needs to pay. Our interface automatically maintains and displays a record of all this information. The cashier additionally needs a way to process unique methods of payment, and our interface facilitates this.
Tasks
The following list of tasks represent tasks of varying difficulty that our system facilitates. We chose these tasks becuase they are some of the most commonly and routinely performed tasks at a Sushi restaurant, and we believe that if they can be done easily through our system them our system has passed atleast the basic standard of being better than existing solutions.
Easy:
The first task our application requires is for the waiter/waitress to fill out a sushi order form on a customized sheet of digital paper. The waiter/waitress writes the quantity of each sushi and roll that customer wants, identifies the current table at which they are sitting (this information is needed when the waiter/waitress deliver the food and bill to the customer), and checks a ‘Send’ box indicating that waiter/waitress has completed the customers’ order.
A second task our application supports allows the owner/cashier to view the total amount of money each table owes. This function will require software to optically recognize the number the customer wrote indicating the number of sushi rolls they wanted and convert it into an integer. Each integer will be multiplied by the price of the given sushi roll and summed up to reveal the total amount spent.
Medium:
Information on order forms that have been completed by the waiter/waitress will appear on the computer screen in which allows the sushi maker to determine the next table in line to receive their food. Once the food has been prepared and sent, the order form is removed from the queue and placed on a separate list used by the cashier for payment.
Hard:
A difficult task our application supports allows the owner/cashier to view the total amount of money each table owes. This function will require software to optically recognize the number the customer wrote indicating the number of sushi rolls they wanted and convert it into an integer. Each integer will be multiplied by the price of the given sushi roll and summed up to reveal the total amount purchased. Information regarding how much each table owes remains on this list until the customer has paid and left. All orders will be grouped by table number for the possibility of a given table ordering multiple times during one sitting. Additional functionality is added in case a single table wants to split an order.
Design Evolution
Our user interface has taken a lot of turns since we first began working on it. While some things have drastically changed, others have changed relatively little. It was during the group brainstorm, of course, where we came up with our original ideas. At this stage we were focused on saving the sushi restaurants money by providing a statistical package to be used to capitalize on all the latest seasonal trends, and providing a new order method that would cut back on employee costs. By allowing customers to order their own food using the Anoto pen and paper interface, the restaurant owner would not need to maintain as many waiter/waitresses to take orders. Here was our first idea of a food order sheet.
..........................
We were also concerned on how the food orders would be displayed to the chef. Here is our first draft of the sushiman menu. It was a big hit during the interviews and it fundamentally stays consistent throughout all of our iterations.
The next step in our design evolution was to conduct a contextual inquiry with our different users. This evaluation technique was probably the most valuable to us. Simply observing and asking questions as an apprentice gave us an incredible amount of information and direction to take with our project. We learned that restaurants were absolutely against replacing their waiters/waitresses with the pen. The culture of service that customers expect at a restaurant is part of the experience they are paying for. Moreover, we learned that a huge draw in of customers to these restaurants was actually the one-on-one relationship they had with the waiters/waitresses. This forced us to go back to the drawing board because the biggest selling point of our design was to get rid of the waiters/waitresses.
We decided to continue and learn more about the restaurant atmosphere and see where we could save owners money while allowing them to deliver the highly personable experience they are accustomed to. We learned more about the chef's line of work. There we discovered that there was usually a head chef that was in charge of delegating food orders to lesser ranked chefs. To our delight, the head chefs we interviewed were very pleased with our initial drafts of our chef interface and so our initial design ideas embodied all iterations of the project. An additional concern that was brought during the process was that there are many different types of payments that customers use, and often customers pay an order using more than one method. This brought up additional concerns regarding backing out of transactions, and unique methods of payment: separate checks per table, etc... With our plates full with these new concerns, along with our foiled original plans regarding our food ordering methods, we decided to put statistical computation on the back burner for a while. Though the restaurant owners liked the idea of having stats to monitor, other concerns regarding communication between waiter/waitress, chef, and cashier seemed liked the more crucial tasks at hand.
From there we took what we learned and moved on to the low-fi prototype. In order to test the usability of our design, we drew the prototype entirely up on paper. Here are some shots of our order sheet interface and chef interface respectively.
The waitresses were able to understand how to use our digital ordering system fairly quickly and ordering food went pretty
smoothly; however, we did catch a flaw in the design at this point. We encountered some problems with our design when a customer placed an order for item A, and then came back and decided to change the desired quantity of item A. This was a problem because the waitress would have already written a number in the box and since the system still use a pen, it would be difficult to erase the original quantitiy and replace it with a new one. We decided to attack this problem by not using handwriting recognition. Instead of writing the number of items desired, the waiter simply uses a tally system. This way he can come back to the order and add more items if desired. This still did not solve our problem of erasing a part of an order. Although this method was not ideal, considering the tools we had to work with at the time, it is a good demonstration of the power of a digital pen system used in a Sushi restaurant environment. We had success with the chef interface again but found flaws regarding ways to manipulate data when things go wrong. At this point we decided to add a "Clear" button to their interface. The cashier interface materialized well but users ran into some difficulties with deleting an order from the list after it was paid. Apparently they were used to the order automatically disappearing from the list upon payment. Interestingly they went back on their previous judgment when they realized that they needed to keep tabs on people who have paid but still sit around and chat. We therefore retained the "Delete" functionality
of our cashier design.
One thing that is glaringly missing from our design was the ability to create custom orders. The way our system is structured currently does not allow the user to request an item without a particular ingredient, or with any other special cooking instructions. The method we devised to implement this was to create a seperate sheet called a "custom order sheet" upon which a waiter could write any special instructions. This custom sheet would be tied to the order, and when the order is sent to the chef, the chef would have the ability to see the sheet entirely and read any special instructions.
Taking what we learned from the low-fi prototype we created our first hi-fi interactive prototype in Java Swing for the Pilot Usability Study. Below is a display of our improved order sheet, sushiman interface, and cashier interface respectively. This was how things looked immediately after we completed the Interactive Prototype.
Improved Order Sheet
Towards the final stages of our project, the hard part was just getting everything to function correctly between
our pen, paper, and Java interface. We were able to integrate our order slips well with our graphical interface. The order sheets lend themselves to this task well. One feature that was not present during our pilot study was handwriting recognition. An important part of the chef interface was a separate display of the aggregated sum of all the different food items from the entire queue of displayed orders. This is important because it allows the chef to prepare multiple orders at the same time. There were difficulties getting this to work properly for the Interactive Prototype but fortunately, we were able to hammer out most of the kinks for the Pilot Study. The cashier interface also improved since the time of the interactive prototype. We added the functionality of keeping track of the elapsed time from when the the order is served to the customers, to current time. We additionally added the field for subtotal and total for each order, as well as for all orders to a "Details" button. Previously, the "Pay" and "Delete" button were the only ones present. However, since we need to keep track of the elapsed time from when the order was served, we added a "Served" button to make this functionality.
Final Design
Ultimately the goal of our project was to showcase the way the Anoto digital pen system can attack conventinal paper based applications and provide a significant advantage. More specifically, our goal was to show how this system can improve efficiency and lead to more profit for owners of a Sushi restaurant. Therefore our goals with our final interface were not to create a very flashy, cool looking interface that could do anything and everything a Sushi restaurant might need. Our goals were more confined to the core tasks that Sushi restaurant owners tend to do the most often and the ways in which we can improve them.
In light of that fact, our project really contained three main interfaces as outlined above. Lets start with the paper interface that waiters use to take down orders. Our paper ordering slip allows a waitress to quickly tabulate orders. One flaw that it contains is that if a waitress accidentally records too many of a certain item, she has no easy way to erase this mistake. She must start a new order sheet. Also we came up with a good idea to allow custom orders but did not implement it. The idea is that there is a seperate region on the paper, or a seperate sheet alltogether where the waiter can writen down special instructions. These instructions will be stored as an image and displayed to the chef as part of the order.
The chef or kitchen interface is one of the interfaces that aggregates all of the order data. It allows a chef to see on the left pane how many of each type of item need to be made. It also allows the chef to look at orders as they are coming in, and he can click on a specific order for more details. This is where we would have implemented the special instructions section. Chefs also have the ability to click on an order and set it as finished or made. This updates the totals of the aggregated item counts on the left pane. This interface was puropsefully kept simple and color coded so that the chef can look at it from far away and quickly see the critical information.
The third interface was the cashier interface. This interface allows the most essential tasks that a cashier must perform. He can see the current orders and tables, and can quickly pay an order, and the delete the table or order entirely from the visible set of orders, essentialy denoting that the customer has paid and left. The cashier also has the option of looking at individual items ordered in a table, and splitting up orders on a table.
A side package that we implemented along the way is general statistics. From this window, the owner can see a variety of sales and performance statistics that would be useful for fiscal planning. Because of the object oriented nature of the interface, the statistics are always up to date and are fine/specific enough to record data about individual items.
