hci prototype report
TRANSCRIPT
TOUCHSCREEN DRIVE-THRU INTERFACE
Yasmin binti Zahir Hussain
Faculty of Computing, Software Engineering, University Teknologi
Malaysia
Roslan Logan bin Abdullah
Faculty of Computing, Software Engineering, University Teknologi
Malaysia
Nor Khairun Aqila Binti Jesmen
Faculty of Computing, Software Engineering, University Teknologi
Malaysia
Maria Ameina Binti Ahmad
Faculty of Computing, Software Engineering, University Teknologi
Malaysia
Muhammad Faridzuan Bin Jamaludin
Faculty of Computing, Software Engineering, University Teknologi
Malaysia
Abstract
This paper presents aspects of a study on usability of a touchscreen drive thru interface at fast food restaurants.
The paper describes the iterative design and testing of the system and focusing the system in Mc Donald. The paper also describes the problems the system addresses, the design and implementation of the system, and an overview on the feedback and evaluation of the system.
Author Keywords
Human-Computer Interaction; HCI; drive-thru; touchscreen interface;
ACM Classification Keywords
D.0 Software: GENERAL
General Terms Human Factors; Design
Problem
With the current drive-thru system, consumers need to speak through an intercom to place their order. Miscommunication between the
customer and the server can cause errors in orders and also confusion, in addition to the fact that people may feel self-conscious when speaking to a box. The new drive-thru interface eliminates these problems. The drive-thru interface also attempts to improve the ordering speed. Present systems require that a server (person in charge) be present to take an order. Often times, a driver must wait for a server to appear, resulting in inefficiency. With our computer drive-thru interface, drivers can automatically begin ordering food without the need to wait for a server.
Users
McDonald’s is the largest and best-known global food service retailer with about 28,000 restaurants in 121 countries, serving 45 million customers each day. The intended users for our drive-thru system are novice and casual users who are able to drive (age over 18 in the Malaysia), and seek quick quality service restaurant. Our system is developed to accommodate people with all different levels of knowledge in computerized systems. Since McDonald’s is very popular in many different countries, our intended users are spread all over the world. Our system can be implemented in any restaurant that offers a drive-thru service.
Solution
We recognized the need to improve the process of ordering food at a drive-thru window of a fast food restaurant. The current drive-thru system has several drawbacks that we want to improve and will allow customers to have direct control over making and changing their orders. The team decided to implement a touch screen interface drive-thru system with the ultimate goal of providing users with a food-ordering interface that is consistent, intuitive and easy to use. For this project, our team decided to use McDonald’s as the restaurant because of its recognition and well-known drive-thru service.
The drive-thru interface is designed to provide customers everything they need to order their food. Note that users must still pay and pick up their order at the window. The following gives an explanation of what our systems allows the user to do.
The majority of the ordering process occurs on this screen. The menu options that the fast food restaurant provides will be listed under different categories across the top of the screen. To prevent users from having trouble finding food items, the menu items are grouped under different food groups, in addition to other options such as “Combos” and “Happy Meals.” The bottom row of the screen will allow users to submit final order, access the “Change Order” screen, start over, and even ask for assistance. Both the top and bottom row icons will be visible throughout the ordering process. These buttons provide quick and easy navigation through the system. They also give a point of reference to prevent the user from getting lost. As users select the menu options, the center of the screen will display pictures of the food item, along with the food name and price, under the chosen category. Touching an item’s “Add to my order” button allows users to add that item. Our system enables the user to select the size of the food item, and if relevant, the flavour of the food item (for example, Coke vs. Sprite).
As customers perform their orders, the read-only “Current Order” screen will automatically update the balance due, and list the food item ordered, along with any customizations. Customers will be able to see these changes and updates as they are being made on the screen.
Personas
Fizo
Fizo is a 40 years old father that works. He often orders meal from McDonald every week
for his family. Fizo doesn’t like to wait in line so he prefers to go through the drive-thru. However he doesn’t like to talk through the intercom as he always gets the order wrong. On top of that, he doesn’t really remember the menus available at McDonald which troubles him a lot. So Fizo hoping if there’s a way that McDonald could display all the menus available which would make his process of ordering better.
Yaya
Yaya is a UTM student who studies Software Engineering. Occasionally when she goes to McDonald, she sometimes cancels the order at the last minute during the drive through but the worker already keyed in the order and already prepared for the meal which made Yaya has to pay for her meal. She’s hoping that there would be a system where although she had placed her order, at any time time she could re-verify whether she wants to confirm the order.
Ummi
Ummi is a 35 years old mother that always rushing around to pick her children and send them to practices. Occasionally she would buy lunch at McDonald. However, during the rush hour she would go through the drive-thru and order through the intercom but the worker never seem to understand what she says, so she need to repeat her order again and again which eventually drives Ummi impatient. Ummi wishes if there’s a different way of placing her order.
Hazeem
Hazeem is a 29 years old male who works. He’s also a regular to McDonald but he has a tight budget when it comes to ordering the meal. He has been very responsible staying under budget but this has been very hard lately. He often struggles to know about the latest promotion when going through the drive-thru. So he is
hoping if there’s a better way to know the latest promotion available at McDonalds so he could spend his money wisely and save under budget.
Tasks
There were many tasks that we thought would be useful for this interface, but there were a handful of essential tasks that were absolutely necessary. First is adding order which is the main basic thing of the system. This requires a list of menus that are available that really relied on having a database of food items available at the restaurants. Next task is cancelling the order. User could easily remove unwanted orders that they did easily without any hassle. The third task is the easily reduce the quantity of order. User can really be certain on how many quantity that they have ordered since they are I control. The last task is adding special request. User can now add specified desired condition for their food items. However, we are aiming to create our ideal prototype, so we try to implement al of the task stated. Had we actually implemented the back-end of this application, we would have to deal with that feature. Instead, this was very much about the design of the overall user-interface, so we focused on that.
Design
Our original design went through several stages but the following discussions will emphasize our original design sketches and how they evolved into the final design. Initially our design did not include a home screen since we anticipated that user would most frequently want access to the menu screen straight away. However, several of our test users found this confusing and they ask to add a home screen. Thus the drive thru interface starts with a home screen and all other functions were accessed as icons after user enters the home screens.
The home screen welcomes the user to the fast food drive through which will be a good start. For this system we use the background as red since Mc Donald is known for red colour. In the middle there’s an indication of logo of fast food restaurant and after that where the “click to continue” button is placed to enter the menu screen.
Figure 1: Initial and Final design of “home screen”
The menu screen remained substantially similar to our initial design sketches. There were no user complaints regarding the menu screen icons. They loved the round icons as it is attractive and easy to understand. User can click any of the icons to enter their preferred menu first.
Figure 2: Initial and Final design of “menu screen”
There are 5 options of menu where user can select which will display the menus and they are “Ala Carte, Beverages, Happy Meal, Promotions and Combo”. Each menu they have a standard display the logo of the specified menu like for example if “Ala Carte” the icon will be on top left. There will be a standard tab on top for user to easily navigate on the menus. On the right of the screen there will be displayed the item that has been ordered with the quantity and amount to pay. User could cancel the item any time.
Below the list there will be a button option whether to cancel all of the order or confirm the order. If “cancel order” is chosen, the user will be brought right back to the home screen and can start over. If user chose “confirm order” another screen will be displayed which is the “special request” page. Here user could add their special request regarding their ordered food such as extra cheese or onion for burger or etc. On the menu page such as the “Ala Carte”, user just need to click on the plus icon to add the item to their order list. The minus icon to reduce order which is easy to be understood.
In the previous design, the way to add order is to click the “place order button” but it is hard to add the quantity of the item together so we have modified the design as mentioned before.
On the “special request” page, there is a back button for user to return to previous screen where they were last visited so that they could cancel their order or add more. There is also “confirm order” button to finalize the order and “cancel order” which will bring the user to “home screen”. Once user chose “confirm order” User will be prompt with successful order so that user could proceed to next counter to take their ordered items and pay.
Figure 3: Initial and Final design of “Ala Carte screen”
Figure 4: Initial and Final design of “Beverage screen”
Figure 5: Initial and Final design of “Combo screen”
Figure 6: Initial and Final design of “Happy Meal screen”
Figure 7: Initial and Final design of “Promotion screen”
Figure 8: Initial and Final design of “Special Request Screen”
Figure 9: Initial and Final design of “Complete screen”
Implementation
Functionality
The prototype implements enough functionality to accomplish the task given to the user. These have the following views available
• Home screen • Menu screen
• “Ala carte”, “Beverages”, “Happy Meal”, “Combo”, “Promotion” menu displays screen
• “Special Request” screen • “Order completion” screen
There isn’t much business logic implemented except for the calculation of total price of the order. However, the view layer has all required behaviour to simulate a real application.
Technology
In order to test if the functional requirements and the look and feel was acceptable, we decided to make some prototypes. This way we could check the useful-ness of the application, validate requirements and see if our metaphors suited well the needs of our users.
Two kinds of prototypes were implemented: low fidelity and high fidelity. We built in all the necessary functions to test a certain set of tasks (vertical prototype), so in every new version of the prototype we made design changes, but did not necessarily add new features. Not being committed to one implementation or idea let us apply changes rapidly and go back to the users to test it.
For this prototype, we used an online software which is the Pidoco where it allow us to build our prototype easily. The interface of the prototype builder is very direct and easy to use. The software also allow us to collaborate to modify the prototype anytime, anywhere and live. This has made our work production more rapid and smoothly.
However, this software has it limitation where we can’t fully implement our idea as it can’t perform certain task. For example we had a hard time to figure out how to automate the calculation of ordered items. Since is purely based on wireframe work, it is hard to achieve. Throughout the building of high fidelity prototype, there were some discussion on
switching the system we could use to build the prototype, however it takes more time just to figure out the software before to be used, thus we continued with Pidoco software to build our prototype.
In a way, it might cause some usability issue, however based on the user test that we did, we have received good reviews.
Evaluation
Throughout the design process of the Touch Screen Drive Thru Interface system, we went through several iterations producing newer and updated versions of the interface based on user feedback we received. The three main types of evaluation we performed using our interface were: paper prototyping, heuristic evaluation, and user testing.
We as a team conducted user testing and evaluations separately on students who go to Universiti Teknologi Malaysia and they are all above 18 years old. Because of the small amount of resources, we felt this was the only way that we could fully test users on the product. We designed sample steps for these users to complete, having them working through it on their own. Once they did complete these steps, we had them take a survey, and interviewed them on what they thought of the design. Both forms of feedback were used for us to determine what to fix in the final product that would make Touch Screen Drive Thru Interface that much more reliable and easy-to-use.
Paper Prototyping
The paper prototype was a successful way for us to hone in on the true issues that our system had. This was the first time anyone outside of the team was seeing as piece of it, so it was important for us to show them the full extent of what we were thinking.
We had users perform three tasks using the paper prototype we had created for this study. Those tasks were:
1. Order an item 2. Add special request 3. Cancel the order
We found that many user doesn’t understand what does “special request” means. They took a moment to think what to key in. We took note to make it clear what should the user do.
A few users also tried to perform activities that the current implementation of the system could not handle. For these cases we needed to ensure that the user is aware that such actions are not accepted by the system. Simple error messages would suffice.
We also received feedback from users wanting to do more with the system. Some felt that the current implementation did not feel complete and as robust as they would like. This is something we focused on increasing in future revisions o the system.
From this prototype, we developed a new menu screen, improved the way to order, and made cosmetic changes that affected the flow of the project.
Heuristic Evaluations
Computer prototyping came with Heuristic Evaluations from our peers. These evaluations both complimented and suggested new ideas for the developing application. We had suggestions to add default special request, which resulted in a Home button on every page, suggestions to change the color schemes so the application was much more readable, and various suggestions that in the end led to what you see. At this point in time the system was online and available for anyone to visit. Each evaluator reported back to us with many good and bad things to say about our system. Here are briefs
lists of some of the common points the evaluators made about our system:
The good
• Clean Interface • Easy to read and access • Direct and not complicated
The Bad
• Hard to type in the special request
We were very thankful to have received such feedback from users and made sure everything mentioned was kept in mind when building future revisions of Drive Thru Interface.
User Testing
The last method of evaluation performed was user testing. The preparation of this method of evaluation was very similar to that of paper prototyping. Users were presented with a briefing which outlined everything discussed previously in the section about paper prototyping. However, the tasks for users to perform were modified and refined:
1. Order an item 2. Cancel specific item order 3. Reduce Quantity of order 4. Add Special request
Most of the user were quite satisfied with the current design though there were still some improvement that could be made said by one of the user.
We had a few user who felt that the special request part there should be a default several option for them to choose instead of keying in manually which consumes time.
Through the user testing performed, many problem areas in our system were identified. We made it imperative to take action on issues when creating the final revision of Touch Screen Drive Thru Interface.
Surveying
User testing that we did on 6 users, we have gave out some questionnaires for them to fill in. Based on their responses we have come up with results of performance measurements and subjective measurements.
Performance Measurement:
Calculate the performance score of the user using the Whiteside equation.
S = PC/T
Where:
S = performance score of the user
T = time spent by the user on specified task
P = percentage of task completed
C = arbitrary constant based on the fastest possible task solution by a practised system expert
Figure 10: Performance Table for ordering task
0
50
100
Task 1 : Ordering
PerformanceScore %
Name Ummi Wahyuni Aiesah Rusli Hafiz Izzat C
Task 1(s) 34 46 41 29 26 25 21 Task 2(s) 19 23 24 19 18 17 16 Task 3(s) 31 44 35 31 34 24 23 Task 4(s) 33 37 35 27 32 29 24
Performance Score(S) %
S1 61.76 45.65 51.22 72.41 80.77 84.00 S2 84.21 69.57 66.67 84.21 88.89 94.12 S3 74.19 52.27 65.71 74.19 67.65 95.83 S4 72.73 64.86 68.57 88.89 75.00 82.76
For this task, all of the user could complete the task 100%. Some of the user could order the item quite fast where as some are average. In conclusion for this task, the users find it easy and not complicated which is exactly what are we targeting for.
Figure 11: Performance Table for cancelling order task
For this task, every user completed it successfully and all of their performances are good above 50%. This proves that this task isn’t hard to carry out.
Figure 12: Performance Table for reduce quantity order
Figure 12 shows that, every user able to reduce quantity of order quite well. Some of the user gave feedback that the system interface is quite good and all of the task could be done smoothly. Every user have performed well.
Figure 13: Performance Table for special request task
In this last task, although the user performance is good, we have received some feedback from the user that it is not that efficient to type every single thing during order. So some of them have suggested to have some predefined selection and that is what we have change in our final prototype.
Subjective measurements
User Experience
Mean Standard Deviation
Attractive 4.50 0.50 Confusing 1.00 0.00
Easy 5.00 0.00 Annoying 1.17 0.67 Helpful 4.50 0.50
Challenging 1.33 0.47 Figure 14
The result is as expected as the system is meant to be easy to use and not complicated which makes the system less challenging. In terms of performance, overall every user have passed of 50% of the user performance in terms of time taken to complete each task. Every task has been completed 100% with ease and there are even certain users that perform as fast as the expert of the system. By far, the hardest task would be task 4 which is the special request as it takes time to key in the special order request. The easiest task would be task 2 which is cancelling order as it is quite straight forward and fast. Based on the performance score, the
0
50
100
Task 2 : Canceling Order
PerformanceScore %
0
50
100
Task 3 : Reduce Quantity Order
PerformanceScore %
0
50
100
Task 4 : Special Request
PerformanceScore %
usability of our prototype is looking good as users doesn’t really face critical problem. From the mean and the standard deviation, almost all of the user finds the system attractive, not confusing, easy, not that annoying, quite helpful and not that challenging. We think we should improve the way user inputs the special request as it takes really long time for user to key in so we might insert some defaults for the user to choose.
Reflection
Through our entire project, we ran into various issues. Upon reflection, it became evident that some of these issues could have been foreseen. While others were as a result of limitations of our prototyping tools. These are the following issues we ran into, and what we would do differently in future projects in order to make the design process easier and more successful.
Issues
Our first problem was, we were tasked with deciding upon a prototyping tool to utilize to best represent our application. We have tested many and they had various limitation, and we ran into a prototyping tool called Pidoco.com. It had many customizable features, and the overall look is good and pleasing. We were pleased to find a prototyping tool where we could all log in at the same time and work on it, and after spending countless hours we have saved. However, we didn’t realize that this prototype had it limitation where only opened up to 6 pages only for free user. For our prototype we require more than 6 pages which frustrates us. Luckily we have contacted the Pidoco customer service and sent a request to allow us to continue to work more on the prototype and after a week of waiting they have allowed us to use unlimited amount of pages that we would like for 2 months. The next issue we ran into is that when one of our team mates accidently deleted one of the prototype page.
We had spent hours on building the page and we had to do it all over again.
Finally the issue we had was the fonts and colour scheme is really limited in Pidoco prototyping tolls. This restrict us from designing more pleasing looking interface thus it looks really plain.
What we would do differently?
For our next revolutionary prototype, we would utilize a more common, or even paid prototyping tool. This would ensure a more problem free experience, and we could even be offered customer service in the case that we run into any issues.
Next we realized how important is default options for users in special request page as it made the task easier.
Finally, we realized if we had code the prototype from the beginning and make it dynamic rather than static. The ordered items display would be easier and calculation could be done smoothly. This would let us avoid many issues we encountered, and it would actually be functional rather than just a model.
Conclusion
The design process was incredibly informative and the experience was an excellent one. We learned a lot, not only technically related, but also in regards to time management and teamwork. We learned about Usability and how important it is in the design process, as well as imagining ourselves in the place of the users. Through our project we found that what we necessarily thought was important and needed in an application wasn't exactly what the user wanted and needed. This showed us how important prototyping is because a company
that dives into a project without actually taking the time to make a prototype may end up with catastrophic sales if there is a certain feature that either is inconvenient to use, doesn't do what it is intended to, or isn't included at all.
By building the prototype of Touchscreen Drive Thru Interface, we definitely gained a bunch of experience and not only learn more on prototyping but also the way we work as a team. Users of our system were also very receptive to the idea of Touch Screen Drive Thru Interface. Implementing this system for real in future would be a great deal for us.
Acknowledgments
Throughout the semester, it was a pleasure to be in this class and we have learned a great deal of information regarding Human Computer Interaction (HCI). It is extremely valuable because so many of us will be applying these concepts in future especially in our technical fields. We thank our HCI lecturer Puan Nor Anita Fairos Binti Ismail for this valuable experience, and to our classmates who have helped us by providing feedback and knowledge along the way.