Building a Band for Musicians-A UX Case Study

Introducing Cassetter

It is difficult for musicians and bands to find each other to collaborate. They are using outdated technology that is not specifically built to find other musicians. A simple one-stop mobile app would be game-changing for musicians to be able to find each other.

Brief

Help musicians find bands and other musicians to collaborate with.

Users

Our User would be a musician who is looking to collaborate with other musicians. Responses from our survey showed that 75.3% of musicians stated that music was a hobby for them. So, we want this app to appeal to users who are practicing music for fun or for a career. Knowing these statistics, we want this app to appeal to users who are not only playing for fun, but we also wanted a space for career musicians to meet others as well.

Scope

We had 6 weeks to design and develop an iOS app to submit to the Apple Store.

Roles

Our team consisted of 3 UX designers, 2 iOS Developers, and our Project Manager.

Challenge

Find a musician’s pain points while searching for collaborators.

Solution

Surveys & Interviews. Prior to the start of our project, our PM assigned us tasks and due dates on Jira. This allowed us to stay on track to meet our 6-week deadline. It also was crucial to see the progress of our team since we were completing this entire project remotely.

Survey

We gathered as a team to brainstorm any assumptions and anti-assumptions that we had regarding musicians. This process helped to generate ideas and areas of opportunity for our product. What formats are they using to find musicians to collaborate with? How are they finding other people? What are they looking for when they collaborate? What content/information does the user want to access in the app?

With these questions in mind, we sent our survey through Google and received a total of 90 responses. We were somewhat surprised to find that only 16.7% of musicians said that they had a positive experience while trying to find other musicians to collaborate with.

Interviews

We were able to interview nine musicians in all different genres. Most of our interviewees were finding collaborators either by word of mouth, or by posting broad descriptions via social media. In going through their responses, we found that the biggest difficulty in finding other musicians was being able to filter people by genre, age, and commitment level. Using the platforms they currently have, it would be near impossible to find the perfect artist.

Affinity & Story Map

My team then collaborated using a Miro board listing the key pain points and goals that our users were having on our Affinity Map. Through careful consideration, we narrowed down the information we collected from our surveys and interviews to try and find our minimum viable product. We then took that information and created our Story Map. This helped us to have a visual outline of what goals our users wanted to accomplish and how we would go about doing that.

Persona

We combined all the challenges, goals, and frustrations and came up with our persona, Luke. He is a representative of our musician users. Luke is 27 years old, he lives in Seattle, WA, and is currently a part-time delivery driver. He plays guitar and is currently looking to become part of an established musical group. His goal is to find other musicians like him to collaborate with and is open to the possibility of making a music career in the future. Not only has he been frustrated with musicians who bail on sessions, but it has also been difficult for him to find musicians that fit into the specific criteria he’s looking for.

Focusing on the key goals of our persona, we developed our story map. The user's main goal is to find other musicians with similar interests to collaborate with.

Challenge

Musicians need an interface that will allow them to easily connect and collaborate with other musicians in their community.

Solution

We went back to the Miro board to do some collaboration and came up with a flow using a Site Map. This was how we determined what the main navigation bar should consist of.

Wireframes

We then grabbed some paper and started sketching some wireframe design ideas of what the app could look like. We each presented some sketched designs that included solutions that we could come up with for the pain points within our app. After, we compared the wireframes and narrowed it down to the designs that accomplished the MVP functions that we needed them to.

We came up with a starting point for our design ideas using a similar layout to some popular dating apps. Many of them have very simple, easy, usable layouts that we felt we could draw from. We wanted our app to have a more professional feel, but function in a similar way.

With all of our sketched wireframes designed. We collaborated on the key MVP elements we wanted to keep. The navigation bar seemed easily understood. The categories to search were relevant per the interview responses we received. We needed a way for the users to search by location to bring up the musicians that were the closest geographically to them.

We also wanted to make sure that we were meeting the MVP goals before including any extra features. We met with the developers and asked what they thought would be feasible features. It really helped us to hone in on what would be achievable in our 6-week timeline. They were able to let us know that the messaging part of our app is a lot bigger task to take on for developers then it looks on our design side of things. So, we went back to the drawing board and took that feature off altogether. This allowed us to focus on building out the profiles and search pages to make them even more efficient and intuitive.

