INTRODUCTION
This week's assignment was on non-visual prototyping. Our goal was to build sound prototypes for non-visual feedback of fitness tracking application that we built previously. We needed to include start/stop tracking, go faster, go slower, sip water, and exercise complete functions as assignment requirement.
AUDIO PROTOTYPING
For making sounds, I used the tools around me at my apartment. Basically water, water glass, wine glass, knife, Sharpies. Then, I used Adobe Audition for editing. At first, I was planning to use Audacity for it's simple and easy-to-use interface, however it did not work with my audio files. So, I needed to watch some videos and use Audition.
Below is the sound prototypes and their descriptions:
Sip some water​​​​​​​
For water notification, I used two glasses and poured water from one to another. The main reason behind my decision was basically water has its sound and I thought I could use this sound for reminding drinking water to the users.
Start tracking
Pause / Stop tracking
Complete exercise (Goal achieved)
For Start Tracking, I used empty wine glass and a knife to touch the glass. Since empty glass gave a higher sound, I think it fits with the purpose. As the beginning of the exercise needs a higher tone of activation, I decided to go with a higher more activating tone. In contrary, for Complete Exercise (Goal Achieved) response, I decided to go with a deeper sound than the Start Tracking sound. Although both of them made by the same tools, for Complete Exercise sound I added some water into glass to have rich and deep sound. Lastly, for Pause/Stop Tracking, I used Sharpies and made a sound. I wanted a short but clear sound for this feature as the user needs to understand the tracking has been cut. So, I looked for some cut effect in sounds.
Go faster
Go slower
Going faster and slower responses are also made by 2 Sharpies. I tried to imitate the pace. Accordingly for one of them I increased the pace of the rhythm, and for the other one I decreased the rhythm. So that user would understand he/she needs to go faster or slower. 
TESTING
For testing, again I conducted a remote test with my friend. I added audio files to this page (without any title or explanation, only sound files) and published the website before the test. My initial plan was giving the website url to the user, so that the control will be on him and he will be able to play the sounds. However when he opened the website the files were not visible, so I needed to play the sounds during the test. 
Before starting the test, I provided a brief explanation about the previous week's assignment to the user by showing the paper prototypes I made. The main reason behind this was since he did not test my paper prototypes, he needed to know the context. Then I started playing audio files one by one and asked him to tell which function's response/notification sound can it be. 
Below is the test feedback I received:
Sip some water: He directly said that this sound is related to water notification.
Complete exercise: He told that this can be end of exercise or start of exercise. 
(Then I played start tracking as both of them were similar)
Start tracking: He mentioned that this is almost same with previous one, accordingly it can be start tracking or end of an exercise. 
Pause/Stop tracking: He couldn't think of anything for this sound. When I told what is it for he mentioned that it might be better to have a similar sound to IPhone's sound notification when AirPods battery is low for this purpose. 
Go faster&slower: He mentioned that some parts of these sounds cannot be heard well but couldn't make any guesses or differentiate one from another. 
REFLECTION ON PROTOTYPES
After the test, I realized that among all 7 sounds I built, only water sound was clear for my user to understand. For start tracking and complete workout sounds, they are okay but I needed to work more to make the difference more noticeable. For instance instead of one touch on the glass, I can do several touches on the wine glasses with different water level to have a more clear melody that says the workout is done. For pause/stop tracking as the user suggested I can have a softer sound because with this response, the application does not ask user to do something or notify him, only giving feedback that it received user's request on pausing or stopping the tracking. Lastly, for go faster and slower sounds, I need to work more on them to be able to build sounds that are distinguishable and easy to understand by the user. With these two sounds, the application is not giving feedback to the user. Instead, it tells the user to do something different. Accordingly, I can try to build this sound with glass or cutlery so that it will be a higher sound than the Sharpies.
REFLECTION ON SOUND PROTOTYPING
With this trial, I had the chance to build and edit sound for the first time in my life. When watching the lectures on sound prototyping, I was a bit confused on how to build sound notifications as I don't have any experience. However, once I started to do, I actually enjoyed it. This experience also gave me chance to think about the importance of non-visual feedback the users receive when they interact with visual interfaces. Sound feedback or response needs to be in line with the action or visual interface, so that the user would not be confused while using the product. ​​​​​​
Back to Top