Ryan Bladzik TC841 Task Analysis Observations February 18, 2003 Methodology I chose to visit my target restaurant at 2:30 on a Sunday. While this is usually a slow time, there were quite a few people there and it worked out well for observations (the restaurant is a brand-new “neighborhood bistro” style restaurant, so any time during a Sunday would have been sufficiently busy). I chose my particular restaurant for several reasons: 1.) Considering I have been to most of the restaurants in the area, and this one was rather new, I didn’t have any knowledge of what went on “behind the scenes”; 2.) I knew that the restaurant had paper check systems and didn’t preempt the research goal; and 3.) I was hungry, they have diet IBC root beer, and the food is good. Observation setup I ended up sitting in a section where I had a good view of two servers in different sections. One of the servers had tables in two different sections, which allowed for a unique dynamic (tables not near each other), so I observed two interactions with that subject. I also observed my server, in an interaction with another table. I took notes on my experience with the server as well, not as a separate and focused interaction, but as additional insight from a first-hand perspective. Server 1: Table 1 I found that the general process for the servers was generally uniform, but had individual characteristics for each table. S1T1 consisted of three college-aged females. S1 came to the table, introduced herself, and inquired if the table wanted drinks. S1 had the standard restaurant uniform (polo shirt and khakis, and a pocketed waist-apron)—the apron contained a small bound folder, towel, and pen. S1 took the drink orders, but did not write them down. Retrieving the drinks took about 3 minutes. The patrons browsed the menu, and upon the return of S1, ordered immediately and apparently without query or indecision. S1 wrote the orders down on a small pad within the bound folder, and then returned to the back hallway before the kitchen. Meal service took about 15 minutes, during which time S1 attended to several other tables at various points in their meals. (During this time, Table 2 was seated, which is to follow). At various points (about 5 minutes apart each time) S1 checked in on the table. After about 15 minutes of dining, S1 inquired about dessert while bussing the dishes—T1 ordered a half-dozen cookies for dessert, the order of which S1 did not write down. S1 returned with the cookies, left to attend to other tables, and then returned to bring the check, which was delivered on a plastic tray with three peppermints and printed on standard receipt paper. One of the patrons examined the check, seemed to discuss it with the other patrons, and then all three threw in cash for the tab. S1 returned a few minutes later, checked about the tab (probably asking if they required change, which they apparently did not), put the money in one of the pockets of her apron, and returned to the back with the plastic tray. The patrons left shortly thereafter. Server 1: Table 2 T2 was located in another section of the restaurant, so I had to speculate more on the interactions between S2 and the patrons. The table was a couple (parent-aged). The interaction began with S1 taking drink orders for the table, which she wrote down on her notepad. She returned several minutes later with the beverages. It seemed that T2 required more time with their orders, but after several more minutes, S1 came with an appetizer (indicating that they had decided on an appetizer but S1 did not write this down). Again, several minutes passed until S1 returned to the table to take the orders, which were written down on the pad. About 10 minutes passed until the meal order arrived, and during this time S1 attended to other tables. S1 returned to the table to bus empty dishes, and seemed to inquire about the meal and dessert, which was apparently declined. The patrons remained for about 15 more minutes, and then S1 brought the check, again on the tray with the peppermints. The man paid in cash, and apparently requested change (it looked like a 20 or a 50, but I couldn’t tell for sure). S1 had change in another pocket of the apron, which was made on the spot and given to the patrons. The man took the change and the receipt, and S1 returned to the back with the tray (the patrons consumed the peppermints). Server 2: Table 1 S2 was similarly equipped with pen, bound folder, and pocketed apron. Her table was three people, older (mid 40’s). As I was sitting rather close I was able to hear some of the verbal interactions. S2 introduced herself, inquired about the patrons, and asked if they wanted any drinks, which she wrote down on her pad by slashing a line across a sheet and writing on the bottom of the page. It appeared to be shorthand, or very scrawled writing. S2 returned a few minutes later, after checking on a few other tables, with the drinks. S2 asked if the party wanted an appetizer, which they declined, but wanted more time to look at the menu. After returning a few minutes later, one member of the party was still undecided and inquired about one of the meals, which S2 described. The patron decided, and S2 used her pad, on a new sheet, to write down the orders, apparently again in shorthand. S2 returned twice to refill various beverages before the food was delivered to the table. The table ate, and then declined dessert when S2 asked while bussing the table. After several minutes, S2 came to the table with the tray, check, and peppermints. The party paid with a credit card. S2 came to the table, took the card to the back with the tray and check, and returned with three receipts—most likely the signatory slips for the customer and the restaurant and the itemized receipt. The party member signed, set the tray on the edge of the table, and left a moment later. They did not eat the peppermints. S2 took the slips to the back of the restaurant. Server 2: My table observations. I did not detail my experience, as I didn’t want to weird-out S2. I found that my experience was similar to the others: S2 did not write down drink orders, wrote down the order for my table on the pad, and also did not write down the dessert order. I paid by credit card, with a similar experience to S1T1. I ate my peppermint. Conclusions/Discussion Once again, I think this is a useful research technique in certain cases—namely, activity-oriented projects. In terms of doing audio/video design or non-application web design, task-analysis doesn’t seem like it would be that useful, but for doing something work-related, like software, I think it is the best way to go. I also think that it would be great to use with persona analysis (again, with a team working on the research—that’s a lot of work to do by ones’ self), since you get to detail a persona with work characteristics and activities. Interview Methodology I generally used the formatted example questions from the assignment, but also came up with my own focused questions. The interviews took about 25 minutes each, and the responses below are virtually verbatim, with the only editing being the removal of the name of the restaurant, the name of the server, some spelling corrections, and the niceties in between the questions. Both interviews were conducted over AOL Instant Messenger. Interview #1 Q: How long have you been working as a server at your restaurant? A: 7 months Q: Have you worked as a server anywhere before your restaurant? A: yes A: small hometown place for 2 years Q: Were the work experiences similar, in overall tasks and duties? A: no Q: Which place was more difficult/harder work? A: my current one. Q: Walk me through an interaction you have with a customer, from the time they sit down to the time they leave. Just a rundown of the things you have to do. A: we have 6 steps, greet and bev, order, food, 2 min check back, dessert and coffee offer, check Q: You use notepads, right? Do you usually write orders down? When do you/don't you? A: i don’t if it is one or two people and it is pretty basic, other wise i always right it down Q: After you take an order, what do you do to place the order? I'd assume you have a computer system of some sort--describe the steps. A: i put in my employee number, open the tables check, put in the order and send it, it goes to the station that is responsible for the team, like drinks go to the bar, salads go to a station, grill orders go to a station, etc. Q: How do you know when food/drinks/etc. are ready to be delivered to the table? A: there is two people in back that get the orders finished and put on trays and they call you, if you aren’t there someone runs your food, but most people know about how long the order will take and are ready to take it out Q: Cool. What do you do if there's a mistake or a problem with the order? Do you use the computer? A: i talk to a manager and if it has to be remade i ring it in again, nothing can come out fo the kitchen that doesn’t have a ticket Q: Ok. What is the easiest part of your job? Q: and what is the hardest part? A: hardest is balancing a lot of tables, easiest is talking to the customers Q: Ok. Now, the project I'm working on is finding out what should go on an "electronic handheld check". What do you think of the idea of going digital? A: i don’t think it would work well for customers because most want the check but i think it would work much better and faster for servers Q: What kind of features/functions would make your job easier? A: if the computer was more like a palm pilot because we spend most of our time standing in line to get to the computer, we write down orders and then just have to punch them in again, it seems like a step could be taken out Q: Ok. I'm going to give you a few sample features. Tell me what you think of them (and if you think of something else along the way, feel free to shout out). A: k Q: 1.) Recording orders on the palm pilot A: good idea Q: 2.) Being able to "beam" orders to the kitchen (or doing a quick plug-in upload to place orders) A: from the palm pilot? Q: Yeah. Like when you take a table's order, you hit "send" and it sends it to the kitchen (or you put it in a cradle and it sends the order to the kitchen). A: it would save a lot of time Q: 3.) getting a notification from the kitchen/bar that an order is ready (it buzzes or flashes or beeps and says something like "Table 5's order is ready") A: i don’t think that would save a lot of time because if i have the time to run my order i would be there, everyone helps each other out when it comes to that Q: 4.) A digital check (with an option for paper for people that want it), maybe with a credit card swiper on it? A: that would save a lot of time, we also have to wait in line to swipe credit cards Q: Alright--two more questions. What kinds of problems could you see with going digital? A: if someone’s thing broke down, they would really be out of luck, if we have a computer go down we can always use another one A: it is a little less personal as well. i think the customer would see it as a way to get them out faster Q: Do you think your co-workers (in general, no one specific) would have a hard time learning how to use a system like this? A: no, it would be just like out computers only smaller, they are a little hard to get use to but they are laid out pretty well, no one really has and problems Interview #2 Q: How long have you been working as a server at your restaurant? A: 5 months Q: Have you worked as a server anywhere before your restaurant? A: no Q: Walk me through an interaction you have with a customer, from the time they sit down to the time they leave. Just a rundown of the things you have to do. A: when the customers sit down, we greet them and bring drinks, then take orders, bring the food, check in on them, take dessert orders, and bring the checks. Q: You use notepads, right? Do you usually write orders down? When do you/don't you? A: I usually remember for small tables or simple orders, but for bigger tables I write down both Q: After you take an order, what do you do to place the order? I'd assume you have a computer system of some sort--describe the steps. A: we log into the computer and use a touch-screen to pick our table, put in the order and send it. Q: Where does the order go? A: It depends on what it is. Food goes to the kitchen, appetizers and salads and stuff like that goes to the stations, and drinks go to the bar. Q: How do you know when food/drinks/etc. are ready to be delivered to the table? A: we check in the kitchen, and the people that get the trays ready usually tell us that our orders are ready. Sometimes, if we’re really busy other servers or the people that do the trays will deliver them to the table. Q: OK What do you do if there's a mistake or a problem with the order? Do you use the computer? A: we talk to the manager and they fix the order on the computer. There’s usually nothing we can do on our own. Q: Cool. What is the easiest part of your job? Hardest part? A: The easiest part is dealing with the customers. Usually they’re pretty nice and fun, but I hate it when it’s really busy and we get understaffed—it’s hard to keep on top of a lot of tables. Or if we have a really big party that have a lot of drinks. Q: The project I'm working on is finding out what should go on an "electronic handheld check". What do you think of the idea of going digital? A: I think it would be cool. I like my palm pilot, and I think it would save a lot of time. I don’t know how some customers would like it—people that don’t get computers, but Q: What kind of features/functions would make your job easier? A: Is it like a palm pilot. Q: It could be. Let’s go with that idea. A: Being able to take orders and put them in would be the best—if it’s busy we usually have to wait for a computer. Q: I'm going to give you a few sample features that I’ve come up with that it could have. Tell me what you think of them (and if you think of something else along the way, feel free to shout out). Q: 1.) Recording orders on the palm pilot A: definitely Q: 2.) Being able to "beam" orders to the kitchen (or doing a quick plug-in upload to place orders) A: That would be good. Not plugging it in though—people would have to wait in line. Unless it was really, really fast. Q: 3.) Getting a notification from the kitchen/bar that an order is ready (it vibrates or flashes or something and says like "Table 5's order is ready") A: That would work, but if I’m busy with another table I can’t just run and get the order anyway until I’m done and someone else would probably take it. Q: 4.) A digital check (with an option for paper for people that want it), maybe with a credit card swiper on it? A: If it had a credit-card swiper, that would rock—we wait in line at the computer so long for credit cards. Would it have a printer on it? Q: It could—or it could have an option on the software to “request” a paper receipt, that you’d just have to run to the back to get. A: A lot of people want their credit-card receipts. It would probably have to have a printer or something like that. Q: Sounds reasonable—I keep mine too. What kinds of problems could you see with going digital? A: I think losing or breaking them would be a problem—not that everyone’s clumsey, but if there were only so many and they were all in use and someone dropped one or lost one, that might be a problem. Also, some customers might try to steal them. Q: Do you think your co-workers (in general, no one specific) would have a hard time learning how to use a system like this? A: Not really, if it was set up the same way the computers were, everyone learned those pretty quick. Interview Conclusions In general, I was pleasantly surprised by the results of the interviews. A lot of the functions and concepts I thought would be very useful and most likely to be included actually weren't very important to my subjects. I think when one does task analysis, it's important to include interviews and not just observations, because there's a lot of data that isn't obviously apparent based on watching someone do their job, and you can't judge their viewpoints and perspectives of their jobs, either. Requirements Analysis Based on my observations and interviews, I have concluded that an “electronic check” is really not feasible, in as far as replacing a paper check. However, I believe that some of the aspects of the concept could be used and integrated into a digital server system: Functional Requirements: The system would have to be able to record orders on the touch-pad; send orders to the kitchen via the touch pad through an infrared system (with an Firewire (or similar) cradle uplink as a secondary back-up system, and a touch-screen terminal as a tertiary back-up; if the system fails after that, then pen and paper and verbal orders would be required, though that’s generally the case at any restaurant with a computerized system). The system would also be able to track the progress of each table through their dining experience (i.e. “Table 2 just seated—needs drinks”, “Table 4 needs check”), meaning that a “smart” computer-processing unit would be required (see Data Requirements). The hand- held units would require automatic backlights (for low-light visibility). Because many customers want paper checks (either to sign for credit card payment or as a receipt), and because of the diverse feelings of the population on practical technology (I can envision some people being very averse to using an electronic device) using the touch-pad (or complementary device) for a check does not seem feasible or efficient. However, the device would have a credit-card swiper and the ability to do remote printing of receipts and credit card slips. Data Requirements: There are three main requirements that the system would have in terms of data: the menu database, the table management system, and the “system” data requirements. The menu database would be administered through a software interface in conjunction with the table-management system, and would allow for periodic cradle uploads in the case of a change in the menu. The database would contain all of the information on the customer’s menus, and would also allow for “specials” or other information. The table-management system would be the largest effort of development, and would be administered/interfaced with in three separate areas. The shift manager would be able to assign/adjust the sections based on the number of servers for that particular shift (the sections must be pre-determined for each possible number of servers). The host/hostesses would use a terminal to fill tables based on the sections (which would be updated in real-time). The waitperson would use the system to go through the process of the dining experience; the system would remind the waitperson of the status of a table (a “smart” system) and record orders in a temporary database. This would be an open-ended system, allowing for in-progress adjusting (i.e. delaying a server notification, customizing special orders, etc.) The system data requirements would entail the ability to send and receive data (such as placing orders, sending orders to the kitchen, remote printing of checks, receiving new customer seating, sending credit card swipes, etc). This would be based on the programming of the engineers. Environmental Requirements: In order for the system to work efficiently, there must be no infrared “dead spots” in the restaurant (meaning there would need to be a sufficient number of infrared nodes to cover everywhere in the restaurant). The system must also have an uplink backup system in case the infrared network goes down, and several other backups based on the needs of the restaurant. A constant infrared/radio signal must be present for the hand-held unit to work (to prevent removal from the restaurant, i.e. theft). User Requirements: Users must be able to understand a basic computer touch-screen system, the use of a stylus to tap-select, and have the capacity to learn the service process and how to record that on the hand- held system. Usability Requirements: The interface must have “one-touch” shortcut buttons to the following three areas: the menu application, the table-management system (a digital “map” of the server’s section where the server would touch a table to see status and interact), and system tools (uploading, maintenance, etc.). The other areas of the system would be branched down from those three areas. Goals Waitperson Personal Goals: The system, as an efficiency-tool, should be able to allocate the time from manual processes to making the customer’s experience more enjoyable. It should give the server more time to make friendly chit-chat with the table, spend more time checking in on tables, cater more to the customer, and reduce the time customers are waiting for any particular step in the service process. Waitperson Practical Goals: The system should be able to achieve the goal of saving time in manual processes; it should replace the time and repetition involved in ordering—writing down an order, going to a terminal to enter it, returning to the table, returning to the terminal to check out, and the time waiting in line for the terminal. The system should also be easy to learn and very quick to use. Corporate Goals: The system should be efficient enough that customers are impressed with the good use of technology to make their dining experiences more enjoyable, thus enticing customers to return for the good food and top-notch service. Mini-Persona Name: Amy Age: 21 Occupation: Waitress Computer/Handheld Awareness: Amy is a fairly competent computer user. She picks up on new systems and applications rather quickly, but only learns what is necessary to get her task done. She thinks Palm Pilots (handheld PDA’s) are cool, but doesn’t use hers for all of the possible functions it contains. Description: Amy, a college student, works at a local up-tempo (Chili’s-style) restaurant. She loves talking and laughing with her customers, but finds she sometimes is too busy with a lot of tables (or a particularly big table) to really chat with the patrons (especially the kids). She usually works one or two days during the week, and then all weekend (Friday/Saturday nights until close, Sunday days). She likes all of her co-workers and has fun at work, but finds waiting in line to put in orders at the computer terminal frustrating. Use Case Scenario I have invented the following restaurant, Chotchkie's, that uses the PalmServer hand-held management system. The following is a run-through of a sample use of the system. Amy, our sample waitress, would just be beginning the dinner shift. AMY comes into work and grabs an available PALMSERVER. She plugs it in at one of the WAITPERSON TERMINAL CRADLES, touches in a server ID code, which then punches her in. The specials and an updated menu have been uploaded to the PALMSERVER. Earlier in the shift, the MANAGER divided up the sections based on the 5 other waitpersons on duty. AMY finds through the TABLE-MANAGEMENT APPLICATION that she has 6 tables in section 3, two of which have customers from the previous server. The HOSTESS uses the HOST TERMINAL to enter a three-top into the system in AMY’s section. AMY receives a notification on the PALMSERVER that table 4 has customers and table 4 becomes an “active table” on the TABLE-MANAGEMENT APPLICATION. AMY goes to table 4 and introduces herself. She makes small talk with the three people, and then asks if they would like drinks. They order drinks, and AMY goes to the MENU APPLICATION and orders their beverages, and then hits “send to bar” to “beam” the drink order to the BAR TERMINAL. She then leaves the table and goes to check on the drinks. During this time, she receives another notification that she has another table filled, a two-top at table 3. AMY returns to table 4 with the drinks, excuses herself to attend to table 3 while table 4 continues to browse their menus. She repeats the drink ordering process for table 3, during which time a notification appears on the PALMSERVER, reminding her that she needs to check if table 4 is ready to order. AMY returns to table 4, where they are now ready to order. She brings up table 4 on the TABLE-MANAGEMENT APPLICATION, and proceeds to the MENU APPLICATION and selects their order, hitting “send to kitchen” to “beam” it to the KITCHEN TERMINAL. AMY goes to table 3 and repeats the process for their order. She did not receive a reminder because she sent the food order before the system’s time limit for taking an order expired. During this time, she checks the drinks on both tables and the status of the food. Upon a trip to the kitchen, table 3’s food is ready, and she brings the food out. In the TABLE- MANAGEMENT APPLICATION, she records that table 3 has received its food. During this time, she receives a notification that table 4’s food has been delivered by a FELLOW SERVER because AMY was delivering the food for table 3. The FELLOW SERVER used a WAITPERSON TERMINAL to enter that food was delivered. AMY receives a notification on the PALMSERVER to check in on each of her tables after 5 minutes (another system-built guideline). She clicks “delay” for table 3, because she was attending to table 4. A minute later, she receives the notification for table 3. Table 3 wants dessert, so AMY uses the PALMSERVER to send another order to the kitchen and the food-delivery process repeats. Table 4 does not want dessert, so AMY “checks out” the table by using the TABLE-MANAGEMENT APPLICATION to send a “print check” command to one of the WAITPERSON TERMINALS’s printers. She goes, retrieves the check, returns it to the table. Table 4 wants to pay by credit card, so AMY takes the card, runs it through the SWIPER on the PALMSERVER, and receives notification of initial approval. She excuses herself to attend to other tables and grabs the paper credit card slips from a WAITPERSON TERMINAL printer to return to the table. After table 4 leaves, she records them as “paid” on the TABLE- MANAGEMENT APPLICATION and clicks that table 4 is now “open”.
Pages to are hidden for
"Methodology"Please download to view full document