MSIV Blog Update #7

Final Conclusions and Recommendations

In conclusion, we decided that the concept of our interface is still worth investigating, but that there are some adjustments required before it should be executed with real users in practice. All participants felt generally safe walking alone due to the limitations of our experiment (the lowest rating was 3/5 in the likert scale, “moderately uncomfortable”). Regardless, all participants universally felt safer when walking with a buddy than alone, demonstrating the effectiveness of our concept. In addition to this, we also determined that female participants tended to pick buddies of the same gender as themselves as they felt more comfortable simply based on the fact they shared the same gender. All participants also had good experiences with their chosen buddies, with an overall satisfaction rating of 5/5 across all 5 users. The participants mutually agreed that profile photos, descriptions, and ratings helped them to decide on their choice of buddy. This demonstrates that the users’ expectations based on the SafeBuddy profile aligned with their actual experience during the trip. However, participants felt some improvements were necessary before they are likely to use the application in real practice.

 

Some suggestions put forward were that we (1) provide an incentive in finding a buddy, such as a point or reward system and (2) provide better security background checks for the buddies. In order to promote wider use of our application, we decided it would be beneficial to incorporate some of these suggestions so that it may appeal to a greater audience. Hence, we recommend that the focus be put on implementing a point or reward system to encourage users to utilize the application more, as well as in implementing more rigorous background checks for all users. This in particular could take the form of a simple Facebook authentication that would give each user more credibility.  Another addition we recommend to include in the app would be more categorical information to describe each user, such as their hobbies, height, gender, which school they attend and what their walking preferences (i.e. walking speed) may be. Participants also suggested that being able to sort the buddies in terms of rating or gender would aid their processing of choosing the buddy. Therefore, we concluded that the overall design approach was valid, but required adjustments in order to better inform the buddy decision-making process and to encourage usage of the application.

 

Reflections on our Design and Evaluation Process 

 

Initially, we explored the idea to improve users’ safety during late night commutes. We began by conducting five in-depth interviews with UBC students who were familiar with SafeWalk. The interviews were semi-structured, yielding rich data and raised specific questions about the topic. Due to time constraints and large amount of time required for us to transcribe each interview, our sample size was smaller than desired. This may have negatively impacted the accuracy of our findings. Although interviewing Safewalk were expected to yield important findings, the administrative concerns made the scheduling of the interviews time-consuming, hence making it impossible to hold within our schedule. In the future, preparing ahead will ensure the scheduling of these interviews. On the other hand, the usage of online questionnaires allowed us to gather information from a larger pool of candidates about their experiences in commuting home, increasing the amount of data we were able to collect. Freeform questions also allowed us to avoid presupposing answers to our design questions. Through this, we realized that escorted walks made people feel safer, and wanted to further expand this capability by use of crowdsourcing.

 

We started by creating paper prototypes and performing cognitive walkthroughs with other classmates. The cognitive walkthroughs allowed us to quickly identify the pain points in the workflow and design of our interface. This also helped evaluating the prototype from an outsider’s standpoint, which was more representative of how our interface would be used in real practice. This allowed us to easily change our design to address problems we uncovered during the walkthroughs. Overall, our usage of low fidelity prototypes facilitated quick iteration enabling us to test different ideas quickly in the initial stage before committing to a design.

 

Next, we created a medium-fidelity prototype based on the chosen low-fidelity prototype. We realized during the experiment that our prototype may have negatively affected our experiment as our participants were confused during the experiment due to the lack of dragging capability. We felt that although the experiment was useful, it would have been more effective if it happened later in the design process. In addition, we felt that recruitment could have been improved during our experiment, as non-incentivized participation made the scheduling of the experiment difficult. This scheduling issue directly affected our experiment as we could not replicate the feeling of danger that the commuters would experience in real life.

 

