Facilitating spontaneity and depth in social networks

Hit Me Up: Facilitating Spontaneity and Depth in Social Networks Dovid Kahn Stanford, United States dkahn293@stanford.edu

Akshay Rampuria Stanford, United States rampuria@stanford.edu

ABSTRACT

Despite the fact that maintenance of deep relationships over time is critical for human wellbeing, few social networking platforms prioritize this need. To explore this issue, we first conducting a Generative Study that encompassed a literature review, competitive review, user interviews, and participatory design sessions. Brainstorming lead us to the idea for an app that connects friends with one another when free time overlaps. After conducting a Usability Study on a paper prototype, we built and deployed the app with extensive instrumentation to 17 users over the span of 11 days. User engagement with the app was minimal due to issues with our design and inherent challenges in this domain. However, our findings suggest that the app idea is appealing in theory to a large number of people and in practice can fit well into a minority of users lives.

Author Keywords

Friendship; networks; close ties; spontaneity; mobile application.

ACM Classification Keywords

H.5.2 [Information interfaces and presentation]: Usercentered design.

H.5.3 [Group and Organization Interfaces]: Synchronous interaction.

INTRODUCTION

Friendships are critical to human happiness and wellbeing.

Unfortunately, friendships are contingent: people change locations, people become overwhelmed with present concerns, and people grow farther apart from their once close friends. Interestingly, apps that focus on getting users to meet new people have multiplied in the recent past while very few apps focus on reconnecting old friends and facilitating deeper connections between those friends. The present paper delineates an attempt to explore this area of the design space: we follow User-Centered Design principles to develop and test a mobile application that tries to satisfy user needs in this domain. We first explored current research around systems that mediate friendships such as social media, ubicomp solutions, and old fashioned media like phone and mail; we also explored social networking apps in this domain. From there, we formulated research questions that guided interviews and participatory design sessions from which we extrapolated overarching themes in an affinity analysis that guided our brainstorm process. From our brainstorm process, we came up with an app called ‘Hit Me Up’ that combines spontaneity and

Joshua Singer Stanford, United States jsinge@stanford.edu

depth of interaction by connecting friends for phone calls during their overlapping free time. We first tested a paper prototype of the app and then built and deployed this app with extensive instrumentation to 17 users over the span of 11 days. Quantitative feedback and qualitative feedback revealed that our app design had critical flaws regarding the model for adding of friends in the app. Despite this, 3 of our users added numerous friends and conducted a few calls during the period. Feedback from those “power users” and the other users revealed that the app is both appealing in theory to a large number of people and in practice can fit well into some users lives.

RELATED WORK

Both the HCI research community and consumer technology industry have focused considerable attention on the question of technology’s role in mediating friendships.

Social media sites such as Facebook are undoubtedly the dominant technology for connecting friends. However, some research suggests that social media as it is currently designed does not optimally encourage true social connection between individuals. For example, Burke, et al considered the way tie strength between two individuals who are “friends” on social media changes depending on mutual levels of engagement with content from the other [1]. In other words, deep engagement with friend’s social media content rather than ignoring or merely “liking”–the prevailing ways people engage with content–produces a greater sense of tie strength. Furthermore, Grieve, et al found that one’s sense of social connectedness derived from online sources differs from the sense of connectedness derived from real life; we maintain distinct “internal gauges” of our connectedness for the online world and real world [2].

Another research domain considers the maintenance of friendships from the perspective of Ubiquitous Computing.

For example, Dey et al found ambient awareness displays to be effective at increasing a sense of connectedness with remote loved ones, while Biemans, et al considered the positive effect of an electronic picture frame that displayed friends’ recent photos in restoring social connectedness for rehabilitation [3, 4]. This line of inquiry suggests that friendships may be positively enhanced through more indirect technological interventions. Finally, in contrast to social media or ubicomp approaches, Shklovski, et al studied the role of more traditional forms of communication in friendship maintenance after residential moves [5]. Their

findings indicate that email exchanges are effective for maintaining long distance friendships while phone calls are effective for actually deepening those relationships [5].