Lo-fi Wireframes

Using Sketch, we started to layout our lo-fi wireframes. We were able to get a little more detail and add some elements that would help our User Testing. By being more precise about what would be on this app, we could get more detailed User Testing feedback that we could then take to our hi-fi designs.

User Testing First Round

We input our lo-fi wireframes into InVision. This allowed us to send a prototype out for user testing. I believe that user testing is one of the most useful parts of the whole project. It’s difficult to look at your own project objectively. By allowing outside users to try out the prototype, it opens the project up to be truly useful to the actual real-life users.

Feedback

The feedback from the first round of user testing went well. We found that some users weren't able to find where to set up a profile. Some users weren’t sure how to tell if they were looking for a band or a musician and how to tell the difference between the two profiles. We adjusted our wireframes to match the feedback we received then proceeded to implement our new ideas into the hi-fi wireframes.

Style Guide

At this point, our next step was to decide on a style guide. What did we want it to feel like? What type of person would be using our app? After searching different color schemes we liked off of design websites like Dribble, we decided to do a dark mode screen with orange as our stand out color. We knew it was risky, but we liked the way it stood out so we went with it.

Hi-fi’s

Using our Sitemap, Persona, and feedback from our first user testing, we started designing our hi-fi’s. We were really able to get into the details once we started adding color. It allowed us to see what would stand out to the user and what would draw their attention.

Our final round of user testing really helped us hone in on the details. We changed some color layouts that were confusing to users and clarified which profiles were bands vs single musicians. The testers also wanted to see consistency in our button choices throughout the app.

Finalizing Hi-fi’s

We updated our screens with feedback from our user testing. We combined and updated the elements that were the best received by the users.

More User Testing

We handed off all of our designs to the developers. We made sure to check in with them and our PM during our daily Sprint meetings to make sure they had everything they needed. We took every effort to clarify any questions that came up along the way.

Query

While the developers were discussing the features of our designs with the mentors, they had some questions. We had designed a scrolling horizontal bar to show different levels of commitment. They needed to know if that meant the scroll could go anywhere on the bar. Or if it would just go to the 3 options we had listed.

Explanation

Due to time constraints and abilities. We decided on having it only scroll to the 3 options listed under the bar. This kept it simplified and allowed us to get closer to our goal of getting this app into the app store as a team.

Continued Education

Design. It’s amazing all the information available to us. With some research, we were able to find incredible ideas to take back to our drawing board. I learned a great deal about color with this project. We researched through all different color combinations to make sure we were choosing an orange that would be modern and not outdated.

Developer Collaboration. I learned a lot about having clear communication throughout your team. The daily Sprint meetings and Friday Retrospectives were crucial for us to stay on track. It allowed us to come together and make sure our common goal was being met. We would look at our product design, what the developers were able to implement and compare that to our timeline.

Soft Skills

Feedback(giving & receiving). I found that it is important to stand up and make sure you are heard. Just like the rest of the group, each idea is crucial to get the best results possible. It’s the two heads are better than one theory. I also learned that active listening is imperative. It’s important to let others know you hear them. This allows for open communication and to let the team members know that their opinions are valuable and that they have been heard.

Leadership. I found that I gravitated to overseeing the information and designs that were being sent back and forth between group members. I came up with an idea to have one main copy of all of our designs. That way we could always refer to this main copy for any information. It also helped simplify the communication with our developers. Since we were doing this remotely, having one file to watch instead of multiple files from each designer made it easier to get the info they needed. I would meet with the designers every morning and make sure that our main copy was updated prior to continuing our day.

Thanks to my amazing team! Jill Smith, Lindsey Croston, Mathis Chevez, and Hunter McNeil. We put our blood sweat and tears into this project. My entire team had such a desire to make this app a success. I value each and every one of your insightful ideas. Also, thank you to our PM, Cameron Stuart, and our mentors, Spencer Rich, and Cooper Swenson. It’s amazing what can be accomplished through collaboration!