OVERVIEW
    Objective:       Design Challenge
          Toolkit:       Figma, Sketch, Adobe CC
Focus Areas:      Strategy, Design Research, UI/UX
      Duration:       1 Week
Background:
The world of facilities management may not seem like the most glamorous occupation to many people, but it is undeniably one of the most important resources of any university. To paraphrase my home institution’s (VCU) facilities management department’s mission statement, “We work hard to make sure that the University can carry out its own mission of excellence to the community”. It goes without saying then that having a robust system to process maintenance requests is imperative to keeping the university running smoothly and efficiently. For this year’s Google Design Challenge, I decided to focus on researching and creating such a system.
The Ask:
Prompt #1: 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.

Solution:
RamFix is a mobile platform that seeks to utilize the power of a university community to empower students to help each other address low priority or routine maintenance requests. RamFix is designed to help alleviate the backlog of requests for the facilities management department while also incentivizing students to become more self-sufficient inhabitants of their environment.

Splash Screen

THE PROCESS
For this design exercise I deconstructed the process into three phases: Discover, Design, and Development. In the Discover phase, I performed research to understand current behaviors and generate insights to define the problem. In the Design phase, I made intentional design decisions to address the problems. Finally, in the development phase, I translated these design decisions into visual executions in the form of a high fidelity prototype.
01 | Discover
Secondary Research
I started my journey by delving into secondary research to understand current processes and behaviors. My first stop naturally was to go to the VCU Facilities Management Division (FMD) where I was able to gather some information related to the maintenance request system currently in place:
VCU has 4 categories for maintenance requests: Emergency, Expedited, Routine, and Scheduled/Preventative.

Maintenance requests can be submitted via two ways: a web based CMMS (Computerized Maintenance Management System) or Phone.

Staff are organized into 5 geographic zones across 2 campuses with a dedicated Student Affairs Property Zone.

The majority of reactive maintenance requests are routine requests with a toilet/sink clogged or circuit breaker tripped being among the top two. Other examples included issues such as squeaky doors or drafty windows.

Most of the maintenance requests were from student living areas (dorms, university apartments. etc) and Student Affairs Property Zone.
I was also able to obtain work flows for how the FMD process requests and better understand the user journey.

Work Flow for Routine Request

From this information I was able to generate a core insight:

Facilities management staff were spending a disproportionate amount of time responding to simple routine requests in high density student areas.

My next step was to research existing CMMS systems and what information they were able to give me regarding maintenance trends and habit. Through my research I was able to make a couple observations about current maintenance trends:
Lack of Resources was cited as the greatest challenge for improving maintenance services.

The largest cause of unscheduled equipment downtime was due to aging equipment.

Preventative maintenance strategies were the most popular strategy for FMDs to address maintenance requests.

VCU FMD stated that most of their maintenance was reactive rather than preventive maintenance.
From this information it is possible to say that:

FMDs lack the time and labor resources to implement an effective preventative maintenance strategy because of the overwhelming demand of reactive maintenance requests. This inevitably leads to further deterioration of campus facilities and introduces even more reactive maintenance requests.

Furthermore, as I saw from my first core insight, the majority of the reactive maintenance requests that required attention were very simple or routine issues. Thus, from these two core insights I was able to come up with some initial assumptions:
Since many of these requests are simple in nature and originate from student dense areas, many of these routine maintenance requests could be resolved by students themselves rather than tying up FMD resources.

Students could be incentivized to helping resolve these issues if they were given monetary or equivalent rewards.

The current workflow and reporting methods for requests are inefficient and outdated and a more modern approach could make staff’s lives easier.
Primary Research
With these assumptions in place, I set off to do some primary research. My first two assumptions meant that I targeted a student audience, which is convenient because I am currently going to school. Using 1 on 1 interviews, focus groups, contextual observation, and a survey I was able to gather the following results:
80% of Students said they had submitted at least one maintenance request in the past 2 years that could be categorized as a “routine service”.

68% of Students said they felt confident doing basic repairs and maintenance in their own home.