In informing the trajectory of our research, we also considered three lesser known apps currently on the market that apply novel solutions to the question of how to strengthen and maintain friendships. Zenly attempts to augment local friendships by bringing greater awareness to friends’ location and providing a social dimension to this knowledge. PplKpr lets you track your emotional reaction to in-person interactions with friends to help you better choose who prioritize in your life. Finally, Bond allows you to schedule repeated reminders to call friends of your choosing. All of these apps approached the question of technology-mediated friendship from unique angles that inspired our research questions.

MOTIVATION

After considering the existing research and products in the domain of friendship, we distilled our reactions to five research questions that we used to guide our inquiry. Our research questions were as follows: 1. How might we facilitate deeper levels of engagement between individuals on a social network to improve tie strength?

2. Do people wish their social network existence bridged over to their real-world existence more often or are they generally satisfied? How might we help bridge online interaction into the real world?

3. How do people choose who they want to keep in touch with and how often they want to keep in touch? What considerations do they weigh in making such decisions and what tends to win out?

4. Do relationships require active engagement between individuals in order to be maintained or strengthened?

How might we trigger the recall of positive memories to help bolster relationships without actually requiring constant interactions?

5. What is an appropriate level of intervention from technology? At what point does the user think that the relationship is too artificial?

GENERATIVE STUDY

We conducted interviews and participatory design sessions with 5 subjects in order to register how users respond when probed along the lines of these research questions. This process helped us fan out and explore the domain of friendship technology more broadly before narrowing in on one product idea.

Participant Criteria

We sought out participants that had experienced one or more relocations from close friend groups. This included a “military brat,” a current university student on leave of absence (i.e. away from his friends), an international student who took a gap year, and two individuals whose tight-knit high school friend groups dispersed when they transitioned to college.

Interview Guide

We prepared a set of interview questions in order to broadly guide our conversations with our participants. We kept the interviews open-ended and asked numerous follow-up questions. Key questions included: • When was the most recent time you felt a digital interaction with a friend/friends made you feel deeply connected to them?

• Is there a relationship (friendship) that you have really wanted to maintain but have not been able to? What do you think you/they could have done to make your bond stronger?

• Is there a friendship that you’ve successfully maintained despite distance? What do you do to keep this friendship alive? Do you feel like this relationship is just “maintained” or gets deeper over time?

Participatory Design Guide

We conducted a small design session that included a brief brainstorm and prototype. We based the design prompt (e.g.

How Might We…) on salient content from the preceding interview and used pre-formulated questions in order to stimulate ideation. For example, we looked at concrete positive experiences they had and asked how might we make those more frequent, and looked at negative experiences and asked what could have helped.

Generative Study Findings

After conducting the interviews and participatory design sessions we organized our data points with an affinity analysis. Around a dozen interesting themes about digital friendships emerged from this process, but the two major themes that informed our system design were: • Spontaneity: Spontaneity is key to healthy long distance friendships: participants enjoy randomly being contacted by old friends. This sentiment was shared by participants P1, P2, P3, and P4. For example, P4 noted that recently “my friend from high school randomly called me as I was walking back [from class], and it was amazing.” P4 shared that “My friend facetimed in the gym out of the blue. The fact I got to see him made me happy.” All participants also shared that they didn’t like their calls to be routinely scheduled. P2 said “I don't schedule routine check-ins. That's kind of lame” and P4 added “I’ve scheduled routine check ins with people, but they rarely work.”

• Too much effort required: Catching up with old friends often requires significant activation energy to initiate on one's own, so most people tend not to do it often.

However, when a session of catching up occurs, individuals find it to be very rewarding. First many participants (P1, P3, P4, P5) noted that most of the time they feel lazy and don’t want to exert themselves by keeping in touch with their distant friends. Instead, they spend their free time with friends around them that they

are comfortable and “caught up with.” For example P5 shared: “Even though I love my high school friends, I just don’t bother contacting them while at school. I just rely on the fact that we can catch up when we’re home for breaks.” P4 shared that “given time differences scheduling a catch up sesh can be a mess.” Critically, however, P3 shared that “Whenever I think of (catching up), I never actively make a call because I am just put off by how much I will have to talk … but when I get a call, for some reason, it’s always great.” P1 shared this sentiment explaining that they “don’t generally call because of high expectations, but whenever I get a random call, I always talk and always love it.”

