This document describes the design process of a hostel booking application for students at Universiti Teknologi Malaysia (UTM). It outlines the problems with existing hostel booking systems, design considerations and iterations, implementation using a prototyping tool, and user testing evaluations. The application was designed to make hostel reservations more convenient by allowing students to search for and book available rooms online across different UTM colleges. The design went through several iterations based on user feedback, improving aspects like adding instruction pages, using student IDs for login, and including logout buttons. A survey of early users found the application was generally easy to use with minor interface issues to address.

1. 1
UTM HOSTEL BOOKING APPLICATION
Muhammad Hafeezul
Anwar Bin Roslan
Faculty of Computing in
Software Engineering
hafeezdzeko374@gmail.co
m
Muhammad Hazeem Bin
Azman
Faculty of Computing in
Software Engineering
stationz_94@yahoo.com
Ummi Syafiqah Binti
Mohd Jalil
Faculty of Computing in
Software Engineering
ummi_layyinul@yahoo.co
m
Nur Atikah Binti Shamat
Faculty of Computing in
Software Engineering
atikah2409@gmail.com
ABSTRACT
In this paper, we describe the process of
designing a hostel booking application to
assist students who wants to book hostel for
any colleges in UTM. This is overview of
how we made design choices, implemented
those choices in various stages of
prototyping and evaluated the usability of
the application at each step in the process.
INTRODUCTION
The Hostel Booking Application was
designed to make the task of room’s
reservation for students in UTM an easiest
one. Most students choose to reserve their
own room, so reservation ends up taking too
much time. We wanted to overcome the
challenges that arise when booking the
hostel such as finding the empty room in any
colleges in UTM. This process was
concerned with the user interface design of
the mobile application as opposed to the
back-end programming aspect of the
application.
PROBLEM
We found that the common issue was that
during the end of the semester, students have
problem to get their preferred room booked.
This is because most of the booking system
in the UTM still using the file based system.
So, there were many problem arise, such as
data redundancy, data lost, data
maintenance. Besides, the hostel booking
system in the UTM is not consistent; there
are colleges which the booking period is not
the same. This is being a concern for the
most of the students because there are others
want to pick the room at the different
college at the same time and consume too
much space. We wanted to design an
application that can reduce these various
problems and made process of hostel’s

2. 2
reservation more convenient and efficient
one.
USERS
Our target users for this application were all
the UTM’s students who want to manage
their hostel booking.
TASKS
There were many tasks that we thought
would be useful for this application, but
there were handful of essential tasks that
were absolutely necessary. Below are the
major tasks we initially expected all users to
be comfortable.
1. Sign in to the application
• Students will enter their
username and password same
as their ACID number.
2. Search and choose for room
available
• The students are prompt to
find which college and block
they want and choose either
single room or double room.
• After they entered everything
needed, they will be ask to
choose which room they want
by clicking only one of the
room that is available. The
room that they click will turn
to blue color which mean
they already booked. Noted
that whenever the room is in
red, it means that that room is
already booked by other
student.
3. Fill in the details
• Students will be asking to fill
all the information needed
such as their name, matrix
number and session. Noted
that if they are to choose
double room, they need to fill
in all of his/her roommate’s
information.
4. Sign out from application
• After the students finish
using the application when
their booking has already
done, they will be back to the
main page and will click the
sign out button.
DESIGN
Our design went through several stages but
the following discussion will emphasize our
original design sketches and how they
evolved into the final design. Initially our
design did not include sign out button and
back button. Thus, both buttons we added so
that user can back to previous page and log
out after they use the application.

3. 3
For final design, we provide one page that
will give the user instruction before they use
the application. This page will let the users
know how to use the application and what
are the conditions while using the
application. After they understand the rules,
they may continue the application by
clicking the “start” button.
Figure 1: instructions
Some of the test users found that it is more
convenient if they use their ACID ID that
was already provided by the UTM to access
the application. So, for the final design, we
ask the user to enter their username and
password by their ACID ID’s. This change
will also help the college’s staff so that they
can review each students and record by
student ID.
At the final design, we added exit button at
the bottom left of log in page. If students do
not want to use this application yet, they can
click on the exit button.
Figure 2: design sketch of sign in page
Figure 3: final design for sign in page
The searching for available room remained
substantially similar to our initial design
sketches. After users complaints, we decided
to consistency include a log out button on
the bottom after the users entered every
details needed to complete the searching.

