Part 1: Subject Research
Subject 1: Late-50s Commuter on BART
The Interview
I met this woman while waiting for the BART Pleasanton train. I decided to interview her because I noticed that she was using her smartphone while waiting for the train. The following is a summarized transcription of the conversation:
Q: Where is it that you usually keep your smartphone?
A: Well I usually have it in my purse, but I decided to buy groceries today, so I brought my backpack. It's in there.
Q: Is there a specific task or set of tasks that you do on your phone often?
A: Not really. I guess calling and sending text messages. I also like looking up directions. I'm not very good with directions (laughs).
Q: Could you perhaps think of a time when you wanted immediate access to your phone but didn't?
A: Ummmm. No. It's not usually very far from me.
Q: Okay, well, lets say you had a watch where you could display information from your phone. Is there a specific use that you could think of to having that?
A: (After thinking for a moment) Oh, it'd be nice to have something like that to tell me how far I've gone when I ride my bike. Like an odometer thing.
Q: Could you give me an idea of what this odometer would look like?
A: Just something like my car has. A little number (points to her wrist). I could reset it if I wanted to.
After this, her train begun arriving, so she rushed off in a hurry. I thanked her for her time and told her to have a nice night.
What I learned:
This was my first interview so I was a little hesitant and unsure how to conduct these types of things. After looking back on the interview, I realized I had more opportunity to delve into her biking experience. I'll definitely learn from that for the next one.
The first thing I learned about her was that, like most younger people I interact with, her phone is never far away from her. So much so that she couldn't think of a prior time where she didn't have her phone. This makes me realize that any app for the device must display information that is valuable to have at a moment's notice, i.e., quicker than the time it takes for one to reach into their pocket / purse / backpack. Otherwise, I don't see the justification for even buying a smart watch when all the information I want to receive is acceptable to view on a 3 or 4 second delay. In addition, this leads me to think a watch may also be justifiable when you are doing a repeated task on your phone at irregular intervals. In this case, even if I was okay having a few second delay, perhaps the burden of taking out your phone repeatedly may be enough to justify a watch type interface. For naive example, a person might be engaged in a text conversation with who responds at irregular intervals. They don't want to have the phone out all the time, since it may take the other person a few minutes to reply, or they may respond within a few seconds. This would be a good use case for the watch, since it eliminates all need to consider the fixed cost of taking out a smart phone whenever they receive a message.
I also learned about the possibility of an odometer type app. While this was not a novel response (there are plenty of step counting and fitness wearables that I'm sure also work with bikes), it did shed some light on general use case for smart watch apps: displaying information when visual attention is limited. For example, you can't stare at your smart phone for more than a few seconds while you're on a bike or you'll crash. The same goes for driving, as well as just general walking (everyone hates those people who are always texting and never look where they are walking). I'll keep this in mind while exploring ideas for Part 2.
Subject 2: High-School Music Fan
The Interview
I met this timid young man in line with his Dad for a music concert in Oakland. I chose to interview because of the context and after noticing him pull out and put away his iPhone a couple times over the past half hour or so. I tried to be as friendly as possible, since he seemed a little confused at first. I guess it is odd when the person in front of you in line for a concert tells you they're a researcher at Berkeley and wants to ask you a couple questions. The following is a summarized transcription of the conversation:
Q: Where is it that you usually keep your smartphone?
A: It's always in my pocket.
Q: Could you perhaps think of a time when you wanted immediate access to your phone but didn't?
A: No. It's always in my pocket.
Q: Is there a specific task or set of tasks that you do on your phone often?
A: I check Twitter a lot.
Q: Okay lets say you had a watch where you could display information from your phone. Is there a specific use that you could think of to having that?
A: Oh yeah, I'd love to have that for playing music.
Q: In what way? What exactly would you use it for?
A: To change the song. Or pause it (he taps his wrist as if to pause a song). Oh also it'd be nice to use it as a tuner. I play guitar and it's hard to hold the tuner in one hand and tune the guitar with the other. I usually put it (his smartphone) on my leg while tuning. It's kind of annoying. It falls on the floor all the time.
Q: Could you give me an example of what this tuner would look like?
A: Uh yeah. Just like the note on the screen. I little meter below it to tell you if you're sharp or flat.
At this point I thanked him and his Dad for their time and told them to enjoy the show.
What I learned
I think that this was the most valuable of the two conversations. While his initial responses were somewhat terse and unhelpful, he finally opened up in the end, giving me a pretty good insight that I actually experience a couple times myself, also being a guitar player.
The first idea he mentioned, the music playing app, is clearly not a novel idea. But what did strike me was that he expected it to work with a single touch, as showed by the gesturing motion he made while talking about it. While I'm not sure how other music players already on the market work, it seems that a wrist accessible function like this needs to have a fairly simple interface, perhaps with only one or two buttons per screen. I'll keep this in mind with future designs. Perhaps this turns out to be a pattern.
The next idea, regarding the tuning app, was the most interesting to me. This was especially relevant because I had also been exposed to the same annoyance, I had just never though of the wrist watch as a viable solution for it until he mentioned it. What was also interesting about it was his description of the design. It was simply information viewing interface: the note that was trying to be tuned to, and how far away you were from it. No need for any user touch input. What it did need though, was audio input. This raises the question as to whether all smart watches have a microphone for an application such as this. If they didn't, it would have to rely upon the smart phone's mic, which is far less practical. In a more general sense, this reveals another use case: displaying information on ones wrist while acting upon the source of device input with your hands (i.e. a guitar). Using both of your hands to make some sort of input, then using your watch to get some sort of result based on the input seems like an interesting use case that would be novel to explore. Off the top of my head a few ideas come to mind: music, cooking, and morse code or sign language translation.
Part 2: Prototyping
Brainstorm:
After thinking about my insights from part one for a few days, I then went on to brainstorm a couple ideas for a smart watch application. I really focused on the two main insights I got from my subjects: an app that receives input from both hands and displays some output, and an app that is used for frequent but irregular viewing.
- Trip Odometer
- Music Tuner
- Morse Code Translator
- Guitar Chord Library
- Recipe Reader
- Moving Sheet Music Reader
- Chord Namer
- Driving Habits Analyzer
- Warehouse or Retail Location Finder
- Words Per Minute Typing Tracker)
- Computer Mouse Augmentation or Replacement
- Gym Repetition Counter
Out of all these ideas, I like #7, the chord namer, the most. It combines the use cases of receiving input from your hands, i.e. playing a chord at the piano / guitar / any other two handed instrument, and being something that you may need to check irregularly, i.e. when you play and you perhaps don't know what a particular chord is.
The Prototype:
Now that I had a good idea to chosen, I decided to start on the prototype design. So to reiterate, I'm making a music chord finder. For those of you who aren't familiar with music, a chord is a specific mix of two or more notes. These notes are represented by letters A through G. Each chord has a unique name based on the specific combination of notes that comprise it. For example, the notes A, C, and E comprise what is called an A Minor chord . The problem is, there are thousands of possible combinations, and often times musicians only know a handful of the most basic ones. This is what my app is trying to solve. The concept for my app would be that it would listen to each note individually, then once all the notes of the desired chord were played, it would display the name of the chord. This requires the watch to take some audio input and decipher the frequency in order to discern the name of the note being played.
With regards to design, I tried to keep it as simple as possible. It serves one function and requires no touch input, due to its auditory nature. I wanted each note being played to be confirmed to the user before moving onto the next note, since auditory input can be sometimes unreliable. In addition to this, I wanted users to be able to see the past notes they have played in the chord, for addition confirmation and visual association once you get the result to aid in learning the chords for themselves. This is what led to my design. I put the current note being played in the center of the screen, and the previous notes accumulated in the top left side. Once a long enough time interval has passed to signal the end of the chord, the last letter would flash twice, then display the resulting chord.
User Testing:
Now that I had a prototype, I decided to do some user testing. I arranged to meet my friend Claire, a piano player, before class. I gave her the watch and asked her to imagine playing a chord at the piano that she didn't quite know. As she played the notes of an A Minor chord, I removed the sticky notes from the watch to show the progression of the screens. She commented that she liked the ability to see the previous notes on the top of the screen as she was playing. I noticed though that she was confused as to how long to wait between playing each consecutive note. It was funny trying to coordinate my screen changing with her time expectations for each note. In addition, she mentioned that for especially long chords, the screen space may not be enough. At the end, she gave me a smile and thought it was a cool idea.
Insights:
The main insight I got from this test was that I needed more feedback to the user as to how to use the app. By trying to keep it simple and somewhat elegant, I made the mistake of making the app's purpose a little too ambiguous. She was confused as to how long to wait between playing each note. Perhaps I could add an indicator on the top right hand side of the screen, showing that it's listening for a note to be played. Once it has identified the note, it prompts the user again for the next note, or starts a time to finish the chord and display the result.
In addition to this, her point that large chords might not all fit on the upper portion of the screen. This leads me to another design choice: how do I deal with this case? One solution would be to scroll the top portion of the screen as notes accumulated, but this might make the chord unclear since users lose access to notes. Another possibility would be to shrink the font in order to wrap the text, but this might get difficult to read on such a small display. This choice would require more user testing to discover the best result.
Overall, this was a great exploration in the design process and really forced me to step out of my computer-surrounded comfort zone. Getting feedback from other, non-technical people really helped me broaden my thinking and really get to the core of what I was trying to do.
Comments