The challenge

A new system for reporting any facilities that may need maintenance or repair. Design an experience that allows students to report building or equipment issues on campus.


I hung around the campus, talking students and staffs to understand the current reporting process and its pain points. Here are the findings:


images from internet


images from unsplash

Current Process & Pain points

1. Students Don’t know if something is “reportable”.
Students rely on the contact information on equipments to report. If they don’t see any information on the equipment, they will just give up.

2. Student's reporting issue process is too complex.
Students need to email, call or even talk to building staffs directly ro report the issue. The reporting process is too complicated and thus many students often just ignore equipment issues.

3. Staff need to do too much typing work.
When students call or email, the building staff need to type the details of the problem into their system. When problems are solved, Staff also need to email students.

4. Staffs need to login different computers when troubleshooting issues.
When staffs decide to trouble shooting problems. They will usually write down the location and the issue. When they arrive the location and solve the issue, they will login the nearest computer to close the case and see the location of the next issue.

Problem Framing

In order to finish the whole reporting and fixing process, a lot of information exchanges will happen between students and staffs. All these information exchange is organized in a subjective and random way, which decreases the efficiency of exchange and increase the cognitive workload for both sides.

How might we improve the experience of information exchange between students and staffs?

Solutions overview

For Students:

I. report "equipments with codes"

The general idea for the reporting system is to standardize information to reduce students' and staffs' cognitive workloads, and to improve the information exchange efficiency.

Most electronic equipments have QR code or barcode on them. These codes could be used to recognize the equipment's identity and location.

1. scan CODE

Scan the code on the damaged equipment.

2. select the issue

The equipment’s identity and location are recognized automatically. All possible problems are listed.

3. Done

Positive feedback and estimated fixing time.

Problem and location are the only 2 things that matter when students file a report. The design standardizes the damaged equipment problem and location. So that:

II. report "equipments without codes"

Most non-electronic equipments like toilet, faucet or light bulbs don’t have codes or any other contact information on them. But students still need to describe the issue and location because there is no way to auto-detect the equipment and the precise location. The only thing we can do is to try make the process as easy as possible:

1. Take a photo

Take a picture about the broken equipment.

2. PINPOINT the issue

Use the pen tool to draw a circle on the broken part.

It helps users to describe which part of the equipment is broken.

3. describe the problem & location

Auto-detect the building location so that students input less.

An suggestion of how to describe location precisely and concisely in the location placeholder.

The design of the location function for reporting equipments without codes

At first I assumed precise location is hard to describe. So I went to ask a few native speaker students to describe locations of specific items to see if that was true. And here were their answers:

Native Speakers:

“Near 1103, Luddy”

“ground floor near the restroom 9900. Luddy.”

“Informatic West Lobby”

“Mans bathroom. first floor Luddy”

To my surprise, the answers are all concise and accurate. They all used obvious locations (1103, restroom 9900 ground floor, West Lobby, mans bathroom first floor) to indicate the precise location. I think maybe it is because they are native speakers.

So then I asked one international student to describe another precise location. After she finished, I showed her examples from previous native speakers. And then I asked her to do that again:

International student 1st round:
“Informatics the entrance near the bus station’s women’s bathroom close to the common area with the elevator, first floor. The second one.”

International student 2nd round:
“In the bathroom near 109”

It shows that a good example could help students to better describe the location.

Based on that insight, I drew different wireframes to strike a balance between the easiness of input and the standardization of information. And I chose the 3rd one.

For Staffs:

I. Desktop case manager

I went to the staffs in the library, asking them to talk about and show their work process. And no surprise, I found they already have a system to manage all the tasks. Based on their workflows, I designed a few new features for them.

I. No More Typing work
Students' report will be directly sent into the system. And when the case status is changed or updated, the system will automatically notify the student who reports the case.

II. The Pocket
I add a new concept "pocket" into the task category. Staffs can pick the cases they are going to solve and put them into the pocket.
It helps to reduces staffs stress. They can focus on a few problems at one time.

III. Sidebar Tabs for fast switching
The staffs need to switch between different task categories, and they need to use the filter function to apply different filters everytime they need to switch. For such a high frequent operations, I designed sidebar tabs to allow staffs to switch quickly. It also makes the whole task pool more organized.

IV. Customizable
From interview I learn that staffs only look at a few things in the charts to make decisions. So I decide to make the charts customizable. Staffs can decide which metrics to display and in whatever order they want. That will improve their efficiency.

V. More Intuitive Visual Design
In the expanded case view, I redesign the layout and visual style. The 2-column layout displays information more efficiently. Everything is organized by expandable cards so it is easier for staffs to see the information they want to see.

II. Mobile case manager

When staffs have decided which problems to solve, they need to memorize the issue and the location before leaving, in case they forget something.

And once solving the problem, they will find the nearest computer to login the system to close the case. Because they are afraid that they might forget to do that. It is extremely inconvenient for the staffs.

All cases in your phone

All cases are in the mobile app. They don’t need to remember or write down anything to remind themselves.

check case details

Staffs can check the details issue description at the issue location.

close a case on the phone

Once they solve one case, they can close it immediately on their phone.

Tests & Iterations

After finishing the design, I printed out all the reporting screens to test them with 5 students.

For the student reporting system, all processes went pretty smooth. Students can successfully understand and use the report system, except that they don't know where to find the code on equipments. They don't even know there were codes on equipments.

So I decided to add another landing page before the scanning/photo shooting.

Product strategies

For the student reporting system, I decide to integrate it into an existing app like Canvas or One IU:

  1. Reporting equipment issues is not a frequent action for students.
  2. Because when students want to report a problem, they should be able to do it right away. It would make the experience terrible if students need to download a new app to report a equipment issue. They might never do it.
  3. And it is unlikely that students will keep an app exclusively for reporting equipment issues in their phone.

For the mobile case manager, an independant app would be a better choice:

Due to time limitation, I couldn't test the new mobile and desktop case manager with staffs. I just showed them the screens, and didn't get many feedbacks from them. Future iterations are important for them: