Initial Exploration and Reflection

Before diving into my research and design, I planned out the process and steps I should take to better tackle this problem.

Keywords: Accessible, Inclusive

Problem Identification - Stakeholder Map

I first started with mapping the stakeholders in the maintenance and repair process. This process helps me as a designer to think more comprehensively on the potential audiences, that way I can design more inclusively. The stakeholders are identified below:

Problem Identification - Secondary Research

I then performed analysis pulling from campus maintenance reports and explored current systems available for students on campus to file maintenance orders. In the general guideline of the campus facility, one problem identified is that the repair rate of the Duderstadt Center (Engineering library) is low, while the complaints of broken work stations (VizHub) are high.

Keyword: Unrepaired Workstations

To explore that problem, I made an interaction map understanding the current system at the university on reporting repairs. I found out surprisingly, the school site is clear and intuitive. Students can easily access the website and file a claim.

If the current system is working so well, what is causing the low reports on the campus maintenance order?

Problem Definition - User Interviews

I conducted user interviews with 3 users, one student, one office worker in the library and one technician who is in charge of library repairs. Some quotes are listed below:

Interviewee 1

"If I see something is not working, I will just switch stations until I find a working one. I am aware of our maintenance site. I just did not bother to report."

Interviewee 2

"Students have a totally different portal than us. We have a more complicated system for internal use. And it would be much easier for students to file orders on their own."

Interviewee 3

"I will occasionally get a complaint like nothing is working in our library. If you all file a request when you see something broken, the repair would be much up to date."

"I will I can close a working order without returning to my desk."

Problem Definition - Affinity Map

I clustered the data I collected during interviews to find similarity and common pain points.

Keyword: Lack of Motivation, Time Inefficiency

Problem Definition - Survey Results

I distributed 30 surveys at the Engineering Library (without revealing Google's name in the survey) and received 24 complete answers. In the survey, I asked students to rate their satisfaction level on maintenance quality and their awareness and frequency on filing maintenance requests using the school website.

I also additional questions on their access to technologies when they encountered a broken item. This process helps me validate my user interview findings and secondary research results.

Findings

• The current website of maintenance repair is actually concise and intuitive, but not many students are aware of it.
• Students tend to switch places instead of filing repair because they think it is staffs' responsibility. It is also faster to switch stations than filing report because getting broken station fixed does not address their immediate needs.
• Technicians need to return to their workstations to close a working order, which wastes time.

Goals

Reporting Side:

To design a ticket system that allows students to report maintenance issues right away that is also accessible in the current location without requiring to go on an additional website.

Technician Side:

To design an app that allows them to get updated information on a maintenance order or to close an order without returning to their workstations.

Wait... No personas this time???

Due to time constraints, I combined my persona development with the scenario. Rather than creating basic user profiles that have risks of stigmatizing myself, I prefer walking through a design problem with an actual story. I described a student, Terry's frustration when working with Vizhub (the working station) of the university library.

The students can select the location and categories of their request. I use icons to represent the categories because I want to have the typing to be minimum. Once the students select a category, the color will change accordingly to reflect their choices. They can also navigate to the previous page by tapping the arrow button on the bottom of the screen.

Phone Screen Design

The technician will be able to manage the order on their phone. It is more portable and easier to update than on the website, which will increase their efficiency.

Technicians can sort the work orders by their priority, date, location and other criteria. They will see the list of orders and a simple overview of the request. The requests are labeled with different colors indicating their priority.

The technicians can also read more details about the request by tapping into the synopsis. On this page, they can also change and update the status of the order.

I also considered the situation of collaboration. Since technicians collaborate in teams. I designed a people page as well. They can see each other’s profile and role, and the current order they are working on. By updating each other, the technicians can divide the tasks more efficiently.

Google products

Considering Google offers a varied range of products. I want to incorporate some existing products into this system. I added a page for the Google calendar on the technician side. Users can add a maintenance request to their calendar and have a Google reminder set for them

If I am given more time to dive deeper into this question. I would change and explore the following:

• Incorporating more actions in the kiosk design and understand what other factors I overlooked during the design process.
• Expanding on the screen designs of the technician side. What are some other functions and features the technician needs to make the process better?
• What would the system react if multiple same requests are submitted? How can it inform students a similar request has been submitted?