4. 4
Figure 4: initial design sketch of
searching available rooms
Figure 5: final design for searching
available rooms
Students will be asking to click one of the
rooms. When they click, the rooms will turn
to blue color which means that the room is
already chosen by the students. Whenever
the room is red, it means that the room is
already booked by other students. To
differentiate the students between single and
double rooms, we assign yellow color as
single room while the blue is for double
room.
Figure 6: initial design of available rooms
Figure 7: final design for available rooms
Besides, we also remained the same as
initial design sketches for our “fill in the
details” page for single room and double
room. This page will ask user to fill their
name, matrix number and session. Others

5. 5
information like IC number are already
recorded in their own ACID ID. So, they do
not need to fill the information again and
again. For students that choose the double
room, they need to fill in their roommates’
information.
Figure 8: initial design sketches of enter
the details (single)
Figure 9: initial design sketches enter the
details (double)
Figure 10: final design for enter the
details (single)
Figure 11: final design for enter the
details (double)
There is one page that will show all the
information that students are already filled.
At the bottom of this page, we added update
button so that whenever students feel that
there are wrong on their information like
matrix number, they will click the submit
button and edit. After students update their

6. 6
information, they cannot edit their
information in the next time. This is because
the system will be updated only once.
Figure 12: initial design sketches of
booking details
Figure 13: final design for booking details
For both initial and final design, students
need to click on the home button to go back
to main page as they want to log out from
the application. So, this home button is
initially remained at the bottom right of the
booking details page.
IMPLEMENTATION
We used a mobile app prototyping tool
called Justinmind to implement our
application prototype. Justinmind
Prototyper is an authoring tool for software
prototypes and high-fidelity website
wireframes. It offers capabilities typically
found in diagramming tools like drag and
drop placement, re-sizing, formatting and
export/import of widgets. In addition, it has
features for annotating widgets and defining
interactions such as linking, animations,
conditional linking, calculations, simulating
tab controls, show/hide elements and
database simulation.
The program creates high-fidelity prototypes
a step before the first version of a mobile
app or website. The prototype can be used
for show reels and testing purposes.
Justinmind Prototyper can be used to create
prototypes and simulations of software
without any coding, thus allowing non-
programmers to be involved in the project.
Design elements include everything from
shapes to things like form fields and menus,
making it easy to mock up user interface
design without having to start from scratch.
All we have to do is drag and drop them into

7. 7
place within our design. But the drag and
drop functionality does not end with just
placing elements. To create links and
interactions, we do the same. To define a
link, just drag the component to the screen
we want to link it to. Add comments the
same way (just drag and drop them onto
components).Guidelines make designing our
wireframe a lot easier and more precise
(meaning it’s easier to convert it to a
finalized design later on).
The ability to round corners, crop images, or
apply color gradients means our final
wireframes are a lot more visually appealing
than a simple sketch. Create entire pixel-
perfect designs right within Prototyper,
saving time down the road. We can add
images to our designs quickly and easily.
Just drag and drop the images we want from
design programs like Photoshop, or directly
from our browser.
There’s even a color capture tool so we can
grab precise color values for our design. One
of the best features of Prototyper is the
immediate simulation of our prototypes. Just
click the “Simulate” button and we will see
a simulation of our prototype’s behavior
instantly. Once your prototype’s design is
finished, you can simulate interactions to get
a feel for how the app will actually work.
EVALUATION
We as a team conducted user testing and
evaluations separately on students in UTM.
We felt this is the 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 taken 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 Hostel
Booking Application much more reliable
and easy-to-use.
USERS
As mentioned before, our users were UTM’s
students. This is because this application is
for UTM’s students to booking their room.
It is important that we mention that we want
this application to be used by any of the
students for different reasons.
EARLY STAGE TESTING
Just to recap on what has already occurred
before user testing, we wanted to show you
some of the results of paper prototyping so
you have an idea of where this left us.
The paper prototype was a successful way
for us to hone in on the true issues that our
application had. This was the first time
anyone outside of the team was seeing as a
piece of it. So, it was important for us to
show them the full extent of what we are
thinking. From this prototype, we developed
a new instruction page, improved design

