Title IX Incident Report Form

Project Overview

Problem

The previous form solution utilized a software no longer funded by the department, required a manual import of information into their case management system, and asked the user to classify their incident. Users should not be responsible for classifying their incident because of further trauma, lack of knowledge, and the possibility of discouraging the submission of their report.

Goal

Design public incident report form for sexual misconduct or gender-based discrimination that captures information based on the user's role and relationship to the university.

Roles

I was responsible for writing the form workflow, input details, and workflow. The third-party vendor was responsible for developing and designing the form to connect to their case management tool. The department was responsible for procuring the contract, testing, and establishing deadlines.

Audience

Primary users include students (18-34) and employees (18-80), while outlier users encompass community members, including parents (18-80).

Building the Workflow

To minimize development efforts, streamline timeline and effectively communicate needs, I developed a workflow that documented the conditional logic required to customize the form experience for each type of user.

The initial workflow focused on

Reducing user effort and avoiding user overload by only displaying applicable form fields based on their university status, anonymous choice, and role type.
Eliminating incident classifying questions. Users often don’t know what the criminal definitions are, could be in a traumatized state, or multiple violations could have occurred within the same incident. These conditions make it difficult to classify the type of violation that occurred.
Utilizing open-ended questions for describing parties involved as information can vary greatly between cases. One user may be able to provide detailed and specific information such as name or phone number, while another user may only be able to describe the physical characteristics of an involved individual.

The revised workflow recognized that employees who are the complainant or victim in the incident reserve the right to report anonymously. When presenting the initial workflow, our clients were invited to provide feedback which led to this discovery.

Detailed Input Specifications

When it was time to develop the form, I passed along the revised workflow and details for each form field to ensure the input matched the expectation for each question.

The form documentation included details for

Tooltip details for the role question which required the use of legal terminology. The tooltip is essential to help users choose their correct role, while encouraging a high completion rate.

Input types for each question. Based on competitor research, dropdown inputs were used most often. However, dropdown require an extra interaction for the user to review the options. Our report form features radio inputs to present the options upfront, while only allowing 1 selection.

Required validation for each question. The workflow is designed to tailor the questions to display based on user and role, but there are still fields that may or may not be fillable for each circumstance. For instance, there may not be any additional parties involved.

Post Development Revisions

During the testing, additional changes were made to improve the form.

The completion screen features a confirmation number for the user to follow up with at a later time.
Confirmation emails are sent to those that choose to provide their email address.
The “visitor” option was changed to “other” for the university status question “I am a” to avoid limiting the option to official registered university visitors. We want this form to inclusive to everyone.
The “other” option was added to the role question to include any individual that has knowledge of the incident, such as a parent.