Overview

I was recently assigned a project in my Systems Thinking class to try and address a problem of our choice on college campuses. My group decided to take on the problem of “campus safety” – namely, navigating the issues surrounding safety at college parties. After my group presented the initial idea and completed the project, I decided to take it further. Here are few snippets from that process.

The Problem

Identifying painpoints
After conducting preliminary research on campus, we found that the main painpoints with respect to safety at parties were:

• Being in potentially vulnerable/threatening situations, not knowing how to get away without facing a potentially dangerous interaction
• Seeing other students in vulnerable situations at parties, not knowing how to intervene
• Having trouble constantly keeping track of friends (where they are, if they’re safe, etc.)

From our interviews and the central painpoints listed, we realized that if we were to build a product that could meet those demands it would have to be:

• Discreet 
• Able to connect with friends
• Fast/accurate (in terms of how quickly someone could signal their friends)

The Process

Our first inclination was to create some kind of alert system on an app that friends could use with one another at parties, but there were a number of issues with that approach: 1) the app could easily be replaced by sending a quick text message, and 2) apps aren’t always reliable (what if there’s no signal at the party?)

That’s how we knew we needed to create a wearable. That way, users wouldn’t have to worry about finding their phones to then download some obscure app when they’re in a potentially dire/time-sensitive situation. A wearable device would allow for users to instantly communicate with friends and signal them discreetly (something that randomly pulling out your phone wouldn’t necessarily deliver).

Here are a few preliminary sketches:

 

Making design decisions

In the beginning of the design process, we were wrestling with a couple of questions – namely, how would users engage with the product to activate the ‘distress signal’? Would it be in the form of a button? A sensor/touch pad? Would the band be open/closed? How big would it be? We had to take a step back and think about context and setting. This band would be worn at loud, crowded parties – so if we only had a button on the wristband, it could potentially be activated by accidentally bumping into something or someone. We then decided that a touchpad sensor would be the way to go. The central feature to this wristband was that if someone was in a vulnerable situation and didn’t know how to get away, all they had to do was double tap on the sensor and help would be on the way. Now, we had to figure out how to get that signal to friends and/or other safety reinforcements (campus police, etc).  

Justifying the need

When we ran the initial concept by our professor, he asked us, “Why would you need to be polite to your attacker? Wouldn’t you just scream for help if you needed it?” 

Having to answer this question forced our group to come to terms with (and figure out how to put into words) the fact that this product needs to exist because it can actually be dangerous for women to reject men. To further illustrate this point, just take a look at some of these headlines:

These 14 Women Were Brutally Attacked for Rejecting Men – Why Aren’t We Talking About it?

21 Horrifying Stories That Prove Why Women Are Afraid Of Rejecting Men

Rejection: When It Hurts Men More Than It Should

Men Are Killing Thousands of Women a Year for Saying No

…and my personal favorite:

Here’s How To Reject Someone Nicely, According To 10 Women Who Have Done It

From the information we gathered both in student interviews on campus and through our additional research online, we realized that this is precisely why First Step needs to exist. 

Adding additional features

Now that we had the basic model figured out, we had to think about connectivity. How would multiple users engage with this product together? There had to be some kind of visual alert paired with the distress signal. Here’s what we decided:

Once a user signified that they were in need of assistance from their friends, they would double tap on the touchpad sensor and, in seconds, all other bands connected to it would start vibrating and the LED feedback display on the sides of the band would turn from black to an unmistakably bright color.

How would the bands actually connect to one another? We ultimately decided that a Bluetooth connection would be optimal — if a group of friends are at a party with no/unreliable WiFi, they should still be able to reach each other at all times in case of an emergency. 

Finally, we had to think about other key functionality (how would the band be turned on/off? In more extreme scenarios, would there be a mechanism with which to get help from campus police?) We decided to add two buttons to serve these purposes: one for turning the device on and off, and one for emergency calls.

With this concept fleshed out, our group presented the product to our class. A few weeks later, having gotten their permission to do so, I started to take the idea further. 

A Second Iteration

Designing the app: preliminary sketches

In order to get the most out of this wristband, users would need a way to configure it (pairing it with friends, setting the correct campus police number for the emergency button, etc.) I decided this would best be accomplished via some kind of app that users could use for the initial configuration process. Having a clean and open layout was important for clarity and ease-of-use, so I tried to optimize for that in the initial app layout.

Color palette

I decided on a warm, neutral color palette for the app. While I wanted to keep the branding modern and professional with the off-white and charcoal tones, I also wanted to emphasize muted red and yellow hues to subconsciously remind users of “safety.”

First mock-up

When a user first receives their First Band wristband, they need to register it with their account on the app. On the first screen, a user would have to type in the six-digit code that would come with the band to kick off that registration process. 

Then, the user would have to register their specific preferences on the app to further configure the band’s settings. They would enter their name, their signature color on the LED portion of the band, and the maximum radius (in feet) they would need to maintain around their friends before the emergency alarm goes off. 

In the event of the actual party, a user would use their band to be able to connect via Bluetooth to all nearby friends using their First Step wristbands. The third screen depicts a user selecting their friends from all nearby users.

Finally, a user would need to set the location tag for where the party actually is. Once they have configured all these settings, they’ll be good to go.

Need for improvement

The first mock-up depicted above was definitely useful for clearly showing off the core functionality of the app, but in the final iteration of this project, I wanted to clean it up a bit and have a clearer and more defined user flow.

The Solution—the First Step App and Wristband

 

As of this iteration, this is what the final app user flow looks like:

I used InVision Studio to create a higher fidelity prototype for this iteration, and as you can see, it is clearly much more detailed!

Given that the official First Step physical wristband is still in beta, here are some preliminary engineering drawings and pictures of the final 3D-printed model! 

Learnings

1. Less is more. There were several points in the design process where our inclination was to over-complicate the product by adding too many features to the wristband. In the end, we came to the conclusion that simplicity is better so that the core purpose of the product comes across more clearly to an audience and doesn’t become confusing.

2. Consider all perspectives. When designing a product and when trying to market said product, it’s vital to think about how it will be received by all audiences. Our initial conversation with our professor forced us to rethink how might we justify the need for our product for an audience that might not readily see one.