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.