80% of Students said they would be more confident doing a repair if they had an internet resource guiding them.

45% of Students said they had fixed something that was broken or tackled a DIY project within the past 2 years.

86% of Students said they would help fellow students out if it meant they were rewarded with something.
From my research I also obtained some relevant quotes:
"I love fixing things, mostly because I hate waiting for someone else to come and fix it for me."
- Alan, 22, Interview Participant
"I would love to have had someone come and fix my issue, even if they were a student, if it meant it was fixed more quickly, because honestly I’m just too lazy to do it myself. "
- Survey Participant
User Personas

From this primary research I was able to generate two student personas, one of a DIYer (Do-it-yourself) student and a repair novice student.
These personas allowed me to identify target users that would contribute and benefit from this platform. Users like Abigail who are driven by a desire to help and create could help users like Ben who are less experienced.
My final assumption involved interviewing the FMD again to identify the pain points in the user journey from their point of view.
The number one complaint that I received was that, from a facilities staff perspective, it was almost impossible to get a full picture of the situation from a description over the phone or through a web form.
This primary research confirmed my initial assumptions and allowed me to clearly identify opportunity areas that could improve the pain points within the current Maintenance request system:
A modern platform that gives maintenance staff a complete picture of the issue allows for focused processing and efficiency use of resources.
Empowering those students with a DIY mentality to serve as an alternative ground level maintenance team could help alleviate the strain on the FMD and free them up to more effectively implement their preventative maintenance strategy.

Rough Sketch of Revised User Journey

The next step was considering how to translate these opportunity areas into actionable solutions.
02 | Design
The research I gathered in the Discovery phase led me to conclude that a mobile platform would be best way forward. A mobile platform would allow students to quickly and conveniently submit maintenance requests. To determine the features I wanted this mobile platform to contain, I reiterated the opportunity areas I wanted to address:
The ability to give maintenance staff a full picture of the problem would be very valuable.

Using the full potential of DIY students would give the FMD an alternative resource in managing maintenance requests on campus.
I used a feasibility matrix to brainstorm several potential features for this platform, but ultimately landed on 3 core features I knew I wanted to platform to contain.
The platform should be able to allow students to conveniently submit a maintenance request with the ability to attach photos/videos.
The platform should have the ability to give students the option to receive student help on routine maintenance requests and facilitate that connection.
The platform should contain a rewards system to further incentive students to assist in fixing maintenance requests.
For each of these features, I decided to create a feature flow starting from wireframes and low-fidelity screens all the way to a high fidelity prototype.
Early Wire-frame Sketches
Feature Flows

1. Submitting Requests
Although the current CMMS system that VCU uses categorizes maintenance requests into 4 categories, for simplicity to the user, I made the decision to create just two types of submission requests, Standard and Urgent. To help the user determine which category their request falls under, I wanted each card to have space for a brief definition of each type of request. The FMD would ultimately classify the requests they received from this platform into their organizational system, but this provided a quick pre-filter for increased efficiency.

Low Fidelity Submit Screen

High Fidelity Submit Screen

As the student moves through the request submission form, they have the ability to add pictures or videos to help the responder better understand the situation. This option is retained later as well even after the request has been made so that the student could add new pictures to address new developments if necessary.

Low Fidelity File Upload Screen

High Fidelity File Upload Screen

2. Connecting students who need help with those who give help
In the initial request submission form, I wanted to design an action that allowed students to choose whether or not they wanted to receive student help. I wanted to give students that option instead of making it a default behavior because I wanted to consider the those who still wanted to have their requests fulfilled by the university staff. A dialog box pops up as the student navigates through the submission process asking if they want to accept or decline student help.

Low Fidelity Dialog

High Fidelity Dialog

