Bullystop was incident management software designed to help schools manage reports of bullying in a safe and secure way. We built a powerful set of tools to provide students and schools the ability to safely report, respond and manage incidents related to bullying in real time.
A big challenge for me on this project was having to design essentially two different products. One for Students and one for School Administrators.
On this project my main role was lead UI/UX designer. Often times, in startups, clear-cut lines that normally define the boundaries of traditional roles are blurred. Bullystop was no different. I co-founded this startup with some of my best friends who are all very talented and posses really good cross functional skill-sets. I did a little bit of everything as most people who work at or start startups do.
Build a Minimum Viable Product (MVP) and get in the hands of students and administrators at a real school.
To meet the goal of building a MVP, I knew right away that the single most important part in my design process would be the research data. For solving most design problems I encounter, I like to use the process outlined below.
I like to have a framework to follow and I tend to adjust the steps project-by-project, depending on the requirements, but for the most part, you can't go wrong following these steps.
To kick of the ideation process be began looking at our research. We interviewed 490 students and discovered that 68% of them had Android based mobile devices. We also discovered that 98% of students would prefer that the Incident Creation process contain no more than 3 steps.
We also conducted extensive interviews with 59 school faculty members, 137 parents of kids who would be using the app. The common themes expressed by parents, school administrators and faculty were:
Here is a look at the first iteration of wire frames for the three step Log In flow. Surprisingly enough, this first iteration was the most well liked in the focus group of students we tested them against.
Here is a look at the first iteration of wire frames for the three step student Enroll flow. Students in the school we were working with are assigned unique Student ID numbers. This was so important because it allowed us to use the Student ID to mask the identity of the student creating an incident report.
One thing we learned really quick about Public Schools is that they have a lot of red tape. I was not really surprised to find this out. Developing products to meet business needs and delight users is hard; trying to do that within the confines of the Public School ecosystem, even harder.
After reviewing our research and talking to nearly one hundred school faculty members and administrators we knew the product needed to satisfy the following business objective: An administrative dashboard for receiving, reviewing, responding and archiving Incident Reports.
The design pattern I decided to implement to solve this problem was: Email. that's right, email. We had a long design studio with key administrators and faculty members where we brainstormed various approaches to making the UI as simple and universal as possible. One thing that we all agreed upon was the fact that everyone in the room, as well as the rest of the administration and faculty knew how to use, without a doubt, was email.
Here is a look at the final wire frame for the Incident Inbox. Students in the school we were working with are assigned unique Student ID numbers. This was so important because it allowed us to use the Student ID to mask the identity of the student creating an incident report.
Next up was the actual Incident Report detail interface. We spent a great deal of time interviewing faculty members about email, the types of email software they use and work with on a day-to-day basis. 78% of users were familiar with and stated they use some form of email, online - daily. I designed the Incident Report Record interface to feel as close to a native email experience as I could.