In conclusion, following a user-centered design process allowed us to answer many of the questions regarding whether an application that allows users to crowdsource people around them to walk with to improve their perception of safety is a viable idea. Through our design process, we successfully found evidence to suggest the validation of our experiment goals. Hence, we believe that our overall design process positively impacted our ability to discern the information that we required, and allowed us to discover new trends regarding the correlation between how people perceived their levels of safety and their levels of comfort when travelling by themselves and with another person.

MSIV Blog Update #6

Pilot Test Results (max 200 words)

We conducted our pilot test with two female UBC students. The participants encountered some difficulty with our prototype such as scrolling through lists and dragging the search radius since it was not a high-fidelity prototype. We decided to include these information in the instructions instead of updating our prototype for the actual experiment, as they were not crucial in answering our experiment goals. For example, we found that setting the time caused some confusion during the buddy matching stage, since the time entry was hardcoded into our prototype. We changed our instructions at the actual experiment to state that the time cannot be changed on the prototype. One of the biggest findings of our pilot test was that the participants were reluctant to come in on two different days for the experiment and to stay on campus until after sundown, thus making our designed experiment unrealistic. We revised our experiment to pair the participants with the fellow researchers whom they did not personally know instead of with each other to decrease scheduling conflicts and conducted the experiment at the participants’ most convenient time.

 

Experiment Abstract (max 150 words)

We address the idea of pairing individuals to accompany each other during their commutes. To demonstrate the benefits of having someone to walk with while travelling to a certain destination, we conducted an experiment with 5 participants to show that people generally feel safer when walking with a buddy than walking alone. The experiment consisted of two parts: (1) people matching and (2) walking alone and then as pair. The first part of the experiment was designed to discover what information users considered useful when choosing their walk buddy. The second part of the experiment had 2 levels within-subjects, comparing their perception of safety when walking alone versus walking with their chosen buddy. During our study, we discovered that participants felt universally safer walking with a buddy and that users could accurately guess their satisfaction with the walking buddy if provided with accurate information.

 

Revised Supplementary Experimental Materials 

We kept all our interview questions, questionnaire surveys and coding sheets the same, but modified the consent forms slightly to better reflect the permissions we required for the experiment. The updated consent form can be found here:

Updated Participant Consent Form

Blog Update #2 – Next Steps

RECOMMENDATIONS 

After the field study, we confirmed the necessity for such an interface. A large percentage of participants that we interviewed have felt unsafe commuting alone, and a significant amount of them commute home alone after dark regularly. Safewalk currently focuses on female users as they are socially perceived to be more vulnerable than male users. However, our results show that men also feel unsafe commuting alone, and thus we decided that our interface should include both females and males. Another reason Safewalk is not being utilized despite commuters’ feelings of being in potential danger is the complexity of the process and the waiting time involved. Our interface should focus on creating a system that is easy to use and set up so that users are more inclined to use the system. As well, to minimize waiting time, the system should support a booking system and minimizing a time-constraint. To further distinguish our interface from UBC Safewalk, we should also consider how we can make the interface work off the UBC campus, where the distribution of users may be more sparse. Finally, our results show that well lit and populated roads are popular in the case of commuting home alone. Our interface could suggest these “safer” routes that could be used during the service or in the case that the user cannot find a buddy.

UPDATED TASK EXAMPLES

Of our three task examples from Milestone 1, we are preserving Task Examples 1 and 3, and changing Task Example 2. The initial proposal in the Task Example 2 addressed a scenario where the user is a bike rider living in an area with a relatively high rate of crime, wanting to bike and have a biking partner for safety reasons. After conducting our field study, we decided that it is more relevant to our study to target users who currently use Safewalk, but would prefer to use other alternatives based on certain reasons such as long waiting times or preferring something a little less formal. This is because we discovered that there are significantly more cases of people feeling unsafe but not wanting to use Safewalk, than those who specifically bike to commute and want a safety biking buddy.

Old Task Example:

Martin lives in an area with a relatively high rate of crime. For health and convenience, he prefers biking to work and usually travels with a partner for safety reasons. One day, however, his biking partner is unavailable to accompany him back home. Martin does not own a car and public transit in his area is very sparse. He does not wish to pay the exorbitant fee for a taxi but has no one else to bike through his neighborhood with.

