Crosslink Incident Report System

Research the problem

To map out each users group’s experience, I created user journeys. Due to time constraints I wasn’t able to talk directly to the users. However, the client had done a lot of research before I was brought on the project. I was able to utilize their knowledge to get a good understanding of the highlights and pain points of the current system, and pinpoint where we can improve.

Defining the focus

Out of the user journeys, two key experiences emerged:

The incident report form was the natural place to start.

Quick wireframes and frequent check-ins with the district allowed us to get the form content down fast. At this stage my main goal was to get a better understanding of the information hierarchy on this form. Questions that were flagged as more important should be visualized as such through more unique components, while other bits of the form just had to be fast no-brainers.

I explored a few different layouts, from multi-page forms to different groupings of information. As the platform was new and didn’t have a style guide or branding to follow, this stage also included color and UI exploration.

The final solution was a single page form split into three sections. The single page layout made the form fast to fill out, and allowed users to easily double check the information before submitting.

In addition, the form components were easily modified for different screen sizes. This gave users the ability to reference other pages and information as they filled out the form.

After an incident report form is filled, an open incident is created.

The current system revolved around a chain of emails, with requests for disciplinary actions, revisions, and confusion around when something was finally approved. The online platform gave us a massive opportunity to simplify the current flow.

Starting with wireframe reviews with the district, I was able to uncover some important user needs.

First, some incident reports were just that—a report. However, others needed approval action from the district. This approval request need to be clearly highlighted.

Secondly, one of the main pain points of their current email system was that there was no student history attached to the email. Administrators had no idea whether this was a first time incident, or if the student was frequently getting into trouble. If the student was frequently getting in trouble, was it across all classes, or was there something happening with a specific teacher? A more transparent online system would allow for more fair and just disciplinary action.

The final deliverables were three different layouts for the client to test and implement. As no two incidents are the same, I wanted to give administrators the flexibility to take a lot of different actions: from requesting support to adding additional information.

The main challenge was hierarchy of information, especially with the more complicated reports. Information that needed immediate approval, like requests, were highlighted at the top. In addition, administrators could easily see previous reports, and notice trends in student (or teacher) behavior.

Final handoff

Being a contractor, I unfortunately didn’t get to be a part of testing and implementation. Instead, the final handoff included the designs for the incident report form and the form review flow, as well as a robust component library, allowing the team to continue growing and improving the platform.