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
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.
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.
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.
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:
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:
“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.
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.
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.
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.
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.
For the student reporting system, I decide to integrate it into an existing app like Canvas or One IU:
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: