Jason Valenti

Bullystop

Project Overview

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.

Roles & Responsibilities

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.

Goals

Build a Minimum Viable Product (MVP) and get in the hands of students and administrators at a real school.

My Process

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.

  1. Identify Goals - User Centered Design, Business, Practical
  2. Learn - Research, Interview, Observe
  3. Analysis - Statistical, Competitive, Make assumptions
  4. Validation - Prove assumptions, Think about them
  5. Imagine - Ideate approaches, Design studios
  6. Design - Wireframes, Mockups
  7. Present - Get feedback
  8. Refine - Make changes, Incorporate feedback
  9. Prototype - Interactions, Heuristics
  10. Test - Usability testing, Learn, Listen

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.

Early Ideas - Android Mobile App

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.

3 Step Log In FLow
Early Ideas Fig01 - Interview session sketch.

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:

  1. Speed
  2. Security
  3. Easy to use
  4. Mask PII (Personally Identifiable Information)

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.

3 Step Log In FLow
Early Ideas Fig2. - Three step Log In flow wire frame.

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.

3 Step Log In FLow
Early Ideas Fig3. - Three step Enroll flow wireframe.

Administrator/Faculty Dashboard

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.

Incident Inbox
Faculty Dashboard Fig1. - Incident Report Inbox Wireframe.

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.

Incident Report Detail
Administrator/Faculty Dashboard - Incident Report detail.


# Back