The sharing of location data is important to anyone with a GPS in their phone. This is a broad population. We performed contextual inquiry to learn more about how people use existing systems, and what features they might like to see in a location-sharing app. In particular, we inquired about social and commercial uses of location-data sharing. We interviewed people who represented
of location data sharing services.
This user is a middle-aged iPhone owner who does not currently use voluntary location sharing. She believes her location data is being used by a variety of applications, but isn’t sure which ones or what it’s used for.
Lessons Learned
Suggestions given by the subject:
This user is a 27 year-old, married, software engineer. He has used most of the location-based apps on a fairly regular basis (around once a week) because of his interest in receiving offers for goods that are of interest to him. For example, he uses Foursquare to get frequent flyer miles at airports and Subway discounts. He also likes to know where his family members are present. He uses social networks on a regular basis but prefers not to be overloaded with information and thus controls his settings with care.
Lessons Learned
Things not being done properly by the existing systems:
Suggestions given by the subject:
This user, who we’ll call Joe, is a 26-year old student who uses location-based services like facebook check-in almost every day. He is also using other involuntary location services. He likes sharing his location information with his friends because it is a useful way to convey his personality and interests to other people. However, he is sometimes hesitant to publish his location for fear that people might know too much about him. Joe is also interested in sharing his location information in exchange for discount offers from stores.
Lessons Learned
Things not being done properly by the existing systems:
Suggestions given by the subject:
Detail:
(Goal, precondition, location, frequency of use, how learned, possible errors, time constraints, who else involved)
The goal of this action is to share some socially meaningful location information with friends or family. As a precondition, the user must desire to share something with a specific person or group of people. The types of things that can be shared can be learned in part by doing. Because the relationships are ongoing, the frequency of use may be anywhere from several times a week to several times per year. When the wrong type of relationship is defined, the relationship can be edited.
The goal of viewing notifications is to learn something socially meaningful about friends who are sharing location information. As a precondition, the friends must have already established a sharing relationship with the user. This activity may be performed as much as several times per day, if the information is compelling. This activity can be learned by doing: some information is presented, and the user can browse by scrolling, clicking, zooming, and panning. This is a fairly safe task -- the worst thing that can happen is the user is not viewing the desired data, but this can be remedied by backing up in the interface. Friends are involved in providing data to be viewed.
The goal of this task is to view offers from organizations that are geographically located near the user’s current location. The user would be able to negotiate the level of location information to share with the organization. In order to start this task, the user should be physically present near the organization and the organization should have offers to present to the user. This task may occur multiple times during a day depending on the places that the user visits. A user would be able to learn this task by experimenting with the various location settings displayed on the screen. The user may have a particular location setting in mind, but the options presented may cause her to select a different one. This error is irreversible but can be prevented with a confirmation dialog box that asks the user to confirm the location setting. Since the offers are shown when the user arrives at a particular organization, the user may feel obliged to make a decision quickly. Therefore, presenting relevant information in an easily-digestible way is important. We could imagine that an agent from the organization would be involved in the negotiation. However, for this course project, we assume that the organization presents a canned list of options and the user selects one of them.
The goal of this task is to review and perhaps change the type of data the user is sharing with others. The precondition is that one or more relationships have been previously established, and the desire to review or edit is generated either by curiosity, or by some recent behavior that a user might want to share or not share in some existing relationship. Because the user can see all of his/her own data here, the task may be performed multiple times per week. We expect people to be curious about their own data and how it appears to others. This activity can be learned by doing -- it just involves scrolling, clicking, zooming, and panning. Viewing is inherently very safe, and editing can be made more safe by including the option to undo actions.
This is a good start, but there are some big things missing. You don't actually discuss classes of users, just specific interviewees. Try to think about who your users are more holistically - right now they're sort of points along a 1D continuum.
You also don't seem to really get a good feel for what the tasks your users use to solve your problems, and instead you describe actions that your app will let users take. Don't forget that the next step is to make three separate designs - you shouldn't already have picked one. Think of task analysis as the analysis of tasks that need to be done to solve the problems.
Please also move your interview information to the GR1 page. I'd appreciate it if you made these changes, since we'll be working off this document for the whole rest of the project.