the iPhone app. We hosted our backend on Heroku for easy deployment and development.

Clearly, these two themes are intimately related and can be summed up by the fact that many people are hesitant to reach out to their long distant friends; however, when contact is randomly initiated, it is generally a delightful experience for the recipient. We were inspired by these themes to build an app that would remove some of the tension around catching up with old friends by making it a convenient and spontaneous process. The research of Shklovski, et al further inspired us to help friends call one another more, as calls are more conducive to friendship deepening when compared to other forms of digital interaction [5].

SYSTEM DESCRIPTION

We created an iOS application that attempts to connect friends with one another during times they are free to have a phone conversation. Users sync their calendar with our app, indicate earliest and latest times they would like to be contacted in a day, and schedule how many conversations they want to have throughout the week. Users then add friends from their contacts. If two users are both on the app, we use their availability information to determine a time that may be appropriate for a call (i.e. a time when neither have anything scheduled in their calendars that is within the contacting window). When such a time is found, our app notifies one of the individuals asking if they’d like to call one of their friends (the exact friend is kept anonymous). If an added friend doesn’t also have the app, then we simply encourage the user to call that friend when they themselves are free. If the user clicks to call, we initiate a FaceTime audio call between the two friends.

In order to facilitate this interaction on mobile app, we coded up a server using the Python micro-framework, Flask. Apart from managing information about users and their friends, the server finds matches between friends available to talk. To facilitate this, we designed a sleeping thread that awakes, randomly chooses a user, randomly chooses one of their friends, conditions on availability information, and sends a push notification. The backend also manages phone number verification, and calendar integration, and every other piece of communication from

Figure 1. A few screenshots of the app.

USABILITY STUDY

Before building our system, we created a paper prototype of our app and conducted a usability study with 5 local participants. Our key findings and the design changes they inspired were as follows: 1. Confused mental model: all participants had a confused mental model of how our pairing mechanism works. Participants got confused during the process of “Getting matched and receiving a call”. For example, P4 expecting there to be a list of currently available friends that he would contact. P1 thought it was awkward that you could get rejected by someone at this stage and didn’t realize that it was an anonymized process. P3 thought of the prompt asking if you're free as going out to two people rather than thinking of multiple people being asked if they’re free and then making a paring.

Thus, the explanation in the app intro was failing to convey the idea properly.

Design Change: In our final onboarding tour, we include a screen that explained the pairing method more precisely. In particular, it explicitly explains that the app checks with multiple friends who will all be notified of

the possibility of making a call, that the pairing will occur if two are indeed free, and that you can say you're free and still not get connected.

2. Doesn’t use calendar precisely: multiple participants noted that they don’t use the calendar app precisely enough for it to determine their free time. This was noted by P1, P4, and P5 at the point in app setup when they give the calendar permissions. For example, P1 noted that sometimes she puts in events that she doesn’t actually attend and this would be marked as unfree time.

P1 and P4 noted respectively that they don’t really use the calendar at all.

Design Change: We provided users with the option not to authenticate their calendar. When users chose to do this, the app still works and relies solely on the times they entered for earliest and latest contact time. In essence, it treats all the time between those two time bounds as potential free time during which they might get contacted.

3. Setting how often you’d like to be contacted: P2 and P5 both noted during the availability scheduling portion of the app setup that according to this app they would be available to chat often based on their unscheduled time.

They were worried that they would be inundated with calls and wanted more control over how often they get contacted. Additionally, P2 noted that sometimes (e.g. during finals) he would want the app to be in do not disturb mode, while other times (e.g. vacation) he would want the app to connect him with friends more regularly.

Figure 2. Our paper prototype.

Design Change: We provided a setting during setup that allows a user to state how frequently they want to be contacted in the week. They can then tweak this setting later on the same screen where they tweak their availability.

4. Add friends by searching: P2 and P3 both wanted to be able to add friends by searching for them. P2 noted this in the app setup phase (task 2) and P3 noted this during the main screen phase (task 3). They both noted that users have lots of contacts and that searching would allow them to more quickly find the people they would like to actually stay in touch with.

Design Change: we included a search functionality in the add/invite friends view of the app.