Revised Task Example:

Martin is currently a UBC student who lives on campus and stays out late to study most nights. As he usually heads home around 1am, he feels unsafe walking back to his residence by himself, and so has been using the Safewalk services offered by UBC Safewalk to have people accompany him home. However, at such a late hour Martin is usually quite tired, and he dislikes having to wait at least 10 minutes (and often longer) for people from Safewalk to arrive. He also feels guilty for making people from Safewalk come to him as he knows that they are often going out of their way for him when they walk him home. None of his friends who stay on campus studies as late as him and so Martin is often left wishing that he had someone to walk home with other than Safewalk staff.

PRIORITIZED LIST OF REQUIREMENTS

Functionality

Absolutely must include:

  • The following are rated “absolutely must include” as the core functionality of our proposed interface:
  • Designate start and end radii, with start date
  • Suggest “walking buddies” based on common start and end radii.

Should include:

  • Allow users to view basic details of potential buddies. This is to allow users who may feel safer walking with people with certain characteristics.
  • View picture of buddies. This is to allow users to identify their designated buddy, addressing the issue of trust and safety of the service itself.
  • Allow users to decline walking buddies.
  • Direct messaging between potential buddies. This is to facilitate introducing them to each other and avoiding people that a user could potentially feel unsafe around, as well as decreasing social awkwardness, which was important to an interviewee. This can also be used in assessing the “friendliness” of a potential buddy.
  • Reporting users who abandon their safe buddies.
  • Suggesting roads and routes that are commonly accepted as well lit

Could include:

  • Specifying mode of transportation. Originally, we considered this interface as a possible solution for safely commuting by bike, but found that the majority of users used a combination of walking and public transit. This could be useful for users for whom public transit is not an option?
  • Ratings and reviews of the safe buddies.

Could exclude:

  • GPS Tracker that maps out the user’s route as they are using the service.
  • Trip history (time, locations, people you walked with)
  • Designate trip start time range.

Users

Absolutely must include:

  • Students commuting home alone after dark. As was found in our interviews and the questionnaire, users felt most unsafe when commuting alone in badly lit areas.
  • Users commuting through possibly areas generally perceived as unsafe.

Could exclude:

  • Users who use a mode of transportation that is not walking or public transit.

DESIGN ALTERNATIVES

Our original approach was similar to Tinder in the sense that users can “accept or decline” an offer of commuting together. However, unlike Tinder, our original design included a time constraint where only users who have similar departure times can be matched. In order to solve this issue, our alternative design uses the metaphor of a bulletin board. Instead of providing the departure time, users are only required to post their start point and destination point, and the board is cleared everyday to ensure requests are current. Among the posted information, users can select whichever they like and directly contact the person who posted the corresponding information to schedule when to leave. This approach has the advantage of flexibility in terms of choosing when to leave. Also, users can use the scheduling session as icebreaking time to minimize the awkwardness they may have when travelling together. However, there is a disadvantage of this approach where users are not automatically matched. This may be time-consuming, because users will be required to contact potential companions one by one in order to use the service. Another possible feature is a GPS tracker that would allow concerned friends or family to view the route of the user, or that could be shared by the user.

Our second alternative design started from the observation that people feel safer when they are with someone else when commuting. Instead of physically travelling together, the second alternative allows users to communicate with other users by video call while travelling. The advantage of this approach is that the video call can act as a live closed-circuit television. The person who is on the line can immediately identify the situation that the traveller is in, and act accordingly to help. In addition to that, users are not required to be physically at the same location to use the service. Thus, it is easier to match users. However, there is a disadvantage where users are required to have Internet connection throughout their travel.

Blog Update 5 – Medium Fidelity Prototype

In developing our medium fidelity prototype, we divided the functionality of the application into two parts to support the two phases in our experiment: buddy matching and walking.

 