I chose to use a dialog box because it gave an opportunity to briefly explain the intent and purpose of student help in addition to giving the requestor the ability to opt in or not. The language that I chose in the dialog box was to also emphasize that even if the requestor were to opt-in to accept student help, it didn’t preclude them from still receiving help from FMD.
In addition, Student help could only be received on standard requests and not urgent requests. Again, the intent of student help was only to help alleviate the backlog of routine maintenance requests. At no time would students be expected or asked to resolve urgent and critical infrastructure services. A dialog also showed up immediately if a student selects urgent request to remind them that any life-threatening issues should be handled through the local emergency services authorities and not through the app.
The Live Request Map serves as the main function to facilitate student connection between those who need help and those who can provide help. A student who may need help in one service category may be able to provide help in another. The map automatically populates maintenance requests from students who have opted-in for student help so that they are visible to potential responders. The map shows requests based on distance to the current location of the user of the app. If a responder wants to help a requestor, they can offer to help.

Low Fidelity Map

High Fidelity Map

In order to protect the privacy and security of the requestor, this offer must be accepted by the requester before the responder can see the requestor’s exact location. This adds an additional layer of security to the requestor to ensure that the platform isn’t abused by those who may want to use this app for illicit purposes. It was my intent that at no time should the requestor be obligated to accept help from anyone they don’t feel comfortable with. Finally a small badge showing how many people the responder has helped before serves to establish trustworthiness.
3. Respond for Rewards
The last feature for this platform was to serve as a way to incentivize students to help other students with their requests. Most colleges and universities have localized currency that can be used to purchase snacks or from local food vendors. At VCU, we have Rambucks. The incentivization model for this platform gives responders points for every completed request they have helped with. These points can then be used to redeem Rambucks or other goods or services such as university apparel or memorabilia.
I chose to use a point system instead of a direct monetary system because points serve as more versatile unit of currency and could be used to obtain items that may not be otherwise obtainable such as sporting event tickets. A user’s available points can always be visible in their profile page as well as history of their completed requests, both submitted and ones the have helped on.
I used the following design system to guide my visual design choices as I transitioned from low-fidelity to high fidelity screens.
I chose the color palette to differentiate between different actions and navigation. Standard requests and all associated content are always in blue. Helping actions and navigations by responders are always in green. Finally yellow is for general platform navigation and actions. Icons were taken from Google Material resources.
03 | Development
Once the features were designed, the next step was putting all the screens together into an interactive prototype. I primarily used Figma to do the interactions.
The prototype is shown in way that follows two user journey simultaneously, that of a student requester and a student who responds to help. This prototype simulates how this interaction would occur in near real time. Although the platform has the capacity to have a traditional student - requestor FMD interaction, I chose to highlight the unique student-student interaction. Please enjoy!
Ultimately I tried to design an experience that accounted for the needs of both students who required assistance and of students who had the motivation and the expertise to be a force of change in the community. I believe that oftentimes students aren't given enough credit in their abilities to affect change. RamFix was designed in mind to be able to empower a community of students to become more engaged in their environment as well as demonstrate their ability to be responsible and capable adults.
TAKEAWAYS

This design exercise was a very fun but also very challenging assignment. Not having an identifiable problem to solve meant I had to dig deep in my research to analyze current behaviors and see what could be improved upon. I thought this was a very valuable lesson in understanding that although many processes in the world may not have obvious problems at first glance, there is almost always a better way to do something. This follows my personal philosophy of “proactive innovation”. The ability to identify a better way to do something before a problem can arise is the ultimate way to innovate and this design exercise challenged me to do exactly that.

Furthermore, this was an opportunity for me to try and design a platform that could adhere to Google’s Material Design standards. I learned so much about Google Material from this exercise which will undoubtedly help me become a better designer in the future.

If I had more time, I would have liked to make the interaction animations better. Figma is a great screen designer but still lagging a bit behind in the animation capabilities of software like Principle or Flinto. Other considerations could be exploring the concept of hiring students to the maintenance staff in conjunction with using this platform.

Overall, it was a lot of fun and I am glad I was able to partake in this experience. I appreciate your time for reading through my design challenge exercise and thank you for your consideration!
Sources & Attributions:
Special Thanks to the VCU Facilities Maintenance Department
CMMS:
https://medium.com/@readinbrief/cmms-maintenance-statistics-you-should-know-going-into-2018-1cad2795b24e

Back to Top