Mobile Web application
Timeline: 2 Months
My Role: User Researcher, UI/UX Designer, Visual Designer, Front-end Developer
Tools: Adobe Photoshop, Bootstrap, Heroku, Github
Methods: User Interviews, Rapid Prototyping, Wireframing, A/B Testing
There's a variety of musical tastes. How do you let people listen to what they want? Synchronized is an app which allows EVERYONE to have an input.
Music is a necessity at many types of events. It sets the mood and creates a context which enables people to act a certain way. However, most events are filled with a diverse group of people so it is difficult to please everyone’s musical tastes. It is also hard to find music that will adequately enable every attendee to react appropriately for the specific event. There should be a way so that music at a particular event satisfies the majority of the attendees with minimal effort on their behalf.
Synchronized allows users to add songs to a playlist of any occasion not only before but most importantly, during the event. We have revolutionized the way playlist content is created- from individuals to now collaborative groups. By giving people the freedom to listen to what they want, everyone’s musical tastes will be satisfied. So... Create an event, share it, add songs to it, and listen!
Synchronized was designed and developed in an Intro to HCI course at UCSD. Our team of 3 journeyed through the meticulous process of building a mobile web-app utilizing aids such as Nielsen Heuristics and Google Analytics along the way. We progressed through various prototypes (starting from paper to the web) and iterated many times after user testing and feedback. The design process is outlined below.
Experience our application here: http://synchronized.herokuapp.com/
Inspirations & Pinpointing the Problem
There is no shortage of music apps that currently exist, but user interviews with fellow students revealed that people are still not completely satisfied. To get a better understanding of the problem and scenarios, I drew out storyboards which proposed some solutions:
We brainstormed big and small to see what features and solutions we could implement by observing current existing apps (not only music apps but also things that people use every day). We drew inspirations from many sources such as the voting feature in Google Moderator/Reddit, word clouds that is a visual display of the frequency of words in a text, iTunes' "Up Next" feature, Spotify's collaborative playlists, and curated playlists/radios based on moods/artists/etc. from Songza and Pandora.
With a bunch of ideas in mind, we picked out the features from each which users seemed to like and utilize. From the storyboards, we crafted "working" paper prototypes for each app idea we had to gather more feedback from our peers.
Our paper prototypes were then given to our peers and instructors for heuristic evaluations. Having more than one person evaluating our prototypes resulted in an overall increase in findings of potential bugs and also allowed us to figure out the severity of the bugs. Some noticeable violations that were found in our prototypes were: error prevention didn't exist, no undo's, and "delete" was unclear. With these errors pointed out, we made changes and began building. Some things we decided were: to simplify the user's options of events and users can click on "Edit Events" to organize/delete and implement "Cancel" as a way to "undo".
Building & Progress
After the initial prototype review, we were off to create the first deliverable with the main navigational pages. We utilized Google Sheets to make a development plan, which was updated weekly. This contained all our tasks, their assignment, and their progress. It can be viewed here.
The home page was the first thing we created and reiterated. From that, I created a diagram for the flow of the app. Below is the Photoshop mock-up of home page and its iteration built with HTML/CSS, then the app flow:
To build, we set up a Github repository and split the work amongst our team of three. One teammate managed the music streaming aspect (which ended up being Youtube links due to Spotify's/Soundcloud's APIs being spotty), another managed the backend database for storing events/song lists, and I dealt with the front-end and frameworks of the app.
Testing & Iterations
When our first build was done, we set off to do testing. Amongst potential users, we asked them to do a walk-through and complete some tasks such as creating an event and adding a song. Using the feedback, we were able to refine our app to be more intuitive and user-friendly. A user doing a walk-through is pictured below:
Major Issues found:
Dropdown menu overwhelming
Error Prevention nonexistent
Small text boxes hard to click, while big words for buttons
Vague wording (URL)
Increase text box sizes
Easier navigation buttons (Back & Home)
Headers with descriptive instructions
Beyond user testing in person, we also utilized Google Analytics to test different versions of some features. For example, we had two different versions of "creating a new event" and wanted to test for the understandability and efficiency of that action (keeping a "+" sign or having a "Create New Event" button). We found through Chi Squared test and T-test that users were not hindered by the "+" sign although it may be more "vague". We decided to stick with the "+" sign for minimalism and aesthetic purposes without damaging user experience. After many iterations, the app is how it is today!
Unfortunately, the end of the quarter came too soon and our group dispersed to work on other projects. The idea of this app is still very dear to me and there are a lot of things I wish we were able to implement in that short amount of time (like the voting function and streaming easily). However, I took the opportunity of this project to truly immerse myself into the design process (especially user testing) and front-end work. I hope to one day further develop this app from its limitations of being a web app to mobile.