FIELD STUDY METHODS

Our main research question was how users would respond to randomly being prompted to call friends. Usually calling a friend is a very intentional act that involves consideration by the subject and a motive for calling. We wondered whether users would get annoyed by–or simply ignore– prompts to call an anonymous friend or if they would engage with it. Furthermore, we wondered whether this would be a begrudging engagement or whether they would enjoy making these calls to their friends. Finally, we wanted to know whether this app would help users grow in closeness to their friends. A secondary question was whether users would find calendar integration useful. We hypothesized that users in different time zones would especially like the feature of finding overlapping available time. Finally, our app is somewhat unique in that there is very little to do on the app itself once it is set up. Rather it acts as a background intermediary between friends by sending push notifications. We wondered whether this model for an app that mostly works in the background is viable in sustaining an active user base.

We were motivated to find groups of people who would want to contact one another more, either old friends trying to keep in touch or new friend groups trying to increase contact with one another. To satisfy the former, we enlisted a group of students that had taken a gap year together before university. This group was motivated to talk to one another but had fallen out of the habit of doing so given their new circumstances. Similarly, we enlisted a tight knit group of international students whose closeness suffered when they transitioned from high school to their various colleges around the world. To satisfy the latter goal, we enlisted members of a fraternity pledge class. We had multiple people from the Phi Kappa Psi pledge class sign up for the app and our aim was to help them keep in touch as part of the bonding experience of pledge.

The study ran from May 22nd to June 1st, 2017, i.e. 11 days. We had 17 real users total who signed up over the course of these 11 days. One user downloaded the app on two devices, so there are 18 “users” in our data analysis section.

We used extensive quantitative and qualitative methods to study users’ interactions with our App. We instrumented out app with Heap Analytics which gave us very rich data about usage patterns and users. Specifically, it tracks every interaction and allows one to define events and funnels after the app is deployed. Heap also helped us understand the demographic break up of our users by tracking the initial location of activation for each user.

• Interviews: we conducted interviews with a segment of the participants after the test period was finished. Before the interview, we noted their number of active sessions and number of calls and adjusted the interview accordingly. In addition to general questions, we asked them to recall app setup and their most recent experiences getting notifications and making calls. We also asked them about specific experiences of frustration or joy.

FIELD STUDY FINDINGS Quantitative Results

Additionally, we provided users with the option of viewing a tour of our app before starting the setup funnel. 17 users started the tour and 58.82% of those users completed the tour and opted to sign up then. One significant drop off here was after users clicked to take the tour (3 users). It’s unclear why this was the case but it’s somewhat likely that a bug may have cause the app to crash at this point. The most significant drop off, however, was when users were prompted to sign up after completing the tour (4 users).

This suggests that some users weren’t immediately compelled by our tour to sign up on the spot.

For our qualitative research methods, we used two techniques: • Experience Sampling: We created a feedback page (Figure 3) that users saw right after making a call through our app. This asked them either to leave a voicemail diary or email feedback about their experience. In the end, however, all users chose to leave written rather than spoken feedback.

Figures 4 and 5. The overall funnels for onboarding.

Figure 3. One of our experience sampling features.

All of our users got through the app setup flow. However, when we look at how many got through the entire flow within one session, the number goes down to a 55.56% completion rate. One of the most significant drop off points (3 users) was at the stage of our app where the user must enter in a verification pin that we sent to their phone via text message. This is a common practice for phone number verification but can take users out of the app and can be confusing for those who haven’t done it before. Alternately, server issues may prevent a user from getting the message immediately, which also causes users to quit trying to set up the app. An equally significant drop off (3 users) was on the

screen where users provide us with their calendar information. To provide us with access to their calendar, users were taken to a safari page where Chronify allowed them to authenticate their calendar of choice. Again, this took users out of our app so the possibility for drop off increased. Additionally, users who failed to successfully authenticate their calendar may have dropped off at this point.

used properly, it can actually achieve its goal of encouraging users to call their friends more.

Scheduling Availability

