Owen Haines

HMI Final Project Report

Analysis and Redesign of Room Reservation Systems at UVA

At the University of Virginia academic and activity spaces are available for CIO’s

(Contracted Independent Organizations) to book for events and general use. While rooms in

just about every building are available to book, there is no one unified reservation system for all

spaces. Activity spaces are reserved separately from academic rooms, and schools such as the

engineering and nursing schools handle reservations independently. The closest thing to a

unified system available is The Source which is used to reserve academic spaces in college

buildings. The Source is used both by requesters making room reservations and schedulers who

confirm bookings. In this report I will examine The Source from the perspective as a requester

as it exists currently and suggest improvements to be made in order to create an efficient and

easy to use room reservation service for all buildings at UVA.

Analysis of The Source

The login screen for the source first presents a couple menu options. “Create an Event”,

“See Available Locations”, and “Search for Events”. Upon selecting the “Create an Event” button

a new page (Appendix I) is called where the user fills out information about the event in order

to make a reservation request. This page is where the majority of issues with the system are

present. The first problem in the page is unnecessary redundancy for the user. Most people are

only associated with one or two CIO’s so having to search a list of all CIOs is an unneeded

redundancy, especially for people booking hundreds of rooms throughout the year. The most
significant and impactful design flaw with this page is the lack of constraints throughout the

process. Many of the data entry fields offer no restrictions, allowing you to do things such as

select dates in the past or during break, reserve as any organization, and select rooms that are

not already booked. This can increase the workload for event schedulers who have to verify all

the information provided. Additionally, the lack of signifiers on room availability is particularly

troublesome as it requires the user to search through a huge list of rooms with no indication of

whether or not they are available to book until they have been selected. This frequently

increases the amount of time to find a room significantly. In order to illustrate the impacts of

this lack of signifiers, I timed 8 people in finding a room for a 30-person meeting at a given time.

The times are shown below with times of people familiar with the system in blue and those not

familiar in orange.

Though there is no real trend to highlight here, the fact that any times are greater than ten

seconds is representative of a flawed system as all trials except two required the user to make

multiple guesses before finding an available room. The fact that any guessing at all is necessary

reflects poorly on the system. These times are only extended when the requester needs a

specific type of room or is booking a repeated event. Another reason for some of the lengthier

times is that poor implementation of the scrollbar for the room selection menu causes it to

jump around semi-randomly making it very difficult to pick the desired room. With the current

design and implementation speed essentially comes down to luck in being able to guess which

rooms will not be reserved. An additional issue with the system is that there is poor mapping,
making it difficult for users to visualize the dates they are booking. Essentially when booking

multiple dates, they are listed out in order with seemingly random color coding for each date.

This requires the user to take additional time to confirm that the listed dates are the dates that

they want to book.

Outside of making books the method for finding an event that you have already

requested is also flawed. Selecting the “Search for Events” button from the home screen pulls

up a screen with just a search bar and a drop-down menu for filtering. In order to view

requested events for confirmation or editing the user has to go to the bottom of the drop-down

menu to just show the events for which they are the requester. This design choice shows a clear

misunderstanding of the purpose for this page. Nobody uses The Source to find events to

attend, it is only used to request bookings and edit them. With this purpose in mind it is clear

that the “Search for Events” page should only show events requested by the user. Another

possible explanation for the current design of this page is that it is used by scheduling workers

who need access to all event requests to confirm bookings. In this case it appears that the

current design unnecessarily shoe-holes two functionalities into one design by diminishing the

effectiveness of both and it would be more effective to separate the two purposes into

separate functional designs

Redesign Suggestion

The first and most obvious redesign proposal is that room bookings for all spaces on

grounds should be consolidated on The Source instead of using many different systems for

different types of rooms. This would make booking rooms significantly easier as the user
doesn’t need to search for the right site to book from. The design proposal (APPENDIX II) would

also implement a sign in system that contains on the users account what organizations they are

associated with and what rooms they have permission to book. This is the first step in

narrowing down options in order to speed up the room requesting process. Using a login

system could also help solve the problems that result from trying to make the system work for

both requesters and schedulers by having separate logins depending on the user’s role.

In redesigning the event creation page, the main goal was to add constraints and better

mental mapping to increase efficiency for booking requests. In this system the requester would

first fill out the information about the event including time, head count, and room type, all of

which would filter out the rooms that are not usable for the event. The user would then be able

to pick from a list of rooms that are actually available at the given times and dates for the given

purpose. Once a room was selected the booking would appear on a calendar instead of just a

list as it is much easier for the user to check that the bookings are as desired using this

mapping. The user can immediately see what weeks and days of the week the scheduled event

is on when looking at a calendar instead of a list. The calendar would also color code bookings

for repeated dates depending on if there happens to be a conflict on one of the days. The next

page would List all the info about the booking as well as the calendar and then allow the user to

confirm the booking. The page for viewing events would also contain a calendar with all of the

user’s events instead of having to search through other events to find requests for confirmation

or editing.
Conclusion

In general, the current design falters in that it was not designed in a manner reflective of

its actual use. By combining requester and scheduler options as well as unnecessary options,

The Source fails to accomplish its primary goal of providing a streamlined and efficient system

for users to request room bookings. The proposed design adds constraints and mapping in

order to streamline the process and minimize frustration. The clearest takeaway from this

analysis is the importance of understanding goals and purposes of a design in developing an

effective design. In this instance trying to add elements necessary for schedulers to the

requester interface causes complications and excessive confusion in making requests.

Application of a systems approach through which an understanding of the issue is developed

before narrowing in on a solution would have been instrumental in avoiding the many pitfalls of

this design, and is a vital step in creating any effective design.

APPENDIX I – Current Event Creation Dialogues

APPENDIX II – Redesign