SVA Maintenance — Google UX Design Challenge

Project Overview

Problem Statement:

“Your school wants to improve the upkeep of campus facilities by creating 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. Consider the process of those filing the report and of those receiving and taking action on the issues.”

Project Summary:

To design an experience that allows students to report building or equipment issues on campus, I did research on the current system and process my school (SVA) adopted and how students feel about it. Based on the current process and using some other systems as references, I designed a maintenance request function integrated with the existing GoSVA app.

Timespan:

One week

My Role:

Individual UX project involving research, synthesis, making low-fi and hi-fi prototypes

Process:

1. Research the problem space: set research goals, draft interview questions, interviews, research solutions in parallel situations
2. Synthesis: debrief the interviews, define current user journey, find pain points and opportunity areas
3. Ideation: think about how to improve the existing system, design the new user journey
4. Design & iterations: wireframes, user testing, iterations, UI design
5. Reflections

1. Research the problem space

Research goals:

When doing research, I set the goals to be figuring out 3 main areas:

• Existing service: What is the current facility maintenance system and process at SVA? Are there any other alternative ones elsewhere?
• Students & staff’s situation: What do they currently do with maintenance issues? How do they feel?
• Maintenance Technicians’ situation: What do they currently do with reported maintenance issues? How do they feel?

Interviews:

I talked with 9 people, including 7 deep interviews with people from SVA and 2 short conversations with students from other schools.

Some questions I used to guide the interviews:

Research on my own:

Besides interviews, I also tried to find out what other schools do about maintenance by searching for relevant keywords.

2. Synthesis

The interviews were information-rich. Here are some findings:

What the existing system looks like

Existing Service: SVA currently has a maintenance request portal open to all students.

• Every department has a Technician (technical support) and a Head of Operations (academic and general support) onsite during business hours. A maintenance technician is in charge of fixing facilities on the whole campus.
• There’s an existing facility maintenance system called School Dude, which staff and students can access through the SVA service dashboard. It’s mainly used by staff and students who live in dorms.
• IT support uses a different system, which communicates with the facility maintenance system in some cases.
• A few common ways to request for facility maintenance in schools:
  (1) Students report to faculty in person, and the staff will contact the relevant department in school (SVA, NYU, Monash)
  (2) Students email work order form to the relevant department (NYU)
  (3) Online work order system (SVA, Columbia University)
• Some apps/systems that can be used as reference:
  - NYC311 (an app with which users can check government announcements and request for maintenance)
  - BuildingLink (some apartment buildings give residents access to this app to access services, including requesting repairs)
  - Citizen (an app that provides real-time safety and crime information across the city, and alerts you to nearby incidents)
  - GoSVA (an app that gives students access to some of its services)
  - Taobao (a Chinese shopping platform. I’m inspired by the way it shows the tracking of the deliveries and the expected arrival time)

Students: They barely know about the portal. They prefer to talk to staff directly. The willingness to report varies.

• Students have barely used the maintenance system, or don’t know about it at all. There was no onboarding for them.
• They usually talk to staff in the department to report any damages.
• They prefer talking to a person regarding maintenance issues because they can see them taking actions more quickly.
• They are okay with using either an app or a website to report. However, if it’s an app, reporting damages shouldn’t be the only function, since the needs don’t occur often.
• Some students are willing to report damages that don’t affect them; others choose to simply avoid using damaged facilities without reporting if there are alternatives.

Maintenance technician: They don’t seem to have major problems with the current process.

• There are maintenance technicians on campus 24 hours.
• A supervisor gets the request first and then assigns it to a technician who’s available and suitable.

Decision: to focus on the reporters’ part:

After gathering the insights, I realized that there are currently far more problems for students than for the maintenance technicians. The students barely know about the online system, while the technicians are more familiar with and used to the current process since they use it every day. The department staff are kind of in the middle, but they also don’t find the current system the best solution.

Hence, I decided to focus on making improvements on the reporters’ side.

Current journey for reporters:

Just to show how they are currently involved in the process, and the pain points they might experience:

Key design principles:

The synthesis process made me realized what factors can smooth out the reporting process and what should be avoided. I listed a few principles that will guide me during the ideation and design stage:

• Awareness. Students should get aware of how to access the service.
• Convenient. The more convenient it is, the more likely students are willing to report.
• Community. Users can see what’s happening around them. A sense of community can also motivate them to report issues.
• Timely update/response. When the user does care about the progress of the case, give them clear responses and expectations.
• Relevance. Information presented should be necessary and clear.

3. Ideation

Idea brainstorming:

The following are some ideas that I believed can improve the current user experience:

• Integrated with the GoSVA app. The service can be easier to find and consistent in branding. Also, students don’t have to keep an extra app on their phone, which they might not use often.
• Shortcuts (like the Shortcut app on iPhone) to make reporting quick and handy
• QR codes around areas prone to damages. When scanned, auto-fill some info
• Give explanations for some potentially confusing options
• All the records are accessible within the same department. When making a request, make sure this is not the same issue already reported by someone else.
• Can see other damages on campus which might affect the user
• Automatically sort if a problem should go to the department staff or school technicians. Students can also report department-related stuff like stationery supply.
• Updates on the home screen/in the notification
• Emergency repair shortcut