How much horizontal and vertical coverage?

In terms of horizontal and vertical coverage of the application, we will have a vertical coverage for the selection of SafeBuddy and both horizontal and vertical for the trip. The user will be able to look at all the SafeBuddy profiles and inform the experimenters of their top 3 choices. The graphical user interface (GUI) of the matching section will have clickable relative links that will bring someone from a screen to another, cover flow, and have a realistic look to the envisioned system. However, it will not display other possible features of the application such as creating or cancelling a trip. The map will be both horizontal and vertical, including the map, timer, and the emergency button. The GUI of the real-time trip part will be fully realistic with regards to user interface (UI).

 

Simulation of Behavioiur

In terms of simulated functionality, we must be able to go through the flow of the system until we select a buddy, and from there, we must be able to pull up an application that will show a realtime map, with an emergency button. In terms of creating profiles, we will be manually simulating social media parsing. We will be manually pairing the participants based the results of the users’ top 3 choices instead of a matching algorithm. The functionality of the realtime part of the application is more fully featured, and will be able to do realtime location tracking based on an android application template, and will have a emergency button to simulate the emergency response design, that will contact one of the experiment staff.

 

Appearance

In terms of appearance, we will place greater emphasis on modelling how the application will work than on the actual outer design for this prototype. Hence, we will be using template UI elements, as to look like a standard mobile application, whereas a final implementation of the application might use custom UI elements.

Non Graphical Elements

Our interface includes non-graphical elements in the sense that matching algorithms, and geofiltering/fencing must be completed. We plan to get around these by limiting the choices to be made in the interface and by hardcoding some features in the mockup.

 

Prototyping Tools

We plan to implement our medium fidelity prototype in two parts. The real-time mobile app will be completed with a Google Android Studio map activity template, with an emergency button element. This will allow us to leverage data available during the trip. The matching section will be implemented as a Microsoft Powerpoint presentation with clickable relative links to ensure the flow is followed. In addition, Powerpoint is a platform that allows us to easily add slides like profiles, without having to use code. These choices were made because of the familiarity of our team with these tools, which reduced the length of time it took to create the prototypes.

 

 

Demonstration

A link to download the interactive buddy matching prototype is available here.

It is preferable to use Powerpoint 2016. Captions are available on each slide explaining functionality, and in presentation mode, the system is interactive in terms of navigation. Clicking on the appropriate buttons will show appropriate flow and functionality at each screen

 

Blog Update 4 – Experiment Design

 

Experiment Goals

From Blog #3:

  1. To find out what aspects about a buddy would make people feel safer and more willing to choose them over others
  2. To find out how people perceive safety when walking in a group or by themselves, and how this perception manifests physically (eg. in the form of shortened walking time when walking alone)
  3. To consider limitations of the Safewalk service and the feasibility of extending its functionality

Revised Goals:

  1. To find out what aspects about a buddy would make users pick them over other choices
  2. To find out the differences in how people perceive their level of safety when walking with a SafeBuddy or by themselves
  3. To find out whether the users’ expectations based on the SafeBuddy profile aligned with their actual experience during the trip

The major focus of our previous experiment goals from the Blog Update #3 was not on the SafeBuddy application, but rather a more general experience of commuting and using SafeWalk . We revised the experiment goals to cover the cases that are directly related to the users and the application of our design. In order to do so, we have revised our goals to narrow the scope by solely focusing on the experiences of the SafeBuddy. Specifically, our goal is to evaluate the effectiveness of our design in increasing the perception of safety while commuting.

 

Experiment method:

Participants

We plan to recruit a total of 5 new participants for this experiment, primarily through convenience sampling via direct face-to-face or online conversations. These participants will all be current students at UBC who are familiar with smartphones.  In addition to these participants, each team member who does not personally know the participant in the study will also be a part for the buddy matching, and also for the field experiment if the member is chosen during the buddy matching. This design was chosen as it allows a greater selection and variety of buddies for the participants to choose from.

 

