Company
CMPM 131 (Class Course)
Team
Music Room Reserver
Time
10 weeks
Role
Tools
Website
UX/UI Designer
Figma / HTML, CSS, JS / Boba
Trying to make reservations for anything should be fast and simple. At a restaurant, you can call or go online and within a matter of seconds, you have reserved a table. No one likes going through a tedious process that should take no longer than a minute or two. We observed this behavior was more prevalent within a certain niche at UCSC.
​
Our team (in my FIRST group design class) wanted to help the music community within our school. We were able to get in contact with Peter Reed, the Stevenson Facilities Manager, who also oversaw the Josh Alper Marine Music Room in Stevenson College. Though the music room reservation system was digital, their current website could use improvements to make the system more streamlined and efficient. This was a simple project idea while having a community that’s sizeable enough to make it challenging to test.
Peter Reed, the College Programs Coordinator for Stevenson, agreed to be interviewed by our group and what we found were the following.
USER RESEARCH
Stevenson Room Problems
1. Minimal number of time slots
The reason the only reservable times are from 1:30-3:30 pm and 6-9 pm every day is because they are based on the times staff is around. They have to provide the student with a key to get inside and hold the student’s ID while they’re using the room. The students “get the key from the college office over here and that closes at 4pm. And if we ended [the time slot] at 4 pm people would be showing up at 4:05 to be able to put the key away.”
2. Extending hours leaves room for students to use it for other recreational purposes.
In the past, students were going in to smoke or drink. “We can't have a space like that as a part of our educational program here. We want to keep it for folks who are playing music.”
Online Reservation Problems
As for the online reservation process, the problems lie in the tedious work for the staff. Sign-ups are done through:
-
Google Forms for the students’ convenience of connecting to a Google Calendar
-
Then the process of checking off whether there are time conflicts are handled automatically by Zapier
​
Because there are two good apps in place, our group needed to keep our design ideas convenient and the experience consistently streamlined when we created our website.
Current Josh Alper website with reservation system
"I want them [students] doing things like higher order cognitive issues, developing educational programs rather than just checking if there's no conflict and sending an email.”
- Peter Reed
What we decided to focus on is making sure the rules and available time slots are more obviously displayed when students go online to reserve the Josh Alper Marines Music Room. By having clear time conflicts and automatic approval, we could replace the two apps with one useful website.
PERSONAS
Person who reserves the room has to be a Stevenson affiliate
Deals with students who misuse the room, like cleaning up after alcohol or drug use
Someone who would make noise complaints and prefer a quiet environment
Peter discussed the issues that involved the staff, like overseeing the room key, which is what Gwen was in charge of
Side note: As we worked on the features of the system, and especially when we walked through one of our latest versions of it with Peter, we became increasingly aware of the connection between the manager’s role and the system as a whole. A music room reservation system manager persona with their needs, worries, etc. was necessary to consider while creating the system, so it would be a persona that would be added in the theoretical redo of the assignment.
COMPETITIVE ANALYSIS & REQUIREMENTS
We looked at 3 other indirect ‘competitors’ that use a similar functionality when reserving rooms on our campus but that target different customers in relation to the current system we were working on:
-
UCSC Library Study Room Reservation
-
BSOE Conference Room Event Listings
-
SOMeCA Room Reservation System
Our team separated our findings on these ‘competitors’ into categories based on their functionality, content, visual design, and then drafted a brief summary of the data collected, which includes the strengths and weaknesses of each ‘competitor’.
From the data collected in our competitive analysis, our team created a list of both functional and non-functional requirements in priority order (high to low) that we kept in mind when creating this new website for the Josh Alper Marine Music Room
Functional requirements
​
-
Website must always display up-to-date information about the availability of the room.
-
High priority. Data that is not up-to-date would cause many other problems for the users.
-
-
Users that create a reservation & admin have the ability to remove/revoke a reservation.
-
High priority. People often make mistakes or have other events come up and having the ability to undo it is necessary. Also, admins must be able to moderate who may and may not make reservations.
-
-
Users that create a reservation will be charged if they cancel/revoke it after a set deadline or do not attend
-
Medium priority. This would provide an incentive to uphold a reservation that, if not attended, could have been given to another person. (A staff member would have to check if the user attended or not. Most likely the key-giver.)
-
-
When a new reservation is created it is added to the users’ calendar automatically.
-
Medium priority. The user can see how the event interacts with their current schedule. This will also serve as a reminder so that the user does not have to create the event themselves.
-
Non-functional requirements
​
-
Website must be accessible on all modern personal devices. (ex. Phones & Tablets)
-
High priority. Site usage will not be limited to personal non-portable computers. (system currently in place appears incorrectly/user unfriendly on phones)
-
-
All data is transferred and stored securely. Data is only accessible by the admin.
-
High priority. Required by college.
-
-
Administrator side of app must be easy to use, intuitive, and accessible from anywhere.
-
Medium priority. An admin user voiced their concerns about the difficulty in learning another set of administrative tools. Access to the admin side of the app should not be restricted to single devices. (ex. What if the admin is traveling?)
-
-
Website should be compact and easily modifiable.
-
Medium priority. The app should be able to be kept up to date while the systems around it change. (ex. Student affiliation is removed, or more time slots become available)
-
As we worked through the requirements listed above, we learned that we had to prioritize the requirements even further, beyond the low-medium-high scale that we used originally, because we needed to accommodate for the time we ultimately had to actually build the system (HTML, CSS, JS) and the time we had within the quarter (10 weeks).
This involved adhering to the requirements that would be implemented in the main user experience of the system on the website while putting the auxiliary features on hold, such as the external database. Therefore, some of the requirements, such as the mobile phone functionality and the actual external database implementation, had to be set aside in favor of our focus on the user experience of the system.
LOW FIDELITY PROTOTYPE
(WITH USERS AND WIREFRAMES)
Our prototype is meant to replace the Josh Alper Marines Music Room reservation site. The primary actions a person can do are see available time slots, reserve a time slot, and cancel a reservation. The high priority functional requirements are listed below with the features of our prototype that meet the requirements:
1. Website must always display up-to-date information about the availability of the room.
The homepage for reservation displays a monthly calendar with color-coded time slots shown on each day. The colors are explained with a key displayed above the calendar.
​
2. Users that create a reservation & an admin have the ability to remove/revoke a reservation.
At first we forgot to include the cancellation feature, but when we worked with the users we added in three places to cancel a reservation: the homepage of the music room, in a column of “My reservations,” and a button at the end of a successful reservation.
When we started making our prototype, we made a storyboard of how we would assume the users would navigate through the website. The main task during our user tests, was to act as Stevenson affiliates trying to reserve the Josh Alpers Marines Music Room on May 16 from 1 to 3 pm. Below is the paper prototype we gave them to first interact with.
Our group conducted a total of 6 individual user testing sessions, and using all the feedback from our users (we compiled a storyboard for users to physically interact with)
We edited the paper prototype to include what they suggested which is shown below
Two buttons to start and cancel a reservation
Increased month name size and added a column for “My Reservations”
Scrollable list of rules, renamed back button, and view of “My Reservations”
Renamed back button and view of
“My Reservations”
Rephrased message with more focus on time slot, a cancellation button, and view of “My Reservations” showing the added reservation
Added cancellation pop-up with view of
“My Reservations”
Rephrased description, redesigned text fields, and renamed back button
From the edited paper prototype, below is what our first wireframe looked like from the user feedback
As it was, the users were faced with
-
Huge block of text, but our interface would welcome the users with pictures and a brief description of the Josh Alper Marines Music Room
-
For the reservation process, the users will get to interact with a clearly labeled calendar instead of the bland Google Calendar built into the current site
-
The reservation and cancellation processes are done in very simple pop-up windows that allow a smooth run-through for the primary tasks of the site
Overall, we aimed to make the reservation process simple, intuitive, and streamlined while keeping in mind design principles and user feedback. With the compilation of our user’s responses on the paper prototype, we were able to discover which additional features to implement in our prototype successfully.
After making the sketches of our wireframe as seen above, we decided to make a working virtual wireframe by using Figma. There we made a better visual representation of how we would like the layout of the updated site to look like, including descriptions, colors, and button shapes. It was with this prototype that we performed our cognitive walkthrough with.
HIGH FIDELITY INSPECTION
During our high fidelity inspection, we came up with two main tasks we wanted the user to test. Our goal was to make the reservation process intuitive and fast to use, so we focused on how well we accomplished that goal. The first task we assigned our users to do was make a reservation as that is the main task of our application. Our second task was to exit out and cancel the same reservation.
Inspection Problems & Solutions
In our personal cognitive walkthroughs, we found some problems within our application. Each of those are identified in the list below as well as solutions we made to combat them.
The home page did not give an adequate description of the room and doesn’t say it is for Stevenson affiliates only.
For the homepage, we will add additional information pertaining to the room, including the restriction that the music room is only open to Stevenson affiliates.
We also realised that there are some fields in our sign in page that were unnecessary as they did not contribute to the form validation process.
For the login screen, we will prompt the user to enter in their CruzID and Gold password to login to their account to match other UCSC sites.
In our calendar page, we noticed there was no visual indicator when the mouse was hovering over the dates besides the cursor changing from an arrow to a hand.
For the calendar page, we will implement a feature that makes the colored circle around each date bigger as the user hovers their cursor over that date.
We noticed that the scrollable list of the room’s terms of service was text-heavy. One user stated that they felt like disregarding the regulations and just moving forward, which is good for speed but not for policy reassurance.
For the regulations popup, we will condense the rules of the room into short paragraphs and differentiate them using bullet points.
Lastly, the last screen never specifies which office to retrieve the key from and where it is located.
For the confirmation screen, we will add information about the Stevenson Housing Office and how to arrive there to pick up the key for the music room.
Changes/updates made throughout this course was how the calendar page looked from the paper wireframe to the digital wireframe in Figma. I designed a calendar page that made its interface show more information in one place and look more aesthetically pleasing according to our users.
EXPERT USER EVALUATION
In order to perform our expert user evaluation, our group decided to do a cognitive walkthrough of our high fidelity prototype. We came up with three tasks for the user to complete based on the most necessary aspects of a reservation website. We hoped to find out from our expert user how intuitive each button was to use and how fast the user could complete all three tasks.
​
We requested our expert user, Peter Reed, to think out-loud as he went through the tasks that we presented him with and recorded his remarks with his permission. He managed to perform each task in under 5 minutes without any help from us. The only errors that came up with the buttons he used were from attempting multiple things which will be described later. With his expert point of view, we were able to get some insights that we would not have had ourselves.
​
Peter stated, “I’m colourblind, but I’m guessing that it’s red for no reservations and blue for yes you can have a reservation that day?”
Peter had a hard time differentiating the colors on the calendar due to colour blindness.
This example where it was hard for Peter to identify which calendar circles were blue or red (available or booked) because he’s colourblind, told us we needed to make the system more accessible, and he suggested to use shapes in addition to colors to identify the availability of the room on certain dates.
Project Context
​
I am also colourblind so when designing the calendar for the hi-fi, I made sure I chose red and blue hex values that could be easily distinguishable, but when handing the hi-fi off to a non colourblind developer, he did not check the hex values, thus creating this issue
OUTCOME
With respect to our current iteration and one user login, Peter said our system did resolve the time conflicts. Before, the individual had to check off the time conflicts, “but now they do not, which is good.” We wanted to measure how quickly he could finish each task. His first run-through the reservation and cancellation process took 1 minute and 58 seconds to complete while talking through each page. Without talking, Peter went through all three tasks in a total of 16 seconds.
After our cognitive walkthrough with Peter we updated our high-fidelity prototype to match the policies of the Josh Alper Marines Room and better suit how Peter thought the interface should look. Now our prototype allows multiple reservations, a properly formatted title on the home page, and a calendar that’s easier to read by making it smaller and accessible (colour-blind friendly).