The new user journey:

4. Design & Iterations:

Sketches:

Wireframe prototype:

Click here to view the project `SVA maintenance wireframes`

User flow:

Highlights (refer to the marks on the flow chart above):

1. Quick reporting by scanning QR codes:
   In areas where problems occur more often, there are stickers with QR codes that remind students they can report issues within a fairly short time.
   The QR codes can be specific to a certain area or a device. So when someone reports through the code, some location details are prefilled in the form (one can still edit if they want).
2. Integration with the GoSVA app:
   Since the maintenance issues don’t come up very often, there’s no needs to download and keep a separate app for this task.
   Also, the reporting process will be a bit easier when given the information about the students already. The reporter doesn’t have to fill out contact info over and over again.
3. Emergency repair call:
   In emergency situations, people want to talk to someone instead of submitting a form and waiting for a reply. The app made it clear that you are able to request an urgent repair by calling someone.
4. Clear and minimal form:
   Comparing to the existing system, I removed/changed some fields that are unnecessary or confusing. The users don’t have to pay attention to what they are not supposed to know.
5. Avoid multiple requests for the same issue:
   Once some minimal information (the building, floor, and area/type) is filled out, you will get asked if it is the same issue as another similar one (if there’s any). This avoids the confusion for the technician, but also adds up the importance of a particular issue since it shows multiple people are getting affected by it.
6. Community alerts:
   You can get notifications on some maintenance issues going on that might affect you. You can make preparations accordingly.
7. Clear expectations of when the issue will get solved:
   You can get a general idea of how soon the issue will be fixed.

User testings & revisions:

I conducted user testing on the wireframes with 3 people. Based on their feedback, I made some improvements that are implemented in the high fidelity version of the prototype:

• The physical QR codes can be smaller and more friendly-looking. The big maintenance massages all-around can leave people the impression that the facilities get broken very often and easily.

• QR code scanning function should also be part of the app in case people don't have or know about other QR code scanning functions on the phone.

• Make the problem information fields less repetitive. The problem summary and description fields are similar and not both necessary.
• The community contents can be in a more visible place. The testers thought it was useful information, although it was not very conspicuous in the design. Now the information is also on the home page.
• Allow the reporter to decide if they want to get update notifications. Someone might just report an issue irrelevant to themself for the favor of the community, and not want to get bothered by excessive follow-ups.

UI prototype:

Click here to view the project `SVA maintenance hi-fi`

What’s not in the prototype, but also part of the whole experience:

• The system should be accessible even without the app. In case someone does not use the GoSVA app, they can still scan the codes and fill out the form on a web page or find the portal by online search.
• The maintenance supervisor has the right to decide which cases are more urgent. In the existing system, you are asked how urgent the issue is in the form (default is medium). However, this does not make much sense in my opinion: if an issue is not so impactful and severe, students might not bother to report; if it’s an emergency, they prefer talking to a real person than filling a form. Therefore, I replaced it with the emergency call feature for the simplicity and clarity of the process. It’s up to the supervisor whether they think something requires extra attention.

5. Reflection

What work well:

1. There are real needs for enabling students to report issues conveniently on their own. At first, I was worried that students don’t need this system because they can just talk with staff who are around most of the time. But it turns out that it’s because I only talked with people from our department, and we are kind of special — we have fewer students; hence we are close to each other. There are other departments with far more students, and it’s hard to find staff who can handle the reporting. This system should be useful in those cases.
2. The community notifications are useful, according to user testing.
3. The stickers will be handy and can raise students’ awareness. One of my classmates lives in the dorm but doesn’t know about the maintenance system. I gave her a magnet from the technician, and she says she’ll keep it around because it'd be useful in case she needs maintenance services. I believe this can benefit other students in a similar way.

Some extra details could have been added:

After I finished the design, I thought of another thing that can be included:

• Show the numbers of people who report the same issue so that the maintenance staff get a sense of how impactful an issue is, and the students get a stronger sense of community.

Limitations:

1. I didn’t get to interview students from other departments or campuses. As a result, my solution might be geared towards my own department.
2. There might be pain points on the technicians’ side that can be addressed, but I didn’t have enough research about that. The technician told me that he usually gets informed of a task by email first with some basic details, and then he has to go to his computer to check the ticket — afterward, I realized this was irregular and could have alluded to some pain point, but I didn’t remember asking why he had to do this :(.
   Also, I didn’t get to do research on the limitations of the current system in the back end (it’s an independent system that is adopted by multiple schools, not specific to SVA), and regulations about school maintenance systems. Those factors might affect the design as well.

What I learned from this project:

This is the first individual UX project for which I have to reach out to people I don’t know. I usually don’t play an outbound role in a team and have a fear that I might miss important information if I fail to ask tactfully during interviews.
This project gets me more confident in interviewing people; I feel that I now get the hang of being flexible and asking the right questions to suss out the information I don’t expect to get.

Thanks for reading!