HCDE 318 - AUTUMN 2017
ROADIE
|
RESEARCH FINDINGS
Our team interviewed hobbyist musicians which we defined as people who play music in their spare time and don’t make a living by performing, but occasionally play at small venues. We talked to them about their performance and practice processes in order to gain a better understanding of their characteristics, problems, and desires.
We interviewed six people ranging from 18 to 24 years old and found our users are passionate about their musical hobbies, practice at least once a week in various locations ranging from classrooms to their homes, and they often encounter technical issues during performances. We synthesized this information and created personas as representations of the people we interviewed. Additionally, we did a competitive analysis for four different existing products on the market that are targeted towards hobbyist musicians. We found that there are a wide range of music applications available, but most are for beginners and are either educational apps or apps that facilitate music writing. Interviews conducted by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya
|
PERSONAS
With information gathered from our user interviews, we created representations of our target demographic and their pain points. We used these personas to give an identity to our users and to determine what they need out of our product. Hobbyist musicians are our primary stakeholder, so it was important that we had a clear understanding of who they are in an empathetic way. These personas were based on our research findings and are a combination of the most salient traits of our users. From these traits, we created design requirements to address the highlighted needs. Through creating the personas we learned how to create empathy with storytelling.
Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya Visual Design by Pari Gabriel |
USER JOURNEY MAP
Based on the information gathered during our user interviews and the personas we created, we built our user’s journey map to pinpoint exact moments of frustration and anxiety and how these affect their performance. This provided us with clarity on where and when our solution should come into play. We made the map to get a better idea of the process the user goes through, when they encounter issues, when opportunities present themselves to address these issues, and to ask questions about what they need to be successful. We found that one of the main issues was the user’s steadily declining confidence throughout the journey. The criteria for what a user needs to be successful translates into the design requirements which ultimately set the stage for our solution’s features.
Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya Visual Design by Arsh Saroya |
DESIGN REQUIREMENTS
Based on the knowledge that our users were losing confidence during live performances, we wanted to design a solution that would improve their performance experience. After choosing to focus on improving sound balance for performers, we had to decide on the most important requirements of our solution. Looking back on the interviews we conducted, personas, and user journey map, we aggregated the data to determine our user's needs. This data led us to conclude that our solution had to:
Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya |
STORYBOARDS
The storyboards were explorations of how different technological solutions could address our problem statement. A variety of solutions were proposed, ranging from applications, to wearables, to an independent device that would plug into the mixing console. As a team, we were able to evaluate which ideas may best address our design requirements and would be the most accessible for our users. Our individual iterations helped us draw inspiration from a number of ideas by branching out to explore design solutions and then focusing in on the most effective and feasible products.
After much discussion, we decided an application would best fit our user requirements. It would be the simplest and easiest and most financial accessible technology for a hobbyist musician to use. After deciding on a mobile application, we were able to begin creating the information architecture and underlying structure of our solution. Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya |
INFORMATION ARCHITECTURE
Visual Design by Arsh Saroya
Our information architecture shows the simplicity of our solution and how a user’s limited options can create a non-invasive experience and allow them to focus on performing. Creating this diagram helped us determine the pathways and general layout of our application. |
Visual Design by Sierramatice Karras, Pari Gabriel
We created additional documentation about our application’s hypothetical machine learning process. Roadie’s machine learning algorithm aggregates band and venue info, which has been inputted by the user and venues, into the algorithm’s knowledge. It then iterates upon this knowledge by listening to soundcheck through the phone’s microphone and ratings provided by users. With every repeat of this cycle, Roadie’s knowledge becomes more accurate and allows the application to create better and better sound settings. Once we had our flow for how the user would interact with the application, we had the foundation for creating the individual screens. We heavily referenced this visualization while creating our paper prototype. Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya |
PAPER PROTOTYPE
Based on our information architecture, which outlined all the possible paths our users could take, we sketched out the screens that make up our application. The paper prototypes were a low-fidelity mockup of three important task paths in our product which allowed us to test out design decisions in a low-stakes environment. The paper prototypes were our first venture into receiving feedback on our design solution from users and people outside of our class. We used the paper prototypes to get our design decisions on paper and ask users what their honest thoughts were on the application concept and features.
Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya |
USABILITY TESTING
We tested our paper prototype with users to see where we might need to improve. This was a quick and cheap low-fidelity method to see our ideas in the real world. We used the findings of this evaluation to modify and improve our design before creating wireframes.
Our results:
To address these findings we made a variety of changes to our design before the wireframe stage. We added a second button to our settings page, allowing the user to go through the sound check process multiple times or skip right to the performance stage. We also changed design copy in the "Listening to Sound Check" page which users found confusing or ambiguous to prompt the musician users to begin their sound check. To further highlight our solution's artificial intelligence aspect, we changed "View Recommended Settings" to "Generate Settings", which gives the user a hint that these settings are customized for them. "View Saved Settings" was changed to "Past Settings" to create less confusion and parallels ambiguity between the two buttons. Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya |
ANNOTATED WIREFRAMES
After conducting usability testing with our paper prototypes, we took the feedback and created annotated wireframes. These were meant to be clean low-fidelity mockups of every screen of our mobile application to illustrate what our solution looks like on a phone. Using the wireframes, we created key path scenarios to illustrate the most important flows in our application. These allowed us to think about transitions and necessary on-boarding features for our users. We received critiques on our wireframes from peers in our class and we used their comments and concerns to further refine the interface for our high-fidelity mockups.
Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya |
HIGH FIDELITY MOCK-UPS
In creating the final visual style, we had to think of the context of use for our application. Because our user would generally be using this in a dimly lit concert venue, we made the base color a dark grey. This makes the app less distracting to other concert-goers and easier on the eyes of the user. Yellow was chosen as the accent color because of its association with happiness, energy, and comfort while still being interesting and highly contrasting with our primary color. Many popular music applications, like Spotify and GarageBand, have a dark primary color with a bright accent color, a trait we wanted to include to further the user’s sense of familiarity.
|
Home Screen
|
Settings
|
Review
|
Sound Check
The high fidelity mockups allowed us to bring a product to life that we have spent 10 weeks researching, creating, and refining. While the wireframes set the stage for our high fidelity mockups, they did not prepare us for is how to introduce our machine learning algorithm to the user and the many small design decisions surrounding color choices and visual style. Through creating these mockups and presenting them to industry professionals we learned that context is important. Whether we focus on the physical context of use for the application, or the user’s context surrounding their knowledge of mixing consoles, it is of the utmost importance to empathize and understand where and with what knowledge a user is interacting with your product. Content by Reine Abubakar, Pari Gabriel, Sierramatice Karras, Arsh Saroya Visual Design by Pari Gabriel, Arsh Saroya |
REFLECTION
The most challenging part of this project was the difficulty in simplifying such a complex process. Mixing consoles are often complicated devices that only professionals are able to manipulate, so we had to find a way to translate the physical features and abilities of mixing consoles into a simple application that was usable by anybody, regardless of their technical knowledge. We had to make difficult decisions on how simplistic and abstract we wanted our displays and interactions to be.
As we worked on our solution, we found that the easiest way to display soundboard settings was to implement an interface that imitated a mixing console without being too literal in our application of the features. While creating these pages, our team was surprised to find that some of the real-life soundboard features, such as knobs, did not translate into an intuitive interaction on the screen. If we had more time, our team would have conducted more user interviews to gain a broader perspective of the hobbyist musician practice and performance experiences. Additionally, we would have liked to conduct usability testing on our high fidelity prototypes by asking our interviewees to complete the salient tasks of our application. This would have allowed us to further refine our designs. Site Design by Pari Gabriel, Sierramatice Karras |