LoFi-Group:J. S. & Associates
From CS160 User Interfaces Fa06
Contents |
Role of Each Team Member
Jae: Interviews, Prototype Brainstorm and Synthesis, Images, Results, Data Collection
Sung: Interviews, Prototype Brainstorm and Synthesis, Images, Results, Data Collection
Anton: Prototype Brainstorm and Writeup, Discussion
Suneet: Method, Results Writeup, Final Compilation
Johnathan: Prototype Brainstorm, Intro and Mission Statement, Demo Script, Consent Form
Introduction and Mission Statement
We are implementing a system that automates the sushi ordering process. The Anoto pen is used to wirelessly and instantly send food orders from waiter/waitress to the chefs in the kitchen. The system additionally computes statistical data and processes customer payments. We therefore have three sets of target user groups: waiters/waitresses, sushi chefs, and cashiers. The rational behind the experiment at this stage is to obtain feedback from the different user groups. Areas of concern we hope to improve are: visibility of the provided interface, ease of navigation through the different services provided by the package, and adaptability to what systems are already in place.
Mission statement – To improve the efficiency of sushi restaurants and thereby increase profits by providing a fully implemented sushi ordering system; this system improves efficiency by: (1) simplifying the food order forms used by waiters and waitresses; (2) shortening the duration from when orders have been placed to the time food is delivered; (3) recording statistical data which can be used to monitor and improve sales in the future; and (4) providing functions cashiers can use to process customer payments.
Prototype
Overview
There are three types of user groups for our project: chefs, owners/cashiers, and waiters and waitresses. There was only one task that was designated to each type of user.
Sushi Bar Interface
Basically, this interface is for the chef to delete an order after completing anorder. Each order can be seen explicitly with the order number on top of each table of orders. The tables on the left of the screen are for displaying overlapping ordered items so that a chef can make them together more quickly; however, for now the chef doesn’t have to worry about this. To delete an order on the screen, we use a common numerical pad. By entering the corresponding order number and then pressing enter, a chef can delete the order. We can see this with a particular order removed on the next screen (order #12 removed in this case).
Cashier Interface
This prototype is for the cashier (either a dedicated cashier or a waitress that operates it) to go through the process of printing out a check for customers on a particular table and then deleting the table on the cashier screen that corresponds to that table number. Each table on the cashier screen is colored red, yellow, or green. Red means the customers have not requested their check yet. Yellow means the customer has requested a check, but has not provided payment yet. Green means the customer has paid and the table is ready to be deleted from the cashier screen. Also, there are buttons on each table with labels “Print Check,” “Received Payment,” and “Delete This” for red, yellow and green tables respectively. The button with the label “Print Check” appears when a table is red because red means the customer hasn't received their check. The button with the label “Received Payment” appears when the table is yellow, and the button with the label “Delete This” appears with green tables. This particular prototype requires the user to start from a red table to print out a check, give it to the customer, bring back the payment, and delete the table off the screen. Starting with table #7 which is in red, the user must click on the “Print Check” button. Then the table changes status to yellow and the check is to be printed out. After the user hands the check to the customer and receives payment, the user must tell the system that he has received payment. Then the table changes status to green. Now that the customer has been adequetly served, the table is ready to be cleared off the screen. After pressing the button “Delete This,” the table is removed from the screen as you can see below.
Waiter/Waitress Interface
This prototype is for waitresses to write down orders from customers on the order slip and make use of the additional item slip. The tasks must be carried out with some care since the order of steps required needs some attention to detail. First of all, we start with what looks like a normal order slip in a sushi bar, with the exception of a “Done” check box at the top. After filling out the Table number in the Table# box, the waitress is to write down how many of each item are ordered on the box next to the corresponding item name. After this there comes an “additional item sheet,” which serves the purpose of adding or subtracting subsidiary stuffs to or from the items ordered, such as wasabi, sesame, spicy sauce and so on. This sheet is for “each” item ordered. The waitress must denote the table number on her order slip, which also has to be same as the one on the main order slip. The order sheet contains two sections categorizing the food items. These two boxes ask the waitress to specify which category of food does the custom instructions belong to. For example, when if a customer orders Dragon “Roll” and wants no wasabi in it, the waitress should first check the box with label “Roll.” Remember, the waitress should never check both boxes since this the waitress must use a seperate "Additonal Item" sheet for each item that is being customized. There is a box to the right, saying “Item.” This means the waitress should put that particular item number. For example for the dragon roll, the waitress should put 1 there. The box labeled “Q,” is to indicate quantity. So for example, if a customer orders 2 dragon rolls and wants no wasabi in both of the dragon rolls, the waitress must write down 2 in the quantity box. Remember, the number written down in the Q box should not exceed the number of that particular item ordered. The boxes on the bottom are just to add or subtract the subsidiary items to or from the main item, which are indicated by + or -.
Method
Participants
In the previous phase of our project we decided to interview two sushi restaurants of different size. We went back to the same restaurants because we have now developed working relationships with them. Just like before, one restaurant was slightly smaller having about 14 tables. The other restaurant is much larger serving just over 35 tables. The owner of restaurant A, the smaller one, had about six years of experience running his restaurant. Restaurant owner B of the larger restaurant has 20 years of experience and owns 2 different sushi bars.
From each restaurant we spoke to a cashier, a chef, and a waitress.
Environment
To understand this project better you need to gain an understanding of Sushi Bars. A Sushi bar is a high-volume low margin business. They really have an emphasis on worker productivity so that during rush hours they can serve as many people as possible with as few employees as possible to maximize profit. During busy hours the kitchen is a stressful place. There are often multiple chefs and they are often doing redundant tasks. There is a lot of room for optimization. On the other side of the restaurant, where customers sit, customers really want quick service. They also hate to deal with hassles of misplaced and incorrect orders and long waits. The goal of this system is to try and reduce the time a customer has to wait for his order, increase the amount of orders fulfilled, and ultimately run a more efficient and profitable business.
Tasks
Ultimately the specific tasks we designed were picked to closely mimic the entire process of a customer coming to a sushi bar. The process contains all of the participants mentioned above: waitress, cashier, and chef. Typically a customer comes and is seated at a table. That's when the waitress steps in and takes the customers orer. This is the first point where our system comes in. The waitress uses our system to instantly transmit the customer's order to the kitchen. There the chefs use the system to receive tabulated orders and start preparing the food. They are also responsible for designating what items go to which table. The waitress also comes in and delivers food to her customers, and finally when the customer is finished, the waitress walks over to the cashier and uses the system to automatically print the customer's check.
Now that we have seen an overview of what our ideal system will look like, lets take a look at the specific tasks we decided to enact.
Chefs
The easiest task was outlined for the sushi chefs. They simply had to pretend that they had finished making an order for a customer and delete the order from the interface. When the system is implemented, they may be able to do this using a touch screen, but for now we asked them to pretend to use a numerical key pad and then press a delete button. We gave them a script instructing them of the process to delete/clear an order:
1. Make sushi as shown through ordering system
2. Organize sushi by table for waitress
3. Delete the completed order by 1) entering order number 2) pressing delete
Cashiers
Anoter set of tasks we defined were for the cashier interface. Some sushi bars have a dedicated cashier and this person would be operating this interface, while in other restaurants the waitresses fulfuill this roll at the end of their orders. This task was simple: the cashier/owner or waitress needs to print a check:
1. Print check
2. Receive payment and record it is paid
3. Delete paid table
We simply drew an interface by which they could select an order and print a check. Then through magic they received a check, and were given another interface through which they could record that an order had been paid for. They finally saw a third interface that allowed them to select an order by entering its number, and then deleting it from the record.
Waiters
Our tasks set-up for waiters were slightly more difficult than the others. We wanted the waiters to practice taking down orders. We found it to be difficult because it required some slight retraining of an otherwise deeply engrained practice. They had to get used to tabulating the total amounts of individual items, and they also had to learn a new method of taking "customized" orders. That is, orders that have special instructions like different ingredients, etc.
We asked them to perform two specific tasks:
1. Take down a normal order that doesn't require any special instructions
2. Take down a highly customized order
More details about all the tasks mentioned above are in the results section.
Procedure
Our procedure for evaluating each task was relatively simple and largely the same for each task. We first explained to the waiter, chef, or cashier exactly what the task we were measuring was. We explained to them that we had drawn mock interfaces and that they would have to use their imagination and follow the steps outlined for them and to pretend as if they were actually doing the task assigned to them. For example, the chefs were given a paper showing an interface with orders. They proceeded to simulate making food, and then simulated pressing a keypad to delete an order. The waitresses were given simulated order sheets upon which they took down simulated orders, and the cashiers used simulated interfaces and pressed simulated buttons to simulate completing an order. The procedures for each individual tasks are discussed in more detail in the results section.
Test Measures
We decided to give our Sushi bar partners some brief usage scenarios through lo-fi prototypes of the interface and scripts and we asked them to rate the entire product interface using the ranking criteria below. For each task they were given, we asked them to rank the interface they used as so:
1. No usability issues.
2. Cosmetic Issues
3. Minor usability problem
4. Major usability problem: Serious flaw that should be fixed
5. Usability catastrophe: Can't use system unless this is changed
Results
This section is split up by constituency.
Sushi Chef Tasks
The first part of the prototyping process was to ask the chefs to look at an order sheet and start making sushi. The items ordered counts are on the left side of the interace they used. The chefs performed this task quickly as usual. One of the chefs remarked, "Sometimes it is hard and takes time to count the numbers of the same items on different order sheets in order to make food process faster in busy hours. If I don't have to arrange items and orders manually by using the interface of the system, I will make food items faster and easier." All the chefs ranked 1 for the interface.
The second task we asked the chefs to perform was to use the interface to sort and arrange orders. After creating many different dishes, they needed to organize them by table and keep track of who ordered what. This task was also very intuitive and went off without a hitch. The chefs unanimously found the interface easy to understand. One of the chefs particularly commented that thanks to the interface his job would become a lot easier, especially during rush hour. Fortunately they all ranked the interface with a 1.
The third task was to clear/complete an order once it had been fulfilled. Though it was a simple task, we found some issues we had looked over. The chefs were able to complete and clear orders very easily thanks to the given scripts. Their actions consist of simply typing the order number and pressing delete. However they brought up two situations we will need to accomodate: how to clear the order number incase the wrong number is initially typed, and secondly, what to do if the wrong order is accidentally deleted. The number pad interface did not accomodate these functions for now, and so the chefs gave it a score of 3 because of these lacking functionalities.
For the most part, from our initial lo-fi prototype testing, our interface scored well. Luckily we caught some glaring features we overlooked at this early stage.
Cashier Tasks
For our second constituency, the cashier, we proved three sample tasks with prototypes and scripts for the actions.
The first task for the cashier was to print a bill or check for a customer that has not yet paid. This was the most simple of tasks. They simply had to select the order and hit the "Print Check" button. Not surprisingly the task went well and the interface was given a score of 1.
The second task which follows the first was to simply enter into the system that the order had been paid for. They "clicked" the "Received Payment" button to verify that the order had been paid for. This task also earned a score of 1.
Our final task for the cashier was to delete the table entry from the interface. It simply consisted of finding the table in the program and pressing the delete button. The task seemed odd to our volunteer cashiers and they all asked why such a step was necessary. They preferred to have this step integrated with the previous task, allowing them to set a table as paid and removing it from the active interface simutaneously. However we justified our decision by pointing out the fact that cashiers often need to know whether a table has been paid for even after it has been paid for because customers may still sit and chat. After pointing this out, two out of three cashiers asked us to modify the interface so that they could easily see which tables had been paid for and which had not. In this task our interface earned a lower score of 3.
Waiter/Waitress Task
Our final group consisted of watiers and waitresses. Their primary responsibility, with regards to our system, is to take orders from customers. We decided to break this down into two tasks. The first was to take a simple order that consisted of quantities of standardized items on the menu. The second task was to take customized orders, e.g. with special instructions
On the first standardized menu we ordered 13 items: 3 Tai sushi, 6 Kani sushi, 2 Spider Rolls, 1 Crazy Roll, and 1 Spicy Tuna Roll. We ordered by saying the total quantity of each item that we wanted and that prevented the waitresses from making mistakes. On their order sheets they wrote down a table number, the quantities of each item, and when they were finished they checked the "Done" field correctly. It took less than 12 seconds on average to complete this standardized task.
However, when we change our ordering style it made the same simple task a lot more complex. Instead of providing the total quantities of each menu item upfront, we gave our order in a random fashion like so: 2 Tai, 2 Kani, 1 Spider Roll, 1 Crazy Roll, 1 Spicy Tuna Roll, 1 more Tai, 1 more Spider Roll, and 1 more Spider Roll. This caused the waitresses to make mistakes becuase they wrote down quantities on the order sheet as they heard them, and they then had to go back and change them. Each waitress asked to replace the order sheet and start with a fresh one. They also asked us to repeat the order. We then encouraged them to use other parts of the ordering sheet to take notes, and told them that only the specified boxed regions would be transmitted to the system. This way they can tall orders to the side of the ordering boxes but only write a final quantity in the ordering box when the entire order has been tabulatd. We asked them to perform this task after sharing this insight and found that their accuracy significantly improved. They used tally marks while taking the order and then wrote down the final quantities. This approach worked smoothly.
The waitresses commented that it was relatively easy for them to find items on the sheet because they were categorized, but they would prefer items to be alphabetized instead for even quicker lookup. They also expressed concern over the size of the order sheet becoming too large. They finally ranked this task with a 2.
The second task we asked of the waitresses was to take a custom order. We ordered the same items as above. We then specified that we wanted no wasabi, but to please add sesame, olive oil, and hot sauce to both of the spider rolls. At first the waitresses seemed confused with how to use the system. They fidgeted for a bit but quickly realized where the customized item section was on the sheet, and proceeded to write down our custom order. For this task they also ranked a 2 because of their initial confusion.
Discussion
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 going to affect the way we further develop the interface. This once again shows how user interaction can reveal simple yet elusive interface faults.
Chefs:
We will have to modify or add onto the chef's num pad to improve feedback and correction. The simplest way for this would be to add a "Clear" or a "Backspace/Delete" type button. On preliminary analysis, we believe that "Clear" will 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 one or 2 incorrect numbers, but the entire number. This means that in most cases, the user will have to hit "Backspace" twice or 3 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 this discussion is the lack of visual feedback given to the chef when he inputs 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 seems more likely a solution. This of course needs to be fast, as the chefs would definitely not want to wait for feedback any longer than they should. In light of this, we may also change the "Clear" button to a "Cancel" button, since the numpad now acts like more like a selection device rather than a keyboard.
We plan to make several versions of this additional functionality, and return to our test chefs for further input.
Next is the case of undoing an order. As an interface decision, the first easy clear choice would be to simply add an "Undo" button, which will simply bring back the last order that was deleted. This may even have a history of a few orders, although this is arguable for several reasons. One, the chef is most likely only interested in correcting the last mistake he made not the last 2. Since there will be errors in the operation, it is not unlikely the chef will press the button more than one time by accident. This may result in bringing up a fairly old order, which may greatly mess up the flow of things. If we do decide for history functionality, we will probably isolate the undo button away from the rest to reduce mistakes.
From the design perspective, however, even one undo may screw up the flow of the restaurant. Although a great feature for the beginner chef, one might argue that it is not so important for a master chef with feedback on the screen of the order he typed. If we give such functionality to our system, we are indirectly welcoming mistakes that may be avoided if more harsh training were given.
We will have to run this feature through several iterations of testing and user feedback to come up with a final decision.
Waitresses:
It was nice to see that the waitresses enjoyed the basic interface. One of our main concerns was that it would be 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. The categorization definitely helped this also, so we will further try to improve on this to make the paper smaller and more efficient.
We did not anticipate the problem with non quantity orders. This issue will help us tremendously to alter the interface, since it is clearly a common one. A simple solution for this is what we suggested to the waitresses, writing 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. We believe that the waitresses didn't default to this by themselves because they felt it may mess up the order input in some way, so once they were told that only the boxes were "live" they had no issues with writing on the rest of it. This leads us to believe that we may add other "temp" areas to the form for on the spot functionality that waitresses are used to.
Another solution may be to change our order form to accept tally marks, rather than numbers. This is somewhat of a tossup. Although it seems even closer to standard order form functionality, it is obviously very poor in terms of large orders. Mixed functionality may be a solution, such as the first portion of the box allowing for tallies, while the second allowing for numbers. Since most orders come in the form "N of item X, M of item B, Oh and one more X and 2 more B for me". We may be able to get away with only one number field. In the case of "N of item X, oh and M more of item X" where M is a number too large to tally, we would certainly be in trouble. This type of mixed interface may also prove to be confusing to the waitress, since the boxes may be too small to properly label, and will have different functionality which will probably yield a higher error count.
We were very pleased to see that the waitresses figured out the customization interface. We spent a lot of time trying to make it general yet small and comprehensible. Even with our current one, we felt that some instruction would be needed to help others understand it, but they figured it out on their own. Some training should still be administered, however, because they may be mislead by their own understanding of the interface.
Appendix
Demo Script
Hello Mr./Ms._______, thank you for letting us come by and visit with you again. If you remember us from last time, are names are <NAMES>. We really appreciate you for taking the time to speak with us again. As you know, we are students at U.C. Berkeley and are taking a course in User Interface Design. The last time we spoke we discussed and observed the different tasks and points of concern related to your line of work. We also expressed our desire to aid you with your work by designing a system that would automate the sushi ordering process, and improve the efficiency of your restaurant. Based on what we have learned from your work last time, we have developed a simple prototype of the kind of system we would eventually like to implement. We are interested in your thoughts and reactions on what we have designed so far. We are additionally interested in what feedback you can provide in improving our system. Before we move on we have a letter of confidentiality we would like you read through and sign. Basically it explains your rights and assures that we will not use this experiment to harm you in any way. [Let them read and sign the letter]. Now let’s move one to the experiment. What we have developed is a series of hand-drawn sketches that represent the types of interfaces you will eventually navigate through on the computer. Using these paper sketches, one of us will imitate the functionality of the computer. The process looks a lot like this.
Basically what we want you to do is pretend that the paper sketches are actual computer screen shots; we will ask you to accomplish a work-related task, and you should try to achieve it based on what tools you see drawn on the computer. We encourage you to speak your mind as you contemplate your objectives. In order to determine the effectiveness of our current design, we will be aiding you as little as possible. Only if you become totally confused and stuck will we give you help. My partner and I will give a demonstration. [Demonstrate how clicking on buttons changes the sketches that are displayed].
Consent Form
By signing this form I:
- understand there are no foreseeable risked involved with the experiment.
- understand the information obtained during the experiment will not be used to harm me in any way.
- understand my identity will remain confidential.
- understand the experiment will take approximately and hour.
- understand I am a volunteer and have the right to walk away from the experiment at any time without penalty.
- have the right to follow up on the progress of the research regarding the experiment.
Signature______________________________ Date____________________
Improved Sushi Bar Interface
Improved Order Sheet
