GR6 - User Testing

Design

One of the most important design considerations that we changed from our paper prototype to our final design was to allow the user to create events from the homepage, in addition to search for them. We recognized that the important distinction between our two main classes of users, party-goers and party promoters, was their primary tasks were searching and creating parties respectively. The original design only had a search bar on the main page, which only allowed partygoers to look for their event. If the search came up empty, there would be a link to create an event. This is not ideal for the party promoter because the interface is not easily learnable nor is it accessible. Therefore, we created two toggle buttons on the homepage to allow both user classes to easily access their primary tasks from the homepage.

One of our user tests pointed out that they didn’t know what they could type in the search bar to effectively find parties. We realized this was a problem with usability and that it might cause errors if the user tries to find their event by date and cannot find it. Therefore, we came up with two solutions: to either create tooltips that would appear when the user clicks on the search bar or to display a watermark tip in the existing search bar that would disappear when the user clicked to focus on the search bar. We chose the later of the two choices because it would be more visible to the user since it appears by default and also because it was consistent with other search engines like Grooveshark, Pandora, and Last.fm that all use watermark tips.

Lastly, we made some cosmetic changes to the splash image to reduce its look as a button. Some users tried to click on the splash image, for no reason but that they wanted more interaction. Because each image has a border around it, it gives it the slight affordance that makes it look like a button. Thus, we removed this border to make them look more like pure images.

Implementation

Evaluation

             We appreciate you taking the time to partake in our evaluation.  Our website is called RemotePlaylist and it enables users to upload, download, and browse music that are being played at variety of different venues.  As a partygoer, you can search for an existing party or you may create a party of your own.   As the website states, “RemotePlaylist is a social music recommendation engine that lets you request your favorite songs before going to the actual party. That way, you know you're going to have a good night before even leaving the door.”

Users were selected randomly among the MIT population.  We would ask people to take a few minutes to test out our design.  The user testers were generally within the demographic that the website was geared toward:  college students with an interest in music and fraternity parties, and did not have extensive knowledge of user interface design.  Users would first take a couple moments to look at the icons before

Scenario Tasks

1. Create an account and log in.

2. Search for a specific party

3. Create a party of your own. 

4.  Browse through a list of parties and click on the desired venue.  The user now has access to a list of songs associated with the party

5.  Play song the playlist

6.  Upload a song onto the playlist

7.   Rate a song using likes or dislikes

8.   Log out

1. One user noted that while the buttons on the front page add to the aesthetic value of the front page, he was tempted to click on them. 
2. There currently does not exist a discernable ordering of parties.   
3. There currently does not exist a method through which users can browse parties according to specific fields:  time, date, location, party playlist rating
4. There isn’t an option to perform an advanced search. 
5. When uploading a song, the program does not check for duplicates. 
   

Task 1:       Given their size and contrast to the background, it is conceivable that  they give off the affordance of a button.  Nonetheless, this was a tradeoff that we were willing to make because the icons are able to succinctly describe verbally and visually the function of the website.  (Minor, button affordances)

Task 2:    This will require figuring out a way to incorporate likes/dislikes into the position in which the parties are ordered.  (Major, Flexibility and efficiency)

Task 3:   One possible solution is to incorporate a tab that allows the user to reorder parties by different fields, in a manner similar to Itunes, which allows users to order music through song title, artists, and length.  This can be done by drawing information from the database to create a dynamic view of partylists. (Major, Flexibility and efficiency)

Task 4.  To correct this issue, we will have to find matches from in the database for a specific set of fields that the user would like to search for :  (i.e.  DJ Zeus, City:  New York or Boston)  (Minor, User Control and Freedom)  

Task 5:  In order to prevent duplicate songs, we will need to match check songs that and double check that there aren’t any songs with the exact entries for the following fields: song/title, file size, track length.   (Minor, Error Prevention)

Reflection