There were 19 user attempts to give us access to their calendar, but our backend showed only 4 successfully did so. In our interviews, we asked users about this and learned that there was an issue with Stanford’s system integrating with Chronify. Additionally, after clicking to authenticate calendar, many users changed their mind when they realized they didn’t have complete enough calendars for it to matter. In essence, they “clicked” before thinking, a common occurrence when users are rushing through an onboarding process.

Additionally, a UI bug in our app made it so that the default availability window was 0 seconds. Many users didn’t change this by themselves.

Figure 6. The number of friends for different users.

Adding Friends

Unfortunately, the lack of availability was only half of the problem for most users. The majority of users added 1 or 0 friends. However, three users added between 14 and 25 friends. There are two hypotheses we have for what went wrong. Firstly, on the UI level, it’s possible that it was not obvious to users that they should add friends. On a blank screen our UI showed a large plus button that said “tap me” underneath. Originally we planned to make a callout for adding friends but failed to do so because of time constraints when building our app. Secondly, on the mental model level, we didn’t clearly explain to users that they could add friends who didn’t have the app (our second use case). Many users likely felt they could only add friends who they knew also had the app which limited who they added. Indeed, we found this to be the case during our interviews with users. This was an oversight in our onboarding process that also dramatically reduced usage of this critical feature.

One possible explanation for why three “power users” used the app more appropriately was that they were a subset of our participants who were on the Stanford campus. They were able to get more detailed in-person instruction about the purpose and use cases of the app and had the ability to ask questions when they were confused.

Calls

In total there were 7 calls placed across the 11 days. All of these calls were placed by the power users; two placed two calls while the other placed 3. As noted in the above sections, the other participants had little to no friends and/or had no available time marked. This inherently limited the number of calls they could possibly make. However, the “power user” data suggests that if the app is understood and

Figure 7. Unique users who attempted to authenticate their calendar.

Qualitative Responses

In addition to collecting the experience sampling, we interviewed both power users and the regular users. Over the course of collection of qualitative data, we found the following overall themes: 1.

2.

3.

4.

5.

Randomness in Calls Out of the box usage Calendar Usage patterns Confusion about friends Idea is divisive

Randomness in Calls

Figure 8. The number of unique users over the study that opened the notification to call someone on a given day.

We consistently heard from our power users about the delight/troubles of randomness when communicating with friends. Positively, users seemed to enjoy the push notifications when they arrived, even if they didn’t open them.

“I always liked the reminder to call someone. Because I spend a lot of time talking to people who aren't at Stanford, it was just a good reminder that there are people I can talk to.”

“Yah I didn't always use it, but I ended up using it a couple times throughout the week to fully make the call. And I enjoyed all of that.”

However, users didn’t always enjoy the randomness of the call prompts when deciding to make a call. If the friend that was randomly selected for the user to call was not on the app, then the prompt for the user was simply “Call a friend.” If the friend that was selected was on the app, then it would say their name and say that they indicated they were free for call.

Figure 9. The number of sessions that took place as a result of a user opening up the notification for a call.

Figure 10. The graph displays the unique number of users who were active on our app per day. As expected, the number of unique daily users drops off after most users set up the app in the first couple of days. Only those users who configured their availability window and added numerous friends returned to the app when prompted by the notification.

Figure 11. Example of a prompt after opening a notification where the scheduled friend is also on the app.

Out of the Box Usage

Another piece of feedback regarded the app’s out of the box experience. By “out of the box”, we are referring to what the experience is like immediately after a person onboards.

In our ideal case, a user just adds friends and waits for a notification, but we learned that our app should engage users immediately.

From one of our interviews we heard: When it said do this to communicate with their friends, after I added them, I couldn't tap them to contact them. It wouldn't let you go in depth a level with your friends.

From other feedback, we heard: “Rethink the "day 1 experience". Right now, my motivation is high. I actually downloaded your app and went through the whole set up. But at the end of the set-up is nothing.

There's no other action or way for me to experience any real value from the app before I close it for the first time.

You're literally providing 0 value on day 1, which you don't want to do… Maybe after set-up you tell users to call a friend right then, or text a friend they haven't talked to in a while. Even doing something as simple as getting them to send a text to a friend they haven't talked to in a while is better than just telling them to leave after set-up.”

It was obvious that we needed some way to provide value to the user after friends were added. Whether that be a notification, or just a way to call them from the app, some feature should be added at that stage.

