CS247: Human-Computer Interaction Design Studio
We have two primary goals for this first round of user studies. The first is to understand how intuitive our interface is -- whether or not users can interact well with our interface, and whether the design and flow of our application is easy to use. Our second goal is to gain a deeper insight into the situations in which users will find our application useful. Our initial stated “use case” for the app was for friends to help find one another at a prescheduled event or meeting, but we believe that the functionality of the app can facilitate the communication for coordination of various different types of events.
We will go into depth about each of our two stated goals below.
Q1: Can users easily find the core functionality features (camera screen, adding friends/events) in the app without further explanation?
Hypothesis 1: We believe that it may be useful to include a brief walkthrough tutorial the first time the app is opened, to familiarize users with how to make use of the different communication features (camera, map, chat window, etc)
Q2: Are users able to switch fluidly between the multiple communication interfaces? Specifically, will people have issues navigating the interface switch among photo magnifications, map, and chat screens?
Hypothesis 2: We suspect that there currently may be some overlap between the communication interfaces our app provides. Photo shots appear in the chat window as well as in the map, and users may be unsure whether to use a text chat or photo chat. We’d like to get user feedback about what features they find most salient in each communication medium, and focus on doing those features well for each medium, so that we can create an application with a breadth of rich communication options that is easy to access.
Q3: What features define our application, and are there any that are superfluous?
Hypothesis 3: We would like to create an application that does one thing (enabling users to find their friends) well, rather than attempt to dip our toes into every feature. Thus, we are curious to find out what users think is the most useful part of our application. We hypothesize that the answer to this will be the map showing real-time location of friends, combined with pinned photo data on the map.
Q4: Will users only open the application to find each other during scheduled meetings at new locations?
Hypothesis 4: Although this was our initial use case, our new hypothesis going into our user studies is that users will also use the app for more casual meetups that they have not previously scheduled into their calendars. For example, Charles may have verbally agreed upon meeting up at the Embarcadero Train Station with Angela, but he may still have incentive to open the application and create his own event on the spot upon arrival to help him communicate with and find Angela even if this were not formally scheduled into his calendar.
Q5: Are users willing (and likely to) interact with the app prior to the event? Is it too much overhead to ask users to remember to create a new event several hours or days prior?
Hypothesis 5: We hypothesize that people will not mind creating a new event on the app in order to use it. Many applications, such as Facebook events, are not synched with users’ calendars, specifically for the reason that a user may want to be selective about which events show up in which application. If this is not the case, then we will have additional incentive to incorporate synching with Google/Apple Calendars to better facilitate this particular use case. Otherwise, it may be frustrating for users to have events they don’t want to use the app for (e.g. meeting a friend at a very specific location, like the Claw) cluttering up the Events screen.
For this user study, we recruited users from amongst our friends and classmates. We feel that this is a representative user base for our application, as college students often have meetings in new or unfamiliar places (visiting teammates in other dorms or buildings, going to large festivals and events, meeting with friends at train stations or restaurants, etc). Since our tester base comes from our friends, we simply sent emails and texts to ask them to participate in this study. We also agreed to test the prototypes of other teams in addition for their assistance. Because our goals in this study revolve around how users interact with our app, we chose tasks that would specifically allow us to observe users in action. We will be having our users participate in these tasks in pairs.
Task 1: We will place User A and User B in different parts of a building (such as Huang). We will have the two users join the same event on our app, and attempt to find each other using the map and the rich media options. One of us will be observing each of the users during this process. We will record the sequence of actions that each user takes, whether or not there are any roadblocks that are presented (either with app functionality or interface), and how long the entire process takes. We will also run a control experiment to observe how people find one another without the app, and compare the two processes.
Task 2: We will ask our testers to go through the process of creating an event in the app and inviting friends to the event. After users have completed this action, we will talk to them about their experience. Specifically, we want to find out about the overhead of event creation, and question users about whether or not they would actually go through this process with their real-life events. As part of our data collection for this part of the experiment, we will prepare a set of survey questions for each user to answer. The answers to these questions will help us understand the potential use cases our testers see for our app. From initial pilot testing with another group, we have found so far that testers are, in theory, amenable to in-app event creation. One tester stated that it was no different from how many other event-driven apps like Facebook events require separate event creation, but this may just be because people are often more agreeable to the idea of doing additional work while using a prototype than they would be in real life.
Task 3: We will give the application to a group of friends who are close to one another or teammates from a group and ask them to attempt using it for their meetups over the next several days (we think an ideal opportunity will be during the Stanford Spring Faire event on Thursday evening). This will be a chance for us to test our app in the wild and see whether or not the app actually is beneficial enough to warrant long-term continued usage. We would also like to use this opportunity to track any functionality or interface annoyances in our current app, and so we will ask users about their experience after using the app several times. For this task, we have also integrated our app with TestFlight so that we can track detailed logs on how often our app is opened and used, as well as any crashes or bugs that may occur during usage.
© 2014 by Alex Wang, Angela Yeung, and Jessica Liu.