InteractivePrototype-Group:J. S. & Associates

Waitress -> Takes an order -> Goes to Sushi bar to place an order -> Goes to cashier for record -> Waits -> Gets the food -> Serves the food -> Waits -> Goes back to cashier -> Gets receipt -> Goes back to customer

Sushi chefs have to wait until a waiter/waitress brings in an order. During busy hours, waiters can't go to the sushi bar right after he or she received an order because they have to get multiple orders and take them at once. Sometimes sushi cooks take a long time to read all of the waiter's orders, and often they interpret orders incorrectly.

Unorganized Food Making Process:

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 with the existing system because orders are written on many small papers.

Absence of Management System for Sushi restaurant:

Here are some more disadvantages to the current system:

non-digitalized sales record – employee can steal money after trashing order paper
lack of statistical data of sales, inventory – hard to analyze restaurant’s current situation or hard to predict future sales because all the record is on paper (do not know when and exact amount of food materials to order from suppliers)

[edit]

Solution

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.

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.

[edit]

Tasks

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.

Medium:

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 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 incase a single table wants to split an order.

Hard:

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.

[edit]

Revised Interface Design

[edit]

Changes As a Result of Low-fi Testing

The results we got revealed that our interface needed work in the area of errors and corrections. The sushi chefs had trouble correcting their mistakes, as did the waitresses when given orders in non quantity format. This is clearly affect the way we have further developed the interface. This once again shows how user interaction can reveal simple yet elusive interface faults.

Chefs:

We added onto the chef's num pad to improve feedback and correction. In order to do this we added a "Clear" button. We were conflicted whether we should add a "Clear" button or "Backspace/Delete" button but we decided that "Clear" would be best because of several reasons.

First, the order number is at most 3 digits. Backspace type correction only benefits the user when there is a large amount of data already inputted, and he does not wish to clear it all off and retype. However, from personal experience, users often backspace to far and have to figure out how to replace a few letters. In large contexts, this is a reasonable cost, but in a 3 digit interface it is not.

Second, the order punched is most likely not one or two incorrect numbers, but the entire number. This means that in most cases, the user will have to hit "Backspace" two or three times, which is a waste.

Implementing both clear and backspace increases complexity needlessly, thus we have chosen to add a clear button.

A side issue that came up during low-fi prototype was the lack of visual feedback given to the chef when he inputed the order. One solution is to allocate a small box on the screen that holds the current digits inputted by the chef so he knows exactly what is going into the system. Another is to make an order light up or get outlined when the order number inputted matches one of the orders on the screen.

In the case of the feedback box, the chef would have to shift his attention away from the orders, which may slow him down. However, instant input is given which lets him correct earlier. This may be more useful for training chefs rather than veterans, since the speed at which they do their job right now is amazingly fast. It is not unlikely that the master chefs will be raking the num pad at lightning speed, eliminating any sort of interrupt input that the feedback box may give to stop them and correct an error.

Because of this, the light up order was the better solution. This of course was implemented to be fast, as the chefs would definitely not want to wait for feedback any longer than they should.

Next was the case of undoing an order. As an interface decision, the first easy clear choice was to simply add an "Undo" button, which simply brings back the last order that was deleted. We isolated the undo button away from the rest to reduce mistakes.

Waitresses:

During the Low-fi prototype, it was nice to see that the waitresses enjoyed the basic interface. One of our main concerns was that it was too large and bulky, and although they expressed some grief on that, it was not as big an issue to them as we had thought. Since categorization aided in this, we improved order sheet by making it smaller and more efficient.

We did not anticipate the problem with non quantity orders. The simple solution for this was to write on the side of the paper. Although it is very low tech, it is objectively a good solution. It is very similar to what the waitress would do on a regular piece of paper, which makes it highly intuitive. See figure below for new and improved order sheet.

[edit]

Unimplemented Portions of Interface

Computing statistical data was the largest area we left out. Our current ideas for what the data should look like are posted below.

[edit]

Storyboards of Tasks

Our system consists of several features:

1. Digital menus and Anoto pens used by waiters to automatically tabulate orders and instantly send them to the kitchen.
2. A screen that will be used to display to chefs what orders are coming in. These are used currently in fast food chains.
3. A screen that will display pending orders that need to be payed for.

The following image is a simple representation of these 3 components of our system.

Waiters/waitresses will fill out the order sheet using the annoto pen. The software designed for this system will be used to tabulate orders currently arriving in real time. In a sushi restaurant this is a very useful thing because it allows the chefs to streamline the cooking process by preparing multiple items at once. After making each order, sushi chefs can remove the orders from the screen by using numPad. Sushi chefs usually do not have much time to use mouse and keyboard in order to delete the orders because he or she should make other orders. However, sushi chefs must have the interaction of the program to remove completed orders. So using numpad, simply typing the order number to remove the order, sushi chefs can achieve the task very easily and fast. After the order is delivered, it will be transfered the cashier's screen and await payment.

[edit]

Prototype Overview

[edit]

Overview

Our prototype is thus far composed of three interfaces. The first is an order sheet used by a waiter or waitress, see Figure 1. below. Its design is the cross between the types of order sheets that are already familiar to food providers, and menus used by customers. Order sheets come in stacks, like post-it notes, and have their order numbers preprinted on them. Likewise, our order sheet has a preprinted order number on it. A box for table number is filled in by the waiter/waitress and used to identify the destination of where food is to be delivered. All the boxes next to the names of food items indicate the places where the waiter/waitress fills in the quantity of items ordered. Ideally handwritten recognition will be implemented so that the waiter/waitress only needs to worry about filling out the order form using numerals 0-9. After an order is filled, the waiter/waitress checks a "send" box that sends the order to the sushi man.

The sushi man has a separate interface that displays all pending orders in queue fashion, and a comprehensive list of all food items to make for all given orders that are visible, see Figure 2. below. In order to update his list, he only needs to click the "done" box and the queue will update and advance.

After the sushi man clicks "done" the order gets sent to an interface used by the cashier, see Figure 3. below. This interface displays all pending orders that still need to be paid for. Each entry displays the table number, amount owed, a "details" button that displays a break down of each item ordered along with its cost (see Figure 4. below), and a set of options that allow different methods of payment. These options allow the bill to be paid as is, or split into two payments. Once split the cashier has the freedom to merge the two bills. The order hangs around once its been paid until the cashier manually deletes it.

[edit]

What Was Left Out and Why

The interface that displays all computed statistical data was the largest area we left out. Though we find that computing statistical data is important for a business to run efficiently, we did not find it as crucial at this stage of the prototype as the tasks we focused on. All three tasks we have focused on thus far are undeniably necessary for our system to be of any use to a sushi restaurant. A manager can get by without knowing the number one hottest sushi roll sold in July. A manager, however, can not get by without means of communicating food orders to the cook and cashier.

[edit]

Wizard of Oz Techniques

The areas of the project that demanded Wizard of Oz techniques the most were those that were dependant on handwriting recognition. Normally the waiter or waitress would simply write a digit indicating quantity in the box that correlated with which food item was ordered. Since an available handwriting recognition package has still not been found, we needed to resort to tallying the quantity of desired food items by adding up consecutive taps to the given food quantity box.

[edit]