Conditions

We plan to compare two main conditions in this experiment within subject: how the measures of feeling safe differs when one walks with someone else, versus when they are walking alone. By doing so, we aim to discover the extent of the impact of providing users who currently travel alone with a SafeBuddy. In order to do this, we will ask participants to go on two separate walks that are similar in lighting and distance. However, one walk will be of them walking by themselves, while the other will be walking with a buddy that they chose during the buddy matching phase.

 

Tasks

The following are the different tasks that participants are expected to complete in our experiment:

  1. Given a selection of different profiles of SafeBuddies, rank the top three.
    1. Participants will be given profile cards with a picture, name, number of mutual friends, and a short two sentence self description of each buddy (that we will have participants provide).  See Appendix 1.2. for example of a profile.
  2. Given a set path, walk alone from a designated starting point to the destination
    1. Participants will be told to keep the SafeBuddy application on them, with a map implemented to show and track their location and route in real time.
  3. Give a rating of perception of safety from 1-5
    1. Participants will be given a simple paper survey to rate accordingly. See Appendix 1.1.
  4. Given another set path, walk with your chosen safety buddy from a designated starting point to destination.
    1. This path will be different that the one in Task 2, but will be similar in other factors as discussed below.
  5. Give a rating of perception of safety from 1-5
    1. Again, see Appendix 1.1.
  6. Final interview with the experimenters

Note that both set paths provided will be very similar in lighting, distance, and number of people walking around. We plan to organize our walks around 6-7pm, by which the sun will have set and thus natural lighting will be relatively dimmer. Both routes will be set on the UBC campus and will have fewer people walking on it in an attempt to simulate a more authentic “late night” feeling. Also, the order of tasks 2 and 4 will vary for each participant to control for any participant bias for walking first alone and then with a buddy, or vice versa.

 

Design

The experimental design will be 2-condition, within subjects to identify how the subjects’ perception of safety change based on the use of the SafeBuddy application. The independent variable we will be modifying is the presence of a SafeBuddy. The results will not be significant when accomplished using a between-subject experimental design since we want to discover how individuals’ feelings change when walking alone versus walking with a SafeBuddy, not how the perception of safety might vary between different types of users. Additionally, individual differences such as individual preference and prior experience walking through the route in our subjects might change their perception of safety between the two walks. A within-subject experiment would allow us to better identify and analyze these cases.

 

Procedure

The overall procedure is designed to be completed within two 30 minute sessions for each participant, for a total maximum of one hour per participant. We will run the experiment over two different days for each participant. On the first day, the participants will be asked to rate their top 3 SafeBuddies based on the SafeBuddy profiles provided. Once all the participants complete choosing their top 3 SafeBuddies, the experimenters will pair users that included each other as the top 3. In the second session, these users will complete the remainder of the experiment by walking a route alone, walking with their paired SafeBuddy, and the post-experiment interview. We will provide a short questionnaire containing the Likert scale questions to the participant after each walk for them to evaluate their perception of safety. After both the walks are completed, we will interview the participant for further information to answer our experiment goals.

Apparatus

Matching Part

The participants will be placed in a room with the experimenters and the interface prototype, along with appropriate note-taking materials (Appendix 1.4) which will be used to record the participant’s answers regarding their process of evaluating the best prospective SafeBuddies.

 

Walking Part

The participants will walk two different predetermined routes on the UBC Campus around 7pm. There will be a experimenter at the destination point and an experimenter at the source point of the routes. The experimenter at the destination will have the questionnaire on a sheet of paper and a writing utensil. These routes will take around 10 minutes each.

 

Independent and dependent variables

  • Dependent Variables
    • Perception of safety based on 5 pt scale
    • Satisfaction with buddy selection after trip (likert scale i.e. disagree -> agree)
    • Time of travel (given by phone)
    • Choice of SafeBuddy
  • Independent Variables
    • Walking with a buddy versus walking alone
    • Route
    • Time of day
    • Pool of SafeBuddies that can be chosen

 