Calendar usage patterns

One of the most important things we learned from our qualitative data was that many people just don’t use an online calendar, and if they do use one, it isn’t always reflective of their actual schedule.

After I signed up I was like “what does this app do?”

Thus, these users’ mental models about the app were off.

They didn’t understand that they had to add friends after they onboarded, obviously a fault of our onboarding process itself.

Another issue arose from the fact that many of our users were international students who have friends in their contacts with multiple numbers. In our original design for the view where a user adds friends, we displayed contact name alone, so they were unable to see which number they were associating with the friend. Thus, they abandoned the app setup at this point and most never returned.

We found that at least some of the users that only added one friend didn’t understand that the app would work if they added friends from their contact that didn’t have the app.

When asked why they only added one friend, one user explained their reasoning and was surprised to hear that the app has functionality even for friends without the app.

Other users added just one friend to “test out” the app.

Unfortunately, the app doesn’t work well if you only have one friend listed so they never felt sufficiently compelled to add other friends I added my friend to test how the app worked but then got distracted because of finals. Sorry about that!

Finally, some users simply didn’t want to add more than one person to this app.

The only person I actually added to the app after going through my entire contact list was my girlfriend. Literally no one else in my contact list would I want this app to set up a call with. And obviously, I don't need this app to set up calls with my girlfriend.

There is a discrepancy between times that aren't filled on my calendar and when I would actually want to talk. There will be times when you're off work, and you could call your parents, but you're tired and would wait until the following morning. It could be kind of awkward situation if one person really doesn't want to talk.

This all suggests that we need to redesign the friend adding process of our app to include a more lucid explanation of how the app works. It also suggests that the idea of the app is simply unappealing to some people, a topic we will discuss next.

We also learned that for one of our user groups the Calendar API, Chronify, would not work because all of the Stanford Accounts switched to a new account system that wasn’t supported.

We found that some users really liked the idea of the app and others did not. This came down to a couple factors. The idea is appealing if one generally tries to keep in touch with friends one is not very close with. However, some people feel they do not need to be in contact with people they are not already naturally reaching out to. For example, one user said:

This was unexpected, but incredibly revealing. Fortunately, feedback from our usability study encouraged us to allow the user to skip calendar integration and simply provide their start and end times per day.

Confusion About Adding Friends

One of the key issues with our field study was the fact that many people didn’t add friends or added only one friend.

We attempted to investigate this further in our interviews with those users. On the issue of adding no friends, some users did not understand that they actually had to add friends.

Idea is divisive

For me, I get no value as there is just no one that I don't already regularly talk to that I would want to use this app to talk to more.

While on the other hand, another user explained that since they live abroad and try to communicate across time zones, the app in theory would be extremely useful if it scheduled that for them:

I try to keep in contact with a lot of people in the states but it’s tough because of the time difference. Having that all done for me would be really useful. Unfortunately, I never got contacted by the app.

DISCUSSION

Overall the data suggests that the app can be useful for some people. For those who set up the app correctly and are sufficiently invested, the app encourages them to call their friends more often throughout the week. We saw this in our data, specifically with the power-users from the pledge class user group.

For many who didn’t set up the app correctly, the idea of the app was still appealing. Despite the various UI changes that we could implement to increase usage, our raw user data and feedback suggests that this app appeals very strongly to a small percentage of people who are motivated enough to integrate the app into their daily life. A larger percentage of people would find the app useful “in theory” but would not go through the effort to really use the app, i.e. any hindrance or confusion would simply derail them from using the app fully.

Finally, a last large segment of the population would not find our app useful. They either don’t like phone calls or feel sufficiently connected to their friends through other apps. Pew Research indicates that 31% of Americans preferred texts to talking on the phone, while 53% said they preferred a voice call to a text message [6]. We may extrapolate from this study that our app is at minimum unappealing to around a third of possible users and at most appealing in theory to half of possible users.

IMPLICATIONS Design Implications Design updates during deployment