8. 8
layout, added new back and next button and
use the ACID ID for log in.
USER TESTING TASKS
We started every user off with a brief
statement on what they would be doing and
that their participation was voluntary. Once
we brief, each user on what they would be
looking at, and they agreed to participate,
we set them in front of the computer and
asked them to do four certain tasks for us:
1. Log in to the application.
2. Search and choose for room
available.
3. Fill in the details and update the
details.
4. Log out from the application.
These four tasks were given to each user in
order. As team members, we would let them
explore on their own, not giving them any
helpful hints. We would see how long it
would take to complete each task and after
each task ask what they thought would make
the task simpler.
Once they had completed all four tasks, they
were asked to take a brief survey. After this
survey was completed, the user thanked and
sent on their way. Nothing else of them was
asked.
FIXING
With our user testing, many fixes and idea
came forward. Some were small thing like
the color of the text. Users feel that it is so
hard to read the text with the color that we
used. There was also the problem with the
logout. Users feels it is more convenient to
logout directly without go back to home
page.
The user testing yielded many results that
we were proud of. Most of these will be
highlighted in the survey below, but can also
be seen in the countless idea poured into the
application.
SURVEYING
The survey was only taken by six users.
Some users that were tested gave us
feedback and completed their questionnaire.
Therefore, the result that you will see may
be completely different that what actually
might happen.
First, we calculate the performance
measures to know how usable our product
by every four tasks that users tested. The
formula given:
S=PC/T
Where:
S = performance score of the user,
P = percentage of task completed,
C= arbitrary constant based on the fastest
possible task solution by a practiced system
expert,
T = time spent by the user on the specific
task

9. 9
Table1: Time for user to completed the
task
Figure 14
As you can see in figure 14, we had users
rate on how they felt when they try to log in
into our application. They seem a little
confused with the application and most of
them don’t know the application icon. When
they have identified the application. They
have no problem in using our interface.
Figure 15
Figure 15 shows the rate for task 2 for every
user. This result shows that almost every
user seems to know what they should do and
they did not hesitate when they are asked to
complete the task. The user are prompted to
enter the college , block no and availability
of the rooms which is single or double. Yet,
they have completed the tasks successfully.
Figure 16
User
1:
Yuni
User2
:
Wana
User
3:
Nad
User
4:
Khai
User
5:
Lan
User6:
khairul C
Tas
k1
48s 31s 59s 48s 51s 53s 20
s
Tas
k2
45s 20s 33s 36s 34s 21s 18
s
Tas
k3
86s 80s 60s 86s 67s 63s 53
s
Tas
k4
18s 12s 20s 11s 12s 9s 8s

10. 10
Figure 16 shows the result for task 3.
Overall, all of the users have the average
time to complete the task. On tasks 3 , the
user were prompted enter details regarding
their name, matrix no and session.
The task was never a problem as they can
pass through the tasks quite easily. Also they
are able to update the data whenever they
click on the update button. Most of the users
are very familiar with the type of interface.
Figure 17
For task 4, almost all of the users can
complete the task smoothly. Some of them
comment that it is more convenient if they
can log out from the application directly
without go back to home page.
Next, we calculate the subjective measures
to know how our user feels when using our
application. From the questionnaires, we
calculate the mean and its standard deviation
for each experience goal. You can see the
results in table 2:
Mean Standard
Deviation
Attractive 4.17 0.33
Confusing 1.83 1.07
Entertaining 3.67 0.93
Annoying 1.33 0.48
Helpful 4.33 0.50
Challenging 1.67 0.46
Table 2
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 successful.
ISSUES
Our first problem we were tasked with was
deciding upon a prototyping tool to utilize to
best represent our application. We ran into a
prototyping tool called Justinmind. It had
many customizable features and we were
pleased to find what could all log in at the
same time and work on it.
The next issue we ran into which we did not
realize until after our first paper prototype
was we originally did not have a home page
implementation. This was an issue because
it did not allow us to go home without
hitting the back button multiple times, and
our user testers were so frustrated.
The next issues we had were related to font
and color scheme. The font was too small
and illegible, the font color scheme we used
was too light that is yellow and the color for

11. 11
choosing room was too dark. This was an
issue because people who are colorblind
would not be able to differentiate the color.
WHAT WE WOULD DO
DIFFERENTLY
We realized how important back and home
page buttons are. We would be sure to
include a back option from the beginning, as
well as a home button to prevent the
frustration of users.
In regards to font size and color, we would
be sure to a font that is legible based upon
how far the prototype should be held away
from the eyes. We also will provide a
contrast between the background and text
colors.
Finally, we would actually code the
prototype and make it dynamic rather than
static. This would let us avoid many issues
we encountered, and it would actually be
functional rather than literally 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 was not 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 certain feature
that is inconvenient to use, does not do what
it is intended to or is not included at all.
ACKNOWLEDGEMENT
We would like to express our deepest
appreciation to all those who provided us the
possibility to complete this report. A special
gratitude to our HCI’s lecturer, Nor Anita
Fairos Binti Ismail, whose contribution in
stimulating suggestions and encouragement,
helped us to coordinate our project
especially in writing this report.
Thank you to our classmates who helped us
along in this iterative process by providing
feedback and input along the way. We
learned a great deal of information regarding
HCI. It is extremely valuable because many
of us will be applying these concepts to our
future lives and our technical field.