The purpose of the study is to observe how people manage their communication using a novel prototype (PocketLove). This study may involve comparisons with how users manage communication using other communication apps. These observations will directly lead to further development and study of the PocketLove prototype.
II. Procedures
Participants will be interviewed for approximately 1/2 hours. Questions about how they manage communication and share information with others will be asked. An audio recording may be made for the duration of the interview. At times, participants will be asked to show how certain tasks are done on their devices. Screenshots of the device may be taken during this time.
III. Extent of Anonymity and Confidentiality
The researchers will not collect personal information beyond name and basic demographics. Subjects are free not to answer any questions or respond to experimental situations that they choose without penalty.
At times, information associated with the participant may be displayed on their device and may be captured when the researchers take a photo. Every effort will be made to allow the subject to avoid displaying private information. The participant is free to hide any personal information on the device or request that the screenshot not be taken.
Collected information will be stored and maintained by the researchers listed above. The information will not be distributed to anyone who is not involved in the research. Anonymized quotes or clips may be used in presenting the project in class. Should the researchers decide to release the information more publicly, the information will be anonymized and consent will be obtained from the participant.
IV. Compensation The participant will be provided with a cupcake for their participation!
Fix UI Bugs - We fixed several usability issues that we found during user testing. Many were quick fixes and low-hanging fruit that would greatly improve the UI.
Added temperature and location labels to indicate that the weather and time is real-time and based on the user’s location
Made clicking the avatar open up the “Update Avatar” options because users’ initial instinct was to click on the avatar
Added game titles to the game menu to make it more clear how to start a game
Make the “Update Avatar” menu have the girl avatar if the user is female to make menu more clear and intuitive
Gifting - This was an all-new feature that we brainstormed after user testing. We found over and over again that users wanted more interaction with the avatar (“I want to make it do something!”) and more ways customize the avatar. Gifting allows users to send random gifts to their partner which are displayed on their partner’s avatar. We believe this feature is aligned with the “playful” nature of the app that users enjoyed most during testing.
Back-end integration - A main task this week was to hook up firebase to all of our different features so we could push avatar, status, and gifting updates immediately between two different phones.
Hugs Vibrate - Users were delighted by the very basic hug feature during testing (just the avatar updating) so we wanted to add a tactile aspect as well.
Poke - Users can now poke their partner's avatar. We wanted to make clicking either avatar do something since clicking on the avatar was most users' first instinct when opening the application.
Unfinished To-Do's:
Make Flappy Bird Multiplayer - Users enjoyed the single-player games that we tested last week but they were very excited for the collaborative aspect. Initially, games were just a side feature, but from the very positive feedback, we decided we wanted to make it a core feature and have it be multiplayer. We weren't able to finish it this week but we are hoping to have it ready for the final presentation!
On-boarding Tutorial - This was initially on our task list for this week since users were confused about the meanings of some icons. However, after completing several UI tweaks, we hope the interface is more clear and discoverable on its own. We will be sure test this in the next user study and decide afterwards if a first-time user tutorial is still needed.
During this phase of user testing, we would like to distill a clearer story about how our application fits into users’ lives. We want to observe usage patterns to see if this app is better suited for quick “glimpse” interactions or longer periods of interaction. We also want to more clearly define the first demographic of users that Pocket Love is designed for.
H1. This app is better suited for long distance couples (versus family members) because the couples’ desire to communicate would be on the same level. (Whereas family members would be more one sided, as we found from first round of user testing.)
We would like to determine how much direct communication we should support in-app vs. outsource to other already popular applications. For instance, some earlier users mentioned they would like in-app messaging whereas others said they had no need for another messaging app.
H2. Users see Pocket Love as a whimsical way to check their loved one’s status and not necessarily as a means to facilitate direct and prolonged communication.
After user testing, we will encourage the users to keep the application installed and monitor their usage. We wanted to see if people still use Pocket Love voluntarily after initial testing.
As per Graham’s suggestion, we also thought deeper about the actual communication and notifications between the app and the user. As a result, we implemented more refined ways to notify both parties of gaming, status, and hug updates and we want to test these new mechanics.
Methods
To recruit our users, we first had to narrow down our user group. We decided to focus on long-distance relationships instead of family communication. We want to make sure that we first get it right for couples and then expand from there.
For our user testers, we first asked Kevin, our mentor, who is in a long-distance relationship to be one of our users so we could get very technical feedback. We also asked two of our friends at Stanford who are in long-distance relationships because we thought we would get interesting insights since we personally understand the nature and context of their relationships. Third, we used SUPost to recruit users in long-distance relationships throughout the Stanford community. We wanted to make sure our users were avid smartphone users and we knew most members of the Stanford community would fit that bill. Finally, we plan to approach couples for testing around campus so we can have both members testing at once.
For individual users, we will present them with specifics tasks as we did in class on Thursday. First, we will ask them to find their avatar and update their current status. After they have done so, we will ask them what they think each of the features represents (weather, time, mood, activity, and call availability) to test if these signals are clear. Second, we will ask them to navigate to the avatar of their significant other (pre-programed to look sad) and ask the user to try and cheer up their partner by engaging with them through the app. Here, we hope to test the mechanics of our “hug” and gaming features. During this phase, we also want to determine if the menu icon meanings are clear. Afterwards, we will ask some follow-up questions and finally ask them if they would like to download the app. If they do, we will track their usage in our database.
For couples testing the app, we will have them sit apart and one of our team members will be with each person. We will run them through a script of an average day with prompts to update their status and engage with each other through the app. Something along the lines of…
Prompt for #1: “You just woke up and it’s a beautiful morning. And your partner asks you how you are doing.”
Prompt for #2: “You just arrived at work and your boss is cranky and yells at you for being late. You also get a notification from your partner’s status update.”
Prompt for #1: “Your partner is having a bad day. Cheer him/her up.”
Prompt for #2: “Reciprocate.”
After this role-play, we will bring the couple back together and ask them a few follow-up questions about their experience of using the app. We will also ask what apps they currently use to stay connected or other means they use to communicate. Finally, we will ask them if they would like to download the app and if they do, we will track their usage in our database.
As a design decision, we parallel prototyped and made as many features for the app as we could possibly come up with. Then we left it to our testers to try a few at a time in a in-between studies approach, and show us which communication mediums were most poignant for them. As a result, we made the following design changes and implementation decisions:
Features we REMOVED for the moment include:
Relationship health bar: made users feel guilty, hard to quantify a relationship. made users feel like health app
In phone calling: this was silly to implement it ourselves when existing apps are easier; we also realized that users simply didn't want to call/message from within our app because it gave a different, more whimsical feel. A Facetime feature would have detracted from the whimsicality
Current activity: we made it more vague, since exact details made users feel uneasy, as if they were stalking the other person
Features we KEPT/ADDED due to user demand/insights:
Mini Game - We want to allow multiple players to simultaneously control the game, like the Pokemon Twitch tournament! The rationale behind this originates from Burke's Growing Closer on Facebook: Changes in Tie Strength Through Site Use. This was a study that found people who played casual multiplayer games, like Words with Friends, were more likely to feel closer to their friends than those who didn't. We want to use real time gaming as a communication medium, or communication spark, to get people to grow closer together.
This gaming feature also enhances the tamagotchi feel of the app and keep the app light-hearted and fun. We also found in testing that users wanted more ways to interact with their avatars so we used their avatars inside the game.
Multiple Avatars - Users routinely mentioned loved ones that the app reminded them of during testing, so we realized that our simple interface lends itself to multiple pocket pals! Within a simple swipe, users can check up on the status/mood and interact with many loved ones. This realization will also keep them engaged with the app for longer periods of time! The wireframe in Figure 1 entails how users may create/manage multiple avatars:
Figure 1: Users may create and manage multiple avatars
Figure 2: User may toggle between various loved ones easily
As the above wireframes demonstrate, users has access to the other party's:
Time - Time is something that everyone keeps track of and it is an integral part of understanding a loved one’s context. We wanted to make sure time was always displayed so users would no longer have to mentally calculate time differences.
Weather - Knowing your loved one’s weather helps to bridge the distance by giving you an understanding of their environment. We found that users had often already programed their loved one’s location into their local weather app so we wanted to make sure to include this feature in our app as well.
Mood - This is a key component of our app that allows users to update their avatar with their mood. In testing, we found that this was a fun way to personalize their avatar but also a quick way to convey emotion.
Users also wanted simple ways to create and update their own avatars:
Figure 3: A simple onboarding process
Figure 4: a simple status update process
As seen in Figure 5 below, user can also toggle the following:
Call Availability - A problem most users ran into in long-distance relationships is finding time to talk. Often times, calls have to be scheduled, especially in international situations. This feature allows users to quickly see when their loved ones are available for a call so it reduces the barrier in communicating and always users to stay better connected.
Work Status - In testing, we found that tracking a loved one’s exact location was a little “creepy” so we are testing out this “at work” status instead. We still wanted to somehow include location in our app since we believe it is important to understanding a person’s setting. Our compromise is allowing users the ability to say whether or not they are at work and having this setting visually displayed on their avatar.
Figure 5: User may quickly choose their current availability, mood, etc.
Figure 6: This is then instantly reflected in the other party's views
Implementation progress thus far
(all images below are screenshots of a fully functioning iOS app)
Users can update his/her own mood, call availability, work status. The time and weather updates are automated by location!
As seen above, user also toggled the following:
The Mini-Game -We also implemented and customized two games.
Both games are accessible via a game menu
Users can now use their avatars to play FlappyBirds, for example (see below). This further personifies our avatar analogy.
Think how much more challenging this game becomes once two people can make the avatar crash!
We also integrated the popular game 2048. This will be turn based and offer users a more intellectual environment to collaborate.
More character management, e.g. animation, outfits, avatar customization to look closer to user's intended.
Character interaction, e.g. kisses, hugs request/reciprocation
Server side and backend implementation
Realtime weather updates
Double playing mode for game, where two people can control the same game, like in pokemon twitch
Food delivery feature, that integrates or routes to Seamless.com
We really enjoyed working on both these prototypes and received valuable feedback on both ideas. Before this milestone, we were pretty set on the Tamagotchi idea because it presented a lot of unique design challenges and seemed the most fun to build. However, after fully thinking through and testing our Story idea, we really came to like the emotional draw of this application and were surprised and happy to find that the purpose resonated with our user testers as well.
Both ideas clearly have kinks that need to be worked out but we’re excited about the prospect of working on either one. On the one hand, the Tamagotchi idea will require careful UI design to make sure the app isn’t clunky and actually succeeds in improving long-distance communication. On the other hand, the Story idea requires a beautiful user experience that will depend a lot more on decisions about content and the execution of each feature.
kaledo-art
janainaart
snowghoul
germansingergirl
jbbartram-illu