One of the first things that we did to improve the design of the app was changing the default times in onboarding. As noted, due to a UI bug default times were the same for “never contact me before” or “never contact me after”. We didn’t anticipate that people would either be satisfied with the pre-set times or rush through the onboarding without adjusting the pre-set times. Soon after app deployment, we observed that that no one was opening notifications and realized we needed to change the default notification window. This idea is important for apps with long onboarding processes. For example, many apps in the social space like Snapchat will force a user to adjust a relevant date picker before allowing them to advance.

Figure 12. The changed defaults for the availability view.

Figure 13. Snapchat does not let you continue until you change the date.

Another thing that we implemented was an updated Table View for the Add Friends screen. As noted above, we got feedback from our international users that they were hesitant to add friends. We learned that many international users keep multiple numbers for their contacts. Thus, international users would be hesitant to initiate a call with one of the randomly selected numbers, and just decided not to add friends in the first place. We decided to build a new table view that shows numbers in the detail text, and allow people to have multiple contacts with the same name. This feature is especially important to apps in the social space that allow interoperability with those that aren’t on the app and use phone numbers as key point of contact. For example, Down To Lunch, a popular social app does this as well: the app segments different numbers into different contacts, so you can send multiple invites to the right numbers and avoid overages.

long-term “background” benefits, should provide some sort of out of the box experience to the user. All but the most motivated users will likely not use the app if there is no initial experience other than just setting up the app.

Additionally, we learned that when one designs a system in the friendship domain one must fully consider the experience of international users, as communication across borders is a key use case. Such investments in development are laborious but they are necessary to provide a realistic user experience that can be accurately tested.

Figure 14. The changed table view to support international users.

Additionally, we drew a methodological implication from our work. While testing a paper prototype of the system before development may help identify interaction blockages that you can fix, a second stage of user testing after the app is built is critical to ensuring that the final product is fully understood by users when it gets deployed. In the realworld, discrepancies between a paper prototypes and what is most expedient to build can result in unforeseen usability issues, such as our default time UI bug. Clearly, doing a second round of usability tests before deploying for our study would have greatly impacted our results.

ACKNOWLEDGMENTS

We would like to thank the participants in our generative study, usability study, and field study for participating in this project. We would also like to thank Frank Bently and Ash Ngu, the CS377U teaching staff, for their invaluable guidance throughout the entire process.

REFERENCES Figure 15. Down To Lunch invite screen.

1.

Burke, Moira, and Robert E. Kraut. "Growing closer on facebook: changes in tie strength through social network site use." Proceedings of the 32nd annual ACM conference on Human factors in computing systems. ACM, 2014.

2.

Grieve, Rachel, et al. "Face-to-face or Facebook: Can social connectedness be derived online?." Computers in Human Behavior 29.3 (2013): 604-609.

3.

Dey, Anind K., and Ed de Guzman. "From awareness to connectedness: the design and deployment of presence displays." Proceedings of the SIGCHI conference on human factors in computing systems.

ACM, 2006.

4.

Margit Biemans, Betsy van Dijk, Pavan Dadlani, and Aart van Halteren. 2009. Let's stay in touch: sharing photos for restoring social connectedness between rehabilitants, friends and family. In Proceedings of the 11th international ACM SIGACCESS conference on Computers and accessibility (Assets '09).

5.

Irina Shklovski, Robert Kraut, and Jonathon Cummings. 2008. Keeping in touch by technology: maintaining friendships after a residential move. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '08).

6.

Smith, Aaron. "Americans and text messaging."

Washington, DC: Pew Research Center (2011)

Future design changes

The major design changes we wish to implement in the future surround the issue of adding friends. We realized that our onboarding stopped before adding friends. (Initially we had wanted to include a callout explaining that users needed to add friends, but didn’t do so because of time constraints on development.) In a future iteration of the app we would want to have a more guided process for adding friends that explains clearly why users need to add friends, what adding friends means, and what to expect after they add friends.

After this study, it is now apparent that with the surplus of social apps, direction must be given as to what roles “friends” play in our particular social app.

Finally, as noted earlier, some users didn’t like the fact that the person they were going to contact is not listed before they actually initiate the call. This is a feature we would either like to AB test or for which we would give users an option.

General Implications

Our app was designed to provide long-term benefits to a user by executing background processes and notifying the users periodically. One of the key findings from our field study was that all apps, even ones that seek to provide such