Symphony is a mobile-friendly website that helps connect musicians based on their gig and then assists with scheduling. Geared toward music students, Symphony makes it easier for musicians to find the right people to play in that important recital with. 



I started off by sketching and listing out features that I thought would solve the problems that I had gathered from interviewing people.

When I figured out the main features and functions, I jumped into Sketch and Invision and created a quick prototype.

After feedback from user tests, I created a more polished version of the above prototype.


Key Features


The Brand


The Process


When I started this project, I was running on a statement I heard from a camp counselor years ago - "Good accompanists are always high in demand." Based on that statement as well as the notion that finding group partners can often be difficult, I figured that finding people to play in a gig with could be a bad experience in general.

Of course, vague ideas aren't exactly reliable data to run on, so I reach out and interviewed as many serious musicians both currently in school and playing in the field as I could find. I then condensed the information I gathered from the interviews down to 2 personas: Erin and Rick. This allowed me to constantly reference them to ensure I was actively solving pain points.

To make the personas more tangible and easier to work with, I created scenarios and user journeys where Symphony could improve their overall experience with either a recital or a gig.

Crafting the Experience

First I made very low fidelity wireframes to figure out what features needed to be where to optimize the experience.

I focused heavily on 2 main work flows: finding gigs or people to play with and scheduling. To find gigs, I created cards for each gig. Each card displays basic information for each gig (date, piece(s) being played, who posted the gig, and any obligatory dates). 

For the scheduling dilemma, I created a block out system where users can create blocks of time that they don't want any practice sessions or rehearsals during. Each gig they participate in will draw from that information to create practice times that fit everyone's schedule.

After the preliminary wireframes, I created a very low-fidelity prototype. I ran the prototype through user testing to see if it worked for users the same way I envisioned.

After receiving feedback, I updated both the interface and a few of the features for a much cleaner, more thorough, and more finished project. 

While no major structural changes were needed, there were some clarity issues. For example, the initial scheduling mechanism wasn't reading as well as it should have been, so I reprioritized the hierarchy to bring more attention to instructions as well as shifted the layout to make the scheduling process easier to understand. Another area that needed clarification was the notification section. While they existed and the information was there, everything ran into each other and there ended up being a bit of an information overload. To combat that, I sectioned off notifications based on time and introduced color as a way to emphasize certain notifications.