Hci Prototype Report

TOUCHSCREEN DRIVE-THRU
INTERFACE
Yasmin binti Zahir
Hussain
Faculty of Computing,
Software Engineering,
University Teknologi
Malaysia
nimsay94@gmail.com
Roslan Logan bin
Abdullah
Malaysia
chidori9444@gmail.com
Nor Khairun Aqila Binti
Jesmen
Malaysia
noraqila.94@gmail.com
Maria Ameina Binti
Ahmad
Malaysia
mariameinahmad@gmail.
com
Muhammad Faridzuan
Bin Jamaludin
Malaysia
fawidzvirrzdamor@gmail
.com
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”

“Promotion screen”
Figure 8: Initial and Final design of “Special
Request Screen”
“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
Performance
Score %
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
Performance
Score %
0
50
100
Task 3 : Reduce Quantity Order
Performance
Score %
0
50
100
Task 4 : Special Request
Performance
Score %

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.

Hci Prototype Report

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Hci Prototype Report

Similar to Hci Prototype Report (20)

Recently uploaded

Recently uploaded (20)

Hci Prototype Report