Hypotheses

H0: SafeBuddy application decreases or has no effect in the perception of safety

H1: SafeBuddy application increases the perception of safety when walking with a SafeBuddy

H2: SafeBuddy application increases the perception of safety when walking alone

H3: SafeBuddy application increases the perception of safety when walking with a SafeBuddy and when walking alone

 

Planned statistical analyses

T-test for:

  • Perception of safety
  • Travel time

Mean/Median/IQR for:

  • Satisfaction rating of SafeBuddy choice

 

Expected limitations of the planned experiment

    The major concern for this experiment is that the experiment must be safe for the participants but also needs to recreate any natural unease and fear that the participant would normally feel when commuting. Since the experiment is designed to be safe by having multiple experimenters watch over the participants and takes place when it is relatively early and there may still be a degree of sunlight, the participants could feel disproportionately safe during their walk. To control the experiment, the same routes will be chosen for all participants. Although this attempts to limit undesired variations created when some participants walk in a route that is “scarier” than other participants, it will not eliminate variations caused by the individual differences between participants. Some participants may be more familiar with the route than other participants, altering their perception of safety. Another individual difference that cannot be accounted for is the participants’ personalities. The two participants’ comfort levels with each other could negatively affect their experience of walking with a SafeBuddy even if the participant normally enjoys walking with a companion more than walking alone.

 

Supplemental experiment materials:

  1. Interview Questions (1.3)
  2. Observation Sheet for Matching portion (1.4)
  3. Questionnaire for rating (Can be part of interview) (see appendix 1.1)
  4. User Profiles of each participant and group member

 

Appendices:

 

1.1.

Perception of safety survey given to participants at the end of their routes.

https://drive.google.com/open?id=1xF_1JSKeSRQ_4OQsjYS9ZqJmoL3R903ZZZktZWJpczY

1.2. Example of a buddy profile template

https://drive.google.com/open?id=0B0o8btIcsGf6dFhCaWhxdVlPaDQ

1.3: Interview Questions

  1. What affected your choice of the SafeBuddy?
  2. Do you think the SafeBuddy profile gave you a realistic expectation of your SafeBuddy? Why or why not?
  3. What information on the SafeBuddy profile was not helpful in choosing a SafeBuddy?
  4. What information was missing that would have aided you further in choosing a SafeBuddy?
  5. Do you think walking with a SafeBuddy helped you feel safer? Why or why not?
  6. Do you think the SafeBuddy application, or something similar is something you would use in the future regularly?
  7. How did you interact with the SafeBuddy application during the walk?
  8. Did you feel safe walking alone? Why or why not?

 

1.4. Observation Sheet for Buddy Matching

 

Profile Number of Times Looked At Patterns in viewing Buddy profiles Notes
1
2
3
4
5
6
7
8
9
10
Total time taken to choose a buddy
Final Rank of Buddies

(1, 2, 3)

 

1.5. SafeBuddy satisfaction survey given to participants at the end of their routes.

https://drive.google.com/open?id=0B0o8btIcsGf6V3hYcGc0MlBFS0U

Blog Update #3 – Low – fidelity Prototyping & Cognitive Walkthrough , Proposed Experiment Goals

Updated Task Examples

Our tasks examples 1 and 3 have not changed since the first milestone, which can be found here: https://blogs.ubc.ca/cs444safebuddies/2017/01/23/ms1-blog-update-due-tues-jan-24/

We are modifying task example 2 as follows:
Martin is currently a UBC student who lives on campus and stays out late to study most nights. As he usually heads home around 1am, he feels unsafe walking back to his residence by himself, and so has been using his phone to call UBC Safewalk to have people accompany him home. However, at such a late hour Martin is usually quite tired, and he dislikes having to wait at least 10 minutes (and often longer) for people from Safewalk to arrive. He also feels guilty for making people from Safewalk come to him as he knows that they are often going out of their way for him when they walk him home. Martin wishes that there were a system he could access on his phone that would help him connect with others who are close in proximity and are heading the same way as him as he heads home.

 

Low-Fidelity Prototypes Demonstration:

We have developed two separate prototypes, and have video walkthroughs for both.
Prototype 1: https://drive.google.com/open?id=0B8aGBg4UG1fLbm9NaUphRmtwM28
Prototype 2: https://drive.google.com/open?id=0ByPAcqv1hgMlVC1zRm1ZOE1OVFU

Additional information about the prototypes

We have 2 prototypes, both geared towards supporting task examples 1 and 2.

The first prototype was meant to support long trips via transit, primarily for people who are anticipating a trip later within the day. The decision to schedule a meeting was thought out to provide anonymity for users. Under this prototype, we realized that two people may not start at the exact same location, and go to the exact end location, so we introduced a radius selection that could allow users to gauge approximate direction of travel. We had made the decision to primarily focus on public transit length trips, because we feel like that is a gap that isn’t covered by existing services. One priority we had was the control of geographic information. Although buddies would be displayed based on a filtering criteria, we did not want the exact location of the source and destination points shared, given that people may put in home addresses, and inadvertently expose private information about themselves. We noticed that this design has limitations in terms of availability, in that you can’t schedule legs of the trip to travel with different people, and for a trip to be successful, a single person has to be found that will go the majority of the trip. This design decision  was made because we felt it would be safest to know that you have a buddy until you are near your destination. In addition, the atomic characteristics of each trip and each buddy would allow ratings to accurately reflect trips. The trip mode of the application, once a trip has started, has support for emergency functions, and basic pathfinding.

The second prototype was meant to support a more spontaneous approach, and possibly allow group travel in addition to individual travel. This prototype does not have scheduling capability, but uses a combination of cached GIS data, and a provided destination to determine if people around you are travelling in the same direction. These design decisions were made to support multi-leg trips, where buddies may drop off the trip at some point, and to provide more support for an individual user who is not able to find a buddy on their trip. As a result of these decisions, a trip with a buddy isn’t as atomic as it would be in the first prototype, which may dilute the buddy rating system, as there is no guarantee they’ve made a whole trip with someone. A key decision we have made is that the exact destination and location of a potential buddy, as per the first prototype, will never be displayed, however, a chat utility will be available to locate your buddy once you are there.

 

Walkthrough Report

We performed a cognitive walkthrough of our initial low-fidelity prototype (prototype 1) with two different people; for the purposes of this post, they will be referred to as user A and user B. The most common sources of confusion for both users were the lack of system status indicators, lack of instructions, and lack of feedback, especially in the sections where the user specifies the trip parameters such as start time and trip start radius. User B pointed out that using only Facebook to sign into the app could exclude some users from the application but considering our target users, this isn’t too big of a concern. User B sometimes missed the “next” buttons on the start and destination parts, which may have been a product of how difficult it was to differentiate the button from the background on a low-fidelity prototype. The messaging function was well understood and performed by both users, but user B had difficulty figuring out how to request a trip from the messaging interface and critiqued the lack of a profile picture in the messaging interface. User A expressed that they would have liked to see an “Uber-style display” of possible buddies, but this brought up the privacy and security issue of displaying users’ locations to strangers with unknown intentions in the interface. Both users seemed to like the idea of the emergency button, but there was some ambiguity as to its actual function.

In its current iteration, our prototype would likely fail to support all of the task examples as some users would be unable to figure out what our interface was meant to do and how to even set up a trip in the first place due to the overarching lack of instructions, feedback, and system status indicators. Ignoring those, task example 1 still would not have been completely fulfilled, as the user may have trouble figuring out how to request a trip with a buddy they’d decided to travel with. Our prototype interface allows the user to search for and contact other users heading in the same direction as her, but only falls flat in the aforementioned circumstances. Ignoring the issues above, our revised task example would have been fulfilled. The interface is designed for a mobile device, which allows the user to access the application “on-the-go”. It does not involve other volunteers or staff and only recruits buddies traveling in a similar direction, which addresses the user’s concerns about making others spend extra time to accompany him.

 

Proposed Goals of Experiment

Our experiment goals, ranked by order of importance and ability to test them, are as follows:

  1. To find out what aspects about a buddy would make people feel safer and more willing to choose them over others
  2. To find out how people perceive safety when walking in a group or by themselves, and how this perception manifests physically (eg. in the form of shortened walking time when walking alone)
  3. To consider limitations of the Safewalk service and the feasibility of extending its functionality

               

To address these goals, we have developed two interface prototypes, which we aim to evaluate against each other. The main purpose of this would be to determine which interface is the most effective at helping us to accomplish our goals, and which aspects are more helpful than others in terms of user engagement. We plan to address goal 1 through our in lab experiment where we will show various participants pictures of potential Safety Buddies, and observe which ones they would rather pick. Goal 2 will be slightly harder to address in our experiment due to safety concerns of setting up an experiment at night, and so we plan to modify our experiment slightly and perhaps ask people through interviews about differences in their behavior when walking in a group or by themselves. The third goal we will address through direct observation of the Safewalk service, and comparing its functionality to our own prototypes.

MSII Blog Update #1 – Project Direction and Task Examples

Project Direction

     The direction of our project has changed from the initial idea of a “panic button” app that spontaneously provides aid to the user through crowdsourcing, to a pre-booking idea for the user(s) to find a Safety Buddy prior to their trip. As well, instead of simply having UBC students as our primary user base as originally intended, we decided on making the user base open to anyone who needs to travel from a start point to a destination point within Metro Vancouver. This would allow us to not only expand our app’s user base, but also increase the reach of the app as it would open up more options of safety buddies for users. The following is a summary of the general intended user workflow of the proposed app:

     A general user using the app would select a start point, a destination point, and a departure time for the route they are intending to take. The app will then plot all the possible routes between the points and then search for other nearby users who have reported similar routes and departure times. Each user that is matched will receive a notification that someone nearby is looking for a Safety Buddy. They each have the option to either accept or decline the match. Should one of them decline, they will each have the option to search for other buddies or cancel the search altogether. If they both accept, however, they will receive directions to each other and can then begin their journey together as each other’s Safety Buddy. This would encourage users to not only meet potentially new people in their community, but will also allow them the option of travelling with another person in order to feel safer overall.

Task Examples

1. Danielle is a UBC student that frequently studies late at the campus. She is concerned with walking by herself because of the numerous sexual assaults that have happened in UBC lately, and so she always calls UBC Safewalk to walk her to the bus loop. However, the bus stop where she gets off is another 10 minute walk away from her house. She usually talks on the phone with one of her friends during that walk, but still feels unsafe. She knows that her neighborhood is a popular neighborhood for UBC students to rent in, and occasionally finds herself walking in the same direction with another student halfway. In occasions like this, she feels a lot safer, and would like this to happen more often.

2. Martin lives in an area with a relatively high rate of crime. For health and convenience, he prefers biking to work and usually travels with a partner for safety reasons. One day, however, his biking partner is unavailable to accompany him back home. Martin does not own a car and public transit in his area is very sparse. He does not wish to pay the exorbitant fee for a taxi but has no one else to bike through his neighborhood with.

3. Charlie is Alex’s sibling. Charlie is concerned about Alex’s well being, because Alex has a daily commute after school, with a portion of the trip home passing through a neighborhood with a high crime rate. Charlie would like to join Alex on the trip back from school, however, other obligations prevent this from happening. One day, Charlie is home, and notices that 20 minutes has elapsed from the time Alex is expected to be home. Charlie calls Alex to ensure Alex’s safety, but receives no response. Charlie would prefer to have information available regarding Alex’s whereabouts, but is unable to get it sometimes as Alex may not want to pick up the phone. When Charlie is able to get a hold of Alex’s location, Charlie feels less anxious.

 

(Due Tues, Jan 24)