...
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.
| Wiki Markup |
|---|
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\! |
...
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 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:
User1User 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.
User2User 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.
Iteration 2:
User 1: User 1 The user had an initial lack of intuition behind the timeframe time frame in which to utilize the interface. User 1 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: 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 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: 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.
Through Through user testing, we have obtained valuable input that will be considered in our next iteration.
Prototype iteration
Change 1:
Instead of using the number of likes and dislikes to rate the songs, we have decided to adhere to a 5 star rating system instead. This will enable the user to provide more information on his or her interest in a particular song, and provides a more accurate picture of how popular a song by rating songs through a highest average rating.
Change 2:
Another change that is to move from a playlist/song centric user interface to a party centric user interface. While the interface still adheres 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 time, date , and location.
...