To get a feel for the potential smartwatch user base, I interviewed a 12-year-old Latina girl who was at Berkeley for a summer sports camp, and a 33-year-old white male who is the Facilities Manager at my Co-Op.
The adolescent stated that she used her smartphone (acquired three months ago) not for social media or games, but to learn and enrich her knowledge. Particularly, she was a frequent user of Duolingo.
The Facilities Manager, whose job is to manage the finances, oversee the maintenance, and communicate with the central board of a 140-person house, had a more typical use for his smartphone, which he acquired 3 years ago. For his work-only phone, he answered texts/emails, and particularly used Google Sheets a lot. For example, he conducted weekly inspections to see if members have cleaned their bathrooms: instead of writing down the people who didn’t clean them on a piece of paper and then transferring it to a spreadsheet, he used his phone to enter the information directly.
Both users keep their phone in close proximity: either in their pockets or backpack. While the Facilities Manager stated he could not recall a time he didn’t have his phone but wanted it, the young girl said sometimes she wanted to take videos, but her phone didn’t have enough battery life to last an entire day.
Both users could not envision Duolingo or Google Sheets on a watch form factor, however, and complained about the small screen size. In fact, the Facilities Manager chose a Samsung Note mainly for its large screen size. He also mentioned that he was going on vacation to Canada soon, and would find a smartwatch helpful if it vibrated and provided facts about famous landmarks he was near. Both users expressed that their phones were more than sufficient for their current needs, and could not see themselves buying a smartwatch.
I then brainstormed some smartwatch app ideas.
- Pokemon/taking care of catching game: watch face is Pokeball, interactions similar to Tamagotchi, maybe integrate pedometer features (bringing back the HG/SS PokeWalker)
- Passive acoustic receiver: just an ambient display of how much noise is occurring around you
- Menstruation tracker, especially for older less tech saavy people: simple tap interface
- Vibrating alarm clock, obviously (like Fitbit)
- As per Facilities Manager’s suggestion, GPS enabled important landmark notifier/fact provider: perhaps interactive, w/ other user tips (Hybrid Snapchat-Yelp like social app?)
- App that helps cashiers auto-record finances through voice customer interaction (“that’ll be $4.75”), eliminating cash register needs
- Game app for virtual pet sites (like FlightRising) that lets you do daily interactions: feed dragons, hatch eggs, gather items
- Social media app like the website thisismyjam, but use audio detection algorithms to auto-log your jams
- Toilet app which provides short daily entertaining content (easy puzzles/sudokus, video of the day, etc)
- Concert fan information app which shows local venues/artists’ setlists/imports social media feeds (like Instagram tags) after the concert
- Work hour log/CalTime replacement app (just a touch to clock in/out, auto-notifies you at the end of pay period for approval)
- Ski companion: shows current velocity, location on trail, weather, iciness of snow, reminds you to drink more water
I decided to do a low-fi prototype on number 7 because as a FlightRising/general virtual pet fan, sometimes when I remember to do my "dailies" I am not nearby a computer. While I have my phone on me, trying to navigate the website's rich web interface is a pain and requires a lot of zooming. Were I to use a smartwatch, I would always have this app (literally) in hand, and could do my daily interactions at any time.
I made the watch from tape and prototyped 9 panels using post-it notes showing how you could feed your dragons, and go fishing if you didn't have enough food. I also predicted a user might want to click on a dragon for more info, so I made an extra watch screen for that.
I user tested on two of my co-op mates: Jordan, who was familiar with virtual pet sites, and Matthew, who wasn't. My biggest concern was the lack of signifiers showing swiping ability: I stayed silent throughout the user evaluation, only replacing watch screens, and hoped the app would intuitively show that swiping up meant going back, etc. I designed the initial error of not having enough fish so users would be forced to go back to the main screen to "gather items".
Insights from the user tests:
- Jordan got immediately immersed into the world and forgot about the goal of feeding her dragons; she explored and gathered items first so she didn't even come across the error I planned.
- She intuitively understood that swiping up meant going back, as I had hoped.
- She wanted to click on the items caught when fishing for a description, something which had not even occurred to me to implement, as I myself never even click on them while using the official web interface.
- On the Dragon Lair screen, Matthew was not sure if Michel, the first dragon was selected or if it was a home screen for all the dragons. This was because I had page 1 selected out of 3, and he wasn't sure if this meant dragon 1 out of 3, or page of dragon. He assumed only Michel was at 72% hunger, instead of the whole liar. He also wanted to swipe left and right to scroll through the dragons in the liar.
- Matthew had a lot of trouble figuring out how to exit both the error message (he eventually clicked on it) and the Dragon Lair screen. I had to tell him you were supposed to swipe up: he assumed you could only swipe horizontally, due to the carousel layout of the dragons themselves.
Were I to do a next iteration of this app and this quest, I would create more screens for wanted activities, such as fish descriptions, and probably redesign the Dragon Lair screen to avoid scrolling vs. swiping vs. clicking interaction confusion.