🎻 Angular Violin
OVERVIEW
The Angular Violin is an electronically modified violin to be used by individuals with complete visual impairment for the purpose of reducing the learning curve associated with learning the appropriate finger positioning
This was a 13 week project that was completed during my 3A semester of school for an engineering design course. I worked alongside 4 of my classmates to bring this idea to life.
ROLE
User Research (Background Research, Personas, User Interviews, Journey Maps), Ideation, Prototyping & Testing
May -July 2019
Background
The purpose of this project was to design an instrument to be played by an individual with a disability. Upon a group consensus to explore visual impairment, our preliminary research revealed that the main frustration associated with learning an instrument like the violin was the slowed learning curve experienced when learning a new song due to the lack of information braille sheet music provides.
Problem Definition
To better understand the frustrations experienced by individuals with complete visual impairment we conducted individual secondary research surrounding the questions listed below,
Research Questions
How relevant is braille in today’s society?
How do people with visual impairments read and learn music?
How does the physical area of interaction impact a visually impaired individual's ability to play an instrument
Does string coarseness impact a person's ability to read braille in a meaningful way?
At what levels of learning music is sheet music used?
What difficulties are encountered when teaching people with visual impairments how to play an instrument
What materials are better at isolating vibrations?
Findings
Our research revealed that the main frustration associated with learning an instrument like the violin was the slowed learning curve experienced when learning a new song due to the lack of information braille sheet music provides.
Ideation
Having flushed out our problem space it was time to begin generating ideas using our ‘How Might We…” statement. Crazy 8’s is an effective idea generation activity where each person has 8 minutes to come up with 8 solutions to the HMW statement; 1 minute for each solution. From there, each person expanded on what they considered to be their strongest idea - the results are documented in the images below.
We then dot voted (individually) on the different aspects of each idea that we liked. The purpose of this was to decide which features should be baked into our eventual final design moving forward.
Our Decision
The ‘Angular Violin’ idea received the most love from group members thus we made the decision to move forward with that as our solution, with aspects of other ideas thrown in. The general solution was to use sensors along the neck of the violin, fitted with vibrations, to indicate where each finger should be placed to play the next note in a song (that would be uploaded to the violin). The strings would be replaced with angular velocity rollers to preserve the bowing motion of the real violin.
LFP Testing
The goal with this testing session was to compare the size, shape and weight of a real violin to our LFP. We wanted to maintain the structural integrity of a real violin so that the transition between our product and a real violin would be as seamless as possible.
We also wanted to compare the bowing motion between the two “instruments” to ensure our LFP mimicked the same motion to that of bowing a real violin.
We gave users a real violin and our LFP and had them compare.
Testing with 5 individuals, general consensus was:
the need for a more accurate bow size (compared to real violin bow)
structural integrity was preserved
missing the friction component that a bow and strings creates with a real violin
bowing motion is accurate
MFP I Testing
Not pictured: Inside the neck of the violin were vibration motors that would indicate where the user was meant to place their fingers to play a note. This note would be played so as long as the angular velocity sensor was detecting motion of the roller and the finger was in the correct position along the violin neck.
We tested this iteration of our design with 10 individuals (ideally all or most of these test users would have been representative of our end user but due to department constraints we could only test with certain individuals - one of which was a blind musician thankfully!)
The overwhelming response:
the vibrations are not localized so it’s impossible to judge where to place your fingers, the entire prototype feels like its vibrating
It was back to the drawing board for us…
Given the amount of time remaining, what issues are within scope to tackle for our next iteration?
We need to improve the implementation of the vibrations to test whether it’s a poor idea as a whole or simply implemented poorly (*most important)
Improve the body structure from cardboard to MDF which has been laser cut to exact dimensions
Make bow more accurate to that of reg. violin
Wrapped each vibration motor with an insulation material and fastened them into the holes positioned along the neck of the prototype.
Laser cut MDF board to improve the structural quality of our prototype. We also believed making the switch would have a positive effect on the isolation of vibrations.
Updated bow size - more closely mimics the dimensions of a typical violin bow
Final Design (MFP II)
Feedback from final round of testing:
vibrations were localized and could be distinguished from one another
some inconsistencies with the angular velocity sensor - doesn’t always pick up the roller being rotated causing the vibrations to not change (ie. doesn’t recognize note being played)
users not sure how long to play the note for (no information is given besides which note to play)
how to play louder/softer?
vibrations are isolated so well users can’t determine where to move hand for next note without feeling up and down the violin neck
Some key takeaways from this project are:
Importance of quantitative data. Throughout the process of designing and user testing, little quantitative feedback was gathered. An example of a quantitative metric that should have been implemented is the time it takes for a user to find the next note with their eyes closed using only the vibrations. This data would provide more evidence for how the vibration motors are performing and how well the Angular Violin does at solving defined user needs.
Prioritization is key. Our group got carried away real early with all the features that could be added to this prototype rather than focusing our attention on implementing one or two features really well - as such, we struggled to learn about the quality of our prototype. It wasn’t until our second MFP that we really honed in on the vibrations (the main feature of our design) to ensure that we were implementing it to the best of our ability. By that time the project was in its final week and not much could be done to improve.
Representative user tests. By this I mean having individuals who are representative of your end user test your prototype. Because of the department constraints to individuals who we could test our design with, we only had access to one person who was visually impaired. The vast majority of our tests were conducted with users who were not representative of our end user and therefore we had to make a lot of assumptions throughout the design process - not ideal for obvious reasons…