Author Archives: AmeliaYap

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)

Welcome to our blog! We are Safe Buddies and we will be documenting our progress on designing and prototyping our project idea throughout the term here.

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.

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

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.