2D Object “Paper” Prototype: A Sheet Music Player (Pick Up. Practice. Play.)
Scenario: The final project is intended to let you expand on a prototyping technique or techniques that you learned previously in the course, but with fewer constraints on the application domain or design. In addition, we would like your project to utilize at least two of the prototyping techniques we have explored in the course (A1 - A8). Remember that in one of our first discussions in the course, we talked about various motivations for creating a prototype. They generally fell into three categories, which can be summarized as exploring a design's desirability, feasibility, or usability.
Challenge: So the basic requirement is that, whatever you make, you must be able to evaluate this prototype and evaluate how it satisfies one of those three goals. This can be accomplished by a small user test or a demo in which you solicit feedback. You should consider this requirement as your plan your prototype and articulate how you will conduct that evaluation.
The Design
For this final project, I wanted to implement an idea that I have had for a few months now. As a musician, I have always wanted to be able to hear what a particular piece of music sounds like without having to play it on an instrument or find a recording online. When a singer is practicing for a performance or an instrumentalist has forgotten their instrument, a “sheet music player” would provide a way to play the printed notes on a page with perfect pitch!
I returned to my design notebook and found my original sketch:
The above object is designed to be small enough to fit into a user’s pocket – providing a portable way to play sheet music on the go. The handheld device features a camera to read the music and a speaker to play it. As the user moves the device across the page, the music plays according to the key marked at the top of the staff. In this project, I seek to test this device’s desirability and usability.
For this final assignment, I decided to use the following techniques for various reasons:
Paper Prototyping to quickly iterate for size and usability constraints. Using cardboard, paper and a sketched UI, the paper device can be changed frequently during pilot testing.
2D Object Prototyping to create a “hi-fidelity” prototype worthy of a real user test. This device can be cleanly cut by a laser cutter in the dimensions verified by testing the paper prototype.
In addition to these techniques, I also employed a modified “Wizard of Oz” method to simulate a functioning prototype. During a user test, I planned on telling the user that I would be “manually calibrating” the device to their position, after which the desired note would play. With the user’s view blocked by my laptop screen, I would play the notes using MuseScore – a sheet music editing and playback tool.
The Design (Paper Prototype)
I modeled my paper prototype after the sketched out design. To decide on a valuable length, I measured the width of my own hand. Before formulating the width of the device, I thought about how it would move across the page. I decided on using a pair of glue-sticks to emulate wheels – their heights decided on the width of the device.
I spent an hour or two cutting mat board into the proper dimensions and attaching the pieces with a thin layer of wood glue:
The Analysis – Part 1
I brought this version of the prototype to Lukas, our teaching assistant, and he rolled it over a piece of sheet music that I sketched out by hand. He liked the look and feel of the device but he didn’t intuitively know what to do with it. Was is supposed to roll on its own? How fast could he roll it? What would happen if he scrolled backwards?
These were excellent questions as the arrow on the top implied a variety of ways that the device could potentially be used. In some user’s mind, they could think that the arrow meant the device was self-advancing – meaning that if they set it down on the paper, it would automatically advance to read the music. Likewise, the arrow could also imply that the device could only read music in one direction. Neither of these assumptions, however, were intended in the original design.
The Re-Design (2D-Object)
In response to this feedback, I decided that a way to show the device could be operated freely by the user – no matter the direction – would be valuable. In a discussion with nearby designers, one suggested that I implement a window to show which note was being played as well as which notes came before and after it.
I attempted to modify my design to demonstrate this new feature:
Unfortunately, this modification would never be able to adjust to the variety of scores that a user may attempt to read. In response to my attempt, my classmate, Daniel (link to his process blog), suggested I use a clear window instead. Within this window, he described a smaller section in the center that would keep track of which note was currently being played.
He sketched out this design, in order to better demonstrate the idea:
The box in the middle shows the smaller section, as described above. The longer box on the side also shows how the device would actually work – using a camera on the right to read in the note so that it could be played when it reached the center of the window. This feature better promotes the various use-cases that this prototype (and eventual product) could support.
With this sketch in mind, I set out to create the next version of the prototype! This time, I used 2D modeling techniques to design a device with a window in its upper portion. In order to support a large window and a handheld size, I decided to mimic the form-factor of a smartphone.
Using the height and width of an iPhone 5 as a guide (and doubling the depth), I drew the following lines for the laser cutter:
The design can be found on my OneDrive here!
After a quick print, the new prototype was ready to assemble:
Fully assembled, the sheet music reader looks a lot like a stud-finder with a speaker on the side. Turning the device around, you can see that there is a camera located on the left of the device. This is used to read the note as it passes beneath the lens – “loading the sound in its memory” to be played when it reaches the box in the center of the window.
The Analysis – Part 2
After using the device a couple of times myself, I set out to test it on a real user. To make the “Wizard of Oz” test easy for me to operate and conduct at the same time, I used a relatively simple song whose tune I could easily follow:
I set up the test as described at the beginning of this post, using the screen of my computer to block the operation of the device. My tested user was a singer who could read music and used the piano to play notes, when necessary. I described the following scenario to the user:
You are in a place where you do not have access to a musical instrument and you are given a piece of music to learn. This device allows you to hear the sheet music by simply hovering over a note. Try to use the device to learn the song and describe whether or not it is useful.
The user immediately grasped the concept, placing the device at the top of the score and moving it across the page from left to right. When asked if there was another way he thought of using the device, he said, "No. [He would] move it from left to right across the page to hear how the song was meant to sound."
He found the device useful, especially if he had never heard the piece of music before. When asked if he would use the device frequently, he said, "Yes”. These answers were satisfactory responses in regards to the Sheet Music Player’s desirability and usability! I am confident that this view would be shared among other musicians and I look forward to future feedback from the musical community in order to further develop this device.
In addition to this test, I also developed a short video describing the problem that the player seeks to solve as well as its use in-context. I also have included a short snippet of the user test itself to showcase its use in-the-wild:
< Previous Project











