GR3 - Paper Prototyping

Prototype photos

Below is our second paper prototype of Remote Playlist. We created an empty page template on paper and cut out different image/text elements to place on the template. The functions we decided to include in the paper prototype include login, signup, creating party playlists, uploading songs, and voting on songs.

After our users sign up and login, they are greeted on the top right corner with "Welcome, [username]". There is a splash image that gives the user some directions on how to use the website. We plan to simplify this image by showing a three step procedure: 1. Create a party playlist, 2. Vote on songs you like, 3. Party like a rockstar!

Our party promoter user just created a new playlist for "Mardi Gras Party." He entered the party information on the homepage [figure. 1] and is shown an empty playlist with an "upload track" that open a file selection dialogue when clicked. We plan to include a "Share" feature in future iterations that give the user the options to place the link to this playlist on Facebook and other social media sites.

After our party goer user searches for "Mardi Gras," he is shown a list of parties with the closest match appearing first. We plan to include more information about the party including date/time in future iterations.

One of our "party goer" users finds the "Mardi Gras Party" and sees that there is little to no music on the playlist. He attempts to upload music by clicking on the "Upload track" and votes for music by clicking on the thumbs up icon.

Briefing

The two major users types were the party promoter and the party goer. The party promoter user approached the website with the background of being in charge of promoting his or her event. The party goer was characterized as being a typical college student that often went to parties on the weekends and was familiar with the format of listening to music in a party setting.

Scenario Tasks

We gave the users different tasks based on their user type. The party promoter user was tasked first with creating an event, then uploading at least one song to their event's playlist. The party goer user was tasked with finding the event they planned on attending and voting on a song in the playlist of that event.

Observations

After observing several user test cases, our group recorded observations and took into account suggestions from several test users to create an additional iteration of our design.  In most cases, the user interface was simple and easy to pick up on a first test run.  Nonetheless, we recorded certain observations of user behavior and pointed out errors that may need to be addressed for future iterations.  

Iteration 1:

User 1: The user found it easy to search for playlists and upload music but did not understand how the playlists were being created because we did not provide a mechanism for it yet. We later added this interface directly on the home page that allows a user (who must be logged in) to create a playlist.

User 2: The user wanted an interface where he could search for parties after making the initial search, but didn't see the search bar that he expected when he was viewing the list of parties. We added a search bar to the search results page.

Iteration 2:

User 1:  The user had an initial lack of intuition behind the time frame in which to utilize the interface. He was confused as to whether he was accessing the interface during the party, or just viewing music prior to it. He expressed later on that he would have preferred to provide feedback during the party instead of before. His task was to upload a song, and he thought he could drag and drop from the desktop into the interface.

User 2:  The user suggested that the user interface should incorporate a log of parties that the user has previously visited, thus adding an extra dimension of information regarding previous parties and music.  

User 3:  The user recommended an auto-complete functionality for searches, as well as more advanced search capabilities: one that would allow the user to pinpoint a party by time, date, and location. In addition, user 3 recommended to consider enabling the user to search for other people’s music, pull the file, and add a song to the user’s personal play list.

Prototype iteration

• Added a splash info on the homepage to explain the purpose and usage of RemotePlaylist
• Added a search bar to the results page to allow users to search again without hitting the back button on their browser 
• Created a form to allow users to create parties on the front page instead of some secret admin interface 
• Instead of using a 5 star rating system, we use rate a song based on the number of likes and dislikes. This will give us a better ratio to determine which songs should be play or not played. If we were to use the 5 star rating system, we would probably see rating normally distributed and centered around 3.
• In a future iteration, we will try to move from a playlist/song centric user interface to a party centric user interface.  While the interface will still adhere to the core concept of allowing users to rate, upload, and download songs, the user interface will also aggregate information on the user's previous party-going history, and pinpoint a specific party through date, time, and location.