In my experience as a pianist, I noticed how hard it can be to find sheet music that lives in the public domain. There are sheet music library sites that exist, but they have outdated style, can be hard to navigate, and often aren’t optimized for different devices. This problem is faced by classical musicians, both professional and amateur, who use public domain libraries to search for sheet music but often spend too much time searching due to complex interfaces and inefficient search methods.
My goal was to improve the overall user experience and create a more modern, efficient, accessible way to search for public domain music. I did this through human centered design methodology.
As the sole creator of this application, I performed all roles of researching, designing, prototyping, and testing throughout its development.
By examining IMSLP, MuseScore, and other sheet music libraries, I was able to decide which features of the existing libraries were the most and least useful. I gained insights on how I could better design my application, extracting all of the positive features and leaving behind the negative ones. Some of the things I knew that I wanted to bring over from these included extensive search features, good information architecture, ability to listen to recordings, and more. I was able to find several negative things such as the search reverting to Google, unappealing theme, and having to download a piece before viewing it full screen.
I composed a screener survey and posted it on several forms of social media. The survey gave me valuable data such as how often users are searching for music, whether professional or amateur, which devices they are using, and more.
From the survey, I picked out four individuals willing to do virtual interviews. I then conducted the interviews virtually over Zoom, taking notes and recording as necessary. The most important pieces of information I gathered were related to the search features of existing websites. I was surprised to learn that when visiting a site, musicians typically have a piece in mind that they are going to search for. There is a very low chance that someone will come to the site just to spend time looking around in an explore section.
By mapping out responses from interviewees, I was able to visualize what was most important to potential users. In addition to several other things, something that stood out most during this phase was the overwhelming response in regard to device use. Out of all of the interviewees, none of them ever searched for music on their mobile device. Users said that they always use a desktop or tablet to view their sheet music. This was important because I was able to come to the conclusion that designing a mobile app would be unproductive.
Next I created two empathy maps that would lead me to better, well thought-out user personas. I identified my main users by two different categories, casual and professional. By performing this exercise, I was able to reflect on how each user might think or feel while interacting with the product and performing certain actions. This furthered my understanding of what features should be included or excluded from the app.
Writing out all of the user stories helped me visualize all of the tasks to be accomplished when designing the application. Creating this was making one big, prioritized to-do list that allowed for more efficient ideating and designing later on.
The first, and perhaps most crucial, step to building the application was creating a site map. This was one of the most fulfilling parts because I was able to define the overarching layout of the application and this new visual served as a to-do list of all of the pages I needed to design.
This step was also another exciting step because I got to start thinking about the application in a logical sense, and what a user will need to accomplish on each page in order to efficiently move through each red route.
To finish ideating the application, I sketched out some basic screen layouts for each red route.
After that I used Figma to turn those ideas into wireframes. Going through these steps was important because I was able to think solely about the layout of the app and how the user interacts with it, without worrying about color, typography, and other major design factors.
This was the step when I got to choose color and typography and make all of the small design decisions that make up the visual feel of the application. To begin this process I started out by making a mood board. This allowed me to visualize how I wanted my application to look and feel, and gave me inspiration on design ideas as well as motives behind those.
At this stage, I found it really important to stay organized and have a laid out design system. I made a brand style guide with all of the colors, fonts, spacing, etc that I would use to build my application.
I then built a component library, comprised of all of the small components I would use to build the application such as navigation bar, buttons, cards, icons, etc. This was an important step because as soon as I finished this, I was able to just drag-and-drop components to my application, speeding up my overall process and making for great maintainability.
Using Figma, I brought my wireframes to life by incorporating all of the color and typography that I laid out in my design system. In addition to an organized design system, I like to keep my components well organized in a library so that I can pull from it as I build. This allows me to change every instance of a single component later on, making for easier maintenance and changeability.
Figma’s easy-to-use prototyping tool allowed me to make a high detail prototype in which a user can click buttons, and navigate pages as if it were a working iPad application.
To test out the usability of the application and find any user difficulties, I performed several moderated remote usability testing interviews. Users ranged from amateur to professional.
I gained three major insights from these sessions:
1. It wasn't clear enough that you could search for a composer.
The placeholder text in the search bar said "Search for your favorite sheet music" which led users to think you could only search for music, when in fact you can search for music, composer, and more.
2. Several buttons had functions that were unclear.
Some buttons, like the bookmark button, had unclear intentions to new users.
3. Users had difficulty finding bookmarked pieces.
When asked to find their bookmarked pieces, users were unsure where it was located on the site. Because the section was labeled "My Library" originally, users didn't make the correlation.
To fix the issues above, I made several changes to the application.
1. I changed the placeholder text in the search bar to say "Start searching for your favorite sheet music or composer."
This lets the user know that they can search for more than just the title of a piece.
2. I added several labels to buttons, such as the bookmark button, in order to let the user know what each button does.
In order to keep the neatness of the application, I only added these labels in spots where space allowed. This teaches the user what the icon is, so that they can carry that information to the next time they see the icon without a label.
3. I changed all instances of "My Library" to be called "My Bookmarked Pieces."
This makes a stronger correlation between the bookmark button and the bookmark page, making it easier for the user to navigate the site. In addition to this, I added a new section to the home screen. When logged in, the user will now see a section titled "My Bookmarked Pieces" right on the front page, so they don't have to navigate to the bookmarked page to find them.
From start to finish I gained a ton of experience and I learned a few major lessons.
Importance of Research and Testing
If you don't do the proper research and gather enough information about what you are making, you could make a potentially useless app. I learned how critical it is to find out what users are looking for and design with them in mind, not yourself.
Reusability and Instancing
I learned the importance of creating a solid foundation of design components that lead to a better building experience down the road. The small design system and component library I built set me up for success because it made my designs extremely easy to tweak later on, and in less time.
Eye for Design
I realized how much work goes into making very small design decisions that make up the "feel" of an application, and I am excited to keep refining my style and improving my eye for web design.