GR3 - Paper Prototyping
Prototype photos
Below is our first 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
Scenario Tasks
Observations
After significant user testing, our group recorded several observations from user testing and took into account suggestions from several test users. 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 2:
User 1: User 1 had an initial lack of intuition behind the timeframe in which to utilize the interface. User 1 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.
User 2: User 2 took some extra time to fiddle around with the interface, as if trying to find a functionality that did not exist. He later 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: User 3 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.
Through user testing, we have obtained valuable input that will be considered in our next iteration.