Campus Safety
Mobile application designed to use bystander intervention to help students.
UX Researcher, UX Designer, UI Designer
User Research, Storyboarding, Competitive Analysis, Wireframing, Prototyping, and Expert Evaluations.
Nov 2019 - Dec 2019
Darshan Munkur, Sandy Nguyen, Veeny Bhatt
Sexual assault on college campuses is a significant issue that needs to be addressed. It is a concerning problem because it was found that 23.1% of undergraduate female students and 5.4% of undergraduate male students have experienced sexual assault. In fact, college women are three times more likely to be victims of sexual assault in comparison to all women. Additionally, sexual assault occurs more frequently than other campus crimes. For every one robbery committed, two sexual assaults occur to college women.
of all students experience rape or sexual assault through physical force, violence, or incapacitation
of students have experienced stalking since entering college
of survivors know their attacker
of female undergraduates will be victim to some form of sexual assault before graduation.
of sexual assaults are committed by someone the victim knows
The campus safety app is designed to prevent sexual harassment on campus. Using a predetermined passphrase, the user will be able to contact and request for aid from either registered users, emergency contacts or local authorities. The predetermined passphrases are inconspicuous and can be said without alerting their assailants. It also hosts an in app feature that the user can utilize when they feel the situation isn't severe.
.png)
We conducted our primary and secondary research during this phase. Primary research included formative research techniques such as observations and interviews conducted. While our secondary research relied upon scholarly articles and research papers to help us better understand the domain and the problems associated with it. We also researched about the tools that are employed by the university to help alleviate this issue and find out why these shortcomings exist.
Due to the short time frame, we were able to conduct 3 interviews from an IUPUI female student, an employee from IUPUI CAPS in charge of sexual assault cases on-campus, and the Public Information Manager from the Indiana University Police Department.
We decided to look into some of the competitors in this domain to understand what they are doing and how effective their solutions have been. We were able to understand some of their applications features and some of their fail points and this was beneficial to our design process. We found that most of the applications currently utilize social computing and this aligns with our secondary research. Some of the competitors that we looked into were as follows:
A question of how to reduce the number of sexual assaults that occur on college campuses arises. We will be focusing on the prevention of college sexual assaults with design ideas that involve community assistance. We decided to tackle the problem of safety when traveling alone or with an acquaintance. Based on our secondary research, we found that 80% of sexual assault and rapes are perpetrated by someone known to the survivor while on college campuses while 90% of survivors know their attacker. In the case of an escalating situation, we want to provide the users with the ability to request and obtain aid from others.
We believe that the key requirements would be
A collaborative approach that would use bystanders to help resolve escalating situation.
Having verified users on the application to help protect the users in the application
Notifying the users immediately about the situation and requesting help from nearby users
Based on the key requirements identified and our prior research conducted, we generated a problem statement which is as follows:
"How might we design a Collaborative Solution to Combat Sexual Assault on College Campuses?"
We then generated the following persona based on our prior analysis. Based on our primary and secondary research we came up with two personas that reflect our target users needs, behaviors, goals, and determination. These personas are of two distinct archetypes:
The persona's we designed were based on the interview data that we collected, we noticed that most of these incidents stem from the reluctance of using university resources like safe walk and trying to rely on people's help in order to get back to safety. We also realized that people aren't sure whom to place their trust in and they are often assaulted by one's they know and these are reflected in the worries of our persona.
We proceeded to brainstorm ideas to combat the issue. We decided to use the diverge and converge approach to generate ideas that would solve this problem. We conducted multiple brainstorming sessions in order to get a wide spectrum of possible design solutions, we also included possible stakeholders into the mix to bring in outside inspiration with designing a solution. After doing so we narrowed down to three ideas that we thought would combat the solution and were socially, economically and technologically feasible.
A voice recognition based app that notifies verified users and government bodies based on predetermined keywords
.png)
An app that marks areas as danger zones based on the crime rate in area and notifies contacts when entering the area and provides details like time required to leave area, location, etc.
After careful consideration and thoughtful deliberation, we found that the first design solution Voice based Safety App would be one that meets our key requirements of collaborative solution that uses bystander intervention to help users. By only taking in verified users we can meet one of our other requirements. The user's will be notified of the users location and be provided with details regarding to aid required based on predetermined keywords.
After deciding on our design solution, we decided to sketch out real world scenarios showcasing the use of our design solution with the personas we contrived previously.
In the above scenario, Alena is returning from class late at night. She feels paranoid and gets scared as she is the only one walking. Trusting her intuition, she presses the emergency button in the app. A couple who lives nearby gets notified, and they decide to help her walk home.
In the above scenario, Sierra is walking home, and it is almost midnight. Someone begins to follow her and before starting to be physically aggressive with her. Sierra panics but remembers her safe word. She realizes that the app has a voice recognition feature, and just by saying the safe word, the alarm gets activated. Sierra says the safe word and thereby initiates the alarm. The application then sends a notification to people nearby. People that receive the notification and come to rescue her. As people are arriving, the perpetrator runs away.
Our team decided to sketch out some paper prototypes to think through the structure and to smoothen the workflow. We then proceeded with acquiring user feedback for the paper prototypes. We took into consideration the initial sketches from our initial paper prototyping session and drew inspiration from similar applications to proceed with this step. Paper prototyping gave us flexibility to test various designs and allowed for us to perform user testing as well during this stage to get some user reviews on the design.
From the paper prototyping sessions, we were able to learn some of the flaws our initial design presented. We found that users had trouble utilizing the voice recording feature and were confused by navigation in the app, this was a major flaw that we looked to address in the final prototype.
We took in user feedback in these sessions and learned a lot from our potential users. When questioned about their experience, we found that they were able to understand the features but would have liked for some sort of onboarding experience to better understand the features.
After distilling the feedback of the paper prototypes, I created high-fidelity prototypes using Adobe XD. These prototypes were then utilized for user and expert evaluation.
One of the most important features of the application would be user authentication.D uring the signup process, we would like the users to scan their identification card such as Crimson card that would allow us to verify their identity. On successful authentication, the user can proceed with registration.
This screen shows the notification that would be received by the other users in the application.The users would then be prompted to either accept or decline the emergency alert that has been initiated in the area.
Here are the screens that the users would utilize to set up a “pass phrase” or a “activation words” that would be inconspicuous, as they are meant to ensure the safety of the user.
The screens show the recording process that the user would face after they determine the activation words of their choice. Once the user completes the process of recording, the user can test voice alarm.
The following screens show the user navigation that would be shown to the responders of the alert. On reaching the destination, they are provided with the set of contacts that could be utilized to deal with emerging circumstances.
We also provided an in app option to send out the emergency alert through the app if the user is capable of doing so. The user can request the responders of their choice based on their circumstances out of the ones provided.
We performed evaluations with potential users and experts which helped us in gathering insights about the usability of the application. Following key findings from our evaluations gave us some direction moving forward in terms of what should be our focus.
Though voice prototypes seem cool and surprisingly easy to make, we faced a lot more issues than we would have expected with the voice prototype itself. User testing for the voice prototype was quite difficult since user's didn't know how to use a voice prototype.
User's prefer the simpler interface and might not notice the subtle changes in your UI that you hoped they would notice. In our project, the UI for the voice recording feature had to undergo multiple iterations and we still had trouble since we were trying something new. Turns out the best solution was to use an interface that they are used to.
One major concern for us was the widespread adoption of our designed solution. Most applications face difficulties with user acquisition and retention. We believe that partnering with the university and having campaigns for awareness wouldn't be as helpful as we would have hoped for. Moving forward we would like to ideate on how to overcome the challenge of lower adoption rate and development of more intuitive interface for the voice prototype
.png)
.png)
