Resolve

Next generation maintenance systems for UC Berkeley.
A concept for a 5 day design challenge.

Introduction

Resolve is a system for UC Berkeley that utilizes Berkeley’s ID cards into its mobile application and maintenance closets. Resolve’s application and maintenance closet simplifies the reporting and receiving process for maintenance requests with the Cal 1 Card. All UC Berkeley students and associates own a Cal 1 Card. A user may submit a report and pin their location in under a minute by opening up their phone camera and scanning their Cal 1 Card. The administration and individuals responsible for repairs will be immediately notified of their new task. Students and those in charge of repairs may view report details on the Resolve app or on CalCentral.

Research

Interview Preparation:

To prepare for my interviews, I brainstormed questions some discussion questions that could help me understand how students and staff at UC Berkeley file maintenance requests. I hoped to understand the following:

  • What interviewees do when they encounter a maintenance issue or something that needs repairing
  • If interviewees have records of problems and issues 
  • Who do interviewees contact or what do they do if they can’t get help
  • What tools interviewees use to report, fix, and document the issues
  • For those who deal with maintenance reports, what happens if they need help? What do they do if they can’t resolve the issue? 
  • How might I create an experience that can benefit those who report maintenance issues and those who fix the problems?
  • Do any of interviewees share the same problems?

The Interviews Process:

I interviewed 8 students and staff members at UC Berkeley on how they report facilities that need maintenance or repair. Out of the 8, approximately half were responsible for maintenance and repair requests. During my interviews, I looked at things from the interviewee’s perspective which helped me gain a better understanding of their problems.

I asked different questions depending on who the person was. I asked questions that helped me understand what they did when the encountered
problems or issues. I was curious to hear whether they would fix the issue themselves, contact someone for help, or forget about it. Once they discovered an issue, what tools they used to fix it and how long it took. If the process took too long, how did they feel. Does the problem get successfully fixed? Everyone who participated in the interviews were associated with UC Berkeley in some way. Participants were on campus and at UC Berkeley’s dorms.

Above are some of my notes from when I interviewed a professor who teaches a mechanical engineering class on campus. He shared a story of a year when he had a major technical issue during his class when all the technicians were on lunch break. Because he was unable to resolve the issue with the projector and there was no one available for help, he had no choice but to cancel the class. He also noted that there have also been times when technology and cables are

stolen. In those situations, he also had to cancel his class. If he sees a maintenance issue walking around campus, he does not report it unless it looks urgent. If it is urgent, then he would call UC Berkeley’s facilities manager or the UC Berkeley Police Department.


Here I interview a design specialist in Jacob’s makerspace. The individual I interviewed is the main point of contact whenever there is maintenance issue or repair. He is notified of the issue with a walkie talkie, by email, or in person. He keeps track of maintenance issues and problems “inside his head” at work; however, at home he uses a Google spreadsheet to keep track of how he fixes TVs. This is because recording maintenance issues in a makerspace become too time consuming even though it would be really useful to have a record of what has been going on.

Post Interview:

Here are some important pain points my interviewees had:

  • Reporting a maintenance issue or repair is a hassle and time consuming 
  • Determining who is responsible. Who is responsible for paying for and fixing the repair? 
  • Documenting maintenance repairs is not always done effectively. Those who are part of the repair service try to get the job done as fast as possible. 
  • Some issues don’t get fixed 
  • Reports go through several people before reaching the people who take action on those issues 
  • Repairs take too long. Students want repairs completed as soon as possible

The Problem

At UC Berkeley's dormitories and main campus, the process to report maintenance issues and repairs is complicated.

Design Requirements

  1. Has a record of all reports 
  2. Simple and allows users to submit a report in under a minute 
  3. Able to get support fast 
  4. Does not need to go through several people to report an issue 
  5. Notifies the user where the repair process is at 
  6. Informs the user when the repair process is completed 
  7. Allows those filing the report and those receiving and taking action on the issues to communicate with each other

Idea Generation

During my brainstorming process, I thought about whether a web application, phone application, or physical product would provide the most effective and simple experience for users. I came up with potential use cases, different scenarios, and considered important features I wanted integrated into my applications.

I wanted something that would allow users to have a record of all reports. This data is important in seeing when yearly and monthly maintenance checks have occurred (or were supposed to happen). It also ensures that reported maintenance issues are being taken care of. If they are/are not, there is documentation on who was responsible for problem and who filed the issue. However, a form with detailed questions would be time consuming for users. Therefore, it was essential that my application be simple and fast to use.

Wireframing

I designed my first Figma prototype without focusing on its visual design. All UC Berkeley students, employees, and affiliates have a Cal 1 Card and activated CalNet ID. They are able to sign into the application without creating an account. Once they sign in, they are able to join different groups around campus and submit new reports.

Mid Fidelity Prototype

I began experimenting with different colors, fonts, reviewed Google’s material guidelines. Then, I received user feedback from two students. They informed me that the app doesn’t look it is for reporting repairs. The colors were also unappealing to them.

High Fidelity Prototype

After receiving user feedback I made the following changes: 

 


So how do we use Resolve?

The Physical Prototype

The wooden box is a small model of a maintenance room. UC Berkeley students, staff, and affiliates will be able to access the maintenance room after their submission is approved. The approval process will be immediate unless the object they are borrowing has other restrictions. The user will be able to unlock the maintenance room and a maintenance locker with their Cal 1 Card.