Google Design Exercise



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.


To begin, I did some thinking about my own personal experiences as a university student and the maintenance issues I have had to deal with since then. What was the process to let the university know that I had an issue with my building? For my undergraduate university in the United States, they advised that I call my resident assistant or submit a link online maintenance form. Now that I am in graduate school in France, I live in a private student residence where I tell the reception of any issues in my building. Additionally, I went to university subreddits and looked up "maintenance request" to read more about student opinions and experiences.

I also did some research on how other schools took care of facility issues, noting the commonalities and also the pros & cons I found. I quickly realized that the majority of universities have some sort of variation of a maintenance request form, whether online or by paper. This made me correlate this to ticketing systems, which is how IT help desks usually manage their work; therefore, I also looked into features of ticketing systems as well. 

Writing down some key points and thoughts - sloppy, but no need to be neat

Problem breakdown

Before jumping to solutions, I wanted to figure out what was the main issue for current building management systems. 

The main goal is to give an efficient and effective experience when it comes to reporting a maintenance or equipment issue. I found that most, if not all, universities relied on a phone number or online maintenance request form on their website for students to submit.

The most significant issue I found was wait time. It's a common trend where students would wait for long periods of time for their issue to be reported to (or not at all), whereas requests tended to get backlogged for facility management staff.

From a student's point of view, it's easy to blame the facility management staff and say "they're not doing their job" or "they're being lazy". However, I figure there has to be more to the issue than that because I found that it was a common problem among universities in general.

So how does a system for building issues get such long wait times?According to my research, I found the following underlying issues:

  • "First-come, first-serve" priority: For many universities, if the request is not urgent enough to call 911 or a resident assistant, everyone's requests are put into one queue. If there is a broken window, it will be put in the same line as someone who requests a new lightbulb. 
  • Lack of updates: After contacting maintenance or filling out a request form, there tends to be no sort of feedback or updates of the form besides the fact that it has been sent to building management. Students found it frustrating that they don't know the progress on if it is being worked on or not, and can lead to duplicate requests sent by the student - which in turn, messes with the queue for facility workers.
  • Bystander effect: Based on personal experience, the bystander effect was certainly apparent for common areas. For example, when there is an issue in my communal kitchen or study room, everyone always assumes someone else has already reported it, prolonging the time it is actually brought to someone's attention. 

The Challenge 🤔

How do you design a platform for building maintenance requests that decreases the wait time for students and streamline requests for facility workers?

Defining the goal

Keeping these things in mind, I decided on the following goal: Create a building management system of efficiency, transparency, and accountability to make reporting issues easy.

To reach this goal, there are certain factors that have to be achieved in the user interface:

  • Improve ticket priotization based on severity of request
  • Highlight communication so that all parties of an issue know what is going on at all times
  • Provide a visual, easy, and intuitive experience

Sketching out the concept

Before drawing anything, I had to think about what kind of platform I would be designing for. Since maintenance issues are spontaneous and might need immediate attention, I decided to go with a mobile application approach because mobile phones are typically on hand by most people nowadays. For students, I would imagine this to be either part of a mobile application that is already associated with the university or a mobile web application. Although sending requests through phone is convenient and immediate, people would not keep or download a mobile application solely for facility requests.

On the other hand, maintenance staff are usually moving a lot around campus and can certainly benefit from using an app on their phone to maintain requests.

Based on the needed features and research, I was able to piece together a user flow from a student's perspective. Because the common basis for a maintenance request is a form, I wanted to make it a smooth experience that transmits as much useful information as possible to maintenance staff. Allowing students to go through a self service portal can streamline the request creation process and eliminate unnecessary emails/phone calls between parties.

Sketching out the view from a student's point of view

I also drew out a user flow for a maintenance staff member's side of the application, in which I envision it as a dashboard of requests. My main focus for this flow was to emphasize organization and a clear overview in a task management system, allowing for more to be accomplished by the facility staff. I think it was extremely important to consider how a facility member would see the information that the student put in because it helped me include things that could be useful for a staff member to expedite the request process. Regardless of who was using the platform, I wanted to make it as personal and simple as possible.

Sketching out the view from a maintenance staff's point of view


I did a few more changes on paper before moving over to Figma so that I could make easier edits and make a more clear user flow. 

This was the final result of the user flow after a couple of iterations:

Wireframes (1)

Although a form is the best way to transmit what is needed from both parties, I included other options of communication for a student because it is important to allow conversations to flow seamlessly across all channels, which means more productive work and more satisfied requests. By letting students to personally get in touch with the person assigned to their request through message or phone calls, it reassures the student that their request is actually being acknowledged. For instance, how many times have you submitted a contact form with a page that says "Your form has been submitted" and the communication abruptly stops there?

Even more so, including push notifications and progress trackers enforces that their request is being tended to in real time - not something that has been lost among the other requests.  With these considerations in mind, the goal of highlighting communication so that all parties of an issue know what is going on at all times can be accomplished. 

Login, Home, and Menu

First Screens

The login flow is pretty standard, but something that should be noted is that the login screen should be an account associated with the university. By having this app connected to a university account, it helps autofill out information later in the process so that students can save time from filling out information the university already has records of, such as their phone number or their full name. As a matter of fact, it also helps to avoid anonymously sent requests that could potentially happen if the app was associated with its own private login. Logging in with a university account lets staff know that if a person happens to be sending spam requests or is causing troubles, it can directly be routed back to who that person is. 

After logging in, a home screen is shown with an overview of all the request history along with the latest request at the top. Making their latest request prominent lets students know the status at a quick glance.

In the menu, it has all the basic functions that this experience has to offer along with a contact us page. I included other services that aren't exactly solely for maintenance, but related to equipment and building issues since it is relevant. As I mentioned before, I felt it was important to include other contact information that cannot be found solely through a form, such as office addresses, phone numbers, and times of work hours available. 

Submitting a New Request

This part of the user flow is the most important bulk part of the process - now, there's a lot going on here, so it is best to dissect it.


Submitting a new request of the user flow is the most important bulk part of the process - now, there's a lot going on here and so it's best to dissect it.

One goal was to improve prioritization based on severity of request. I found that a lot of university facility forms were available didn't have anywhere to rate the urgency, which leads to all issues to be placed in the same queue in order of the time they were submitted. By allowing the user to tag their urgency, it helps facility set their priorities on which requests are time-sensitive and need response immediately. 

The extent of what universities did to emphasize prioritization of requests is that if there is an emergency, they advise on their facility website to call a certain number or emergency services. I decided to include a pop-up dialog to cater to this need and let students know that if it is truly an emergency that they should call someone immediately. 

Request Details


After selecting the level of urgency, the user is led to the request details page which is all the information of where the incident occured. This page is what most facility request forms offered by university consists of and generally includes the location of a request or issue and a description. Separating the location by campus, building, and room helps staff know how to assign tasks based on where requests are precisely located. However, I made some tweaks to help facility know the request a little bit better:

  • "Summarize your request in a few words": This field is to help facility know at a glance the subject of the issue. From the staff's end, they could quickly assign roles (such as if a request is to be for electricity, water, etc.) based on the subject line. If possible, automation can be done by grabbing words from the summary/description to assign workers to these tasks.
  • Camera: Going further than a description, I thought it would be useful to have the student have an option to upload a photo or video of the issue. In the third screen of the photo above, you can see that there is a pencil icon in the corner. This allows the user annotate and draw on the recorded photo or video to specifically point out something in the request. After all, a picture can be worth a thousand words.

Avoiding Duplicate Requests

Avoiding Duplicates

After clicking next, there may be a screen that asks if a similar request has been made. Sometimes, an issue may happen in a common area or multiple people are having the same situation for the request. In my experience, students tend to fail to report issues in a shared space because people assume that someone else has reported it. By having the app catch similarities in location and keywords in request summary, this would really help with letting students know if they are the first to report the issue. If there is a similar request, the application stops the process there to avoid wasting the student's time to fill out a duplicate request and also to avoid having duplicate requests in the backlog for staff members. This saves staff members from taking the time to delete duplicate requests.

Request Submission

Submitting a New Request

Here is the following basic process of the request submission. After filling out the request details, the user is led to a contact information page. Since I intend for this application to be connected to a university account, the contact information page should be automatically filled out and save time from the student. This page is simply to confirm details and allow the student to edit their information if the phone number and email is not their most actively used one.

After submitting, they are led to a "Thank you" confirmation page. Having a link to the "Contact Us" page is significant because sometimes, people may get confused or frustated with this experience. Even after taking care of errors that may occur, it's fair to assume that some users will still face problems. Therefore, it's crucial to provide students direct assistance with real people on staf and adds credibility to the request at hand.

Request Details

Request Details

Lastly, the request details page acts as a summary of the request. On the top, it has a progress bar which is a key feature in this application. This progress bar ensures students that their request is being looked into and to manage their expectations.

Additionally, allowing for status updates through push notifications lets the user be aware of progress without having to open the portal. It can be especially beneficial to know updates of a request without having to constantly check.

There is also an option to message the staff member who has been assigned to the request. In case there are any further inquiries or changes, a staff member and student can know immedietaly. Again, this feature stresses the importance of engagement between students and staff members and promotes human connection.

Overall, I made a conscious effort to achieve the goal of providing an easy and intuitive experience. Not everyone loves to fill forms and especially when it is because of a facility issue or equipment request, but most won't mind filling one out as long as it is clear and w

Sure, very few people actually love forms. But most won’t mind filling one out as long as it’s clear, concise, and well-designed. I could have made this experience more extravagant and added extra things, but the point of this is to avoid students from filling out a long and tedious form when they simply just want their request fulfilled.

High Fidelity

Throughout this whole process, I finalized the high fidelity screens and brought color into the picture. I used Google's own Material Design standards to bring this facilities management portal to life.


Future Implications

Although I focused on a student's perspective, I mentioned bits and pieces on how this design would benefit the staff members as well. As previously mentioned, I chose designing for a mobile app because I'm sure that it is convenient device for employees who are traveling all around campus to have. I envision the app to follow the design of a dashboard with a ticket management system in place based on what students have submitted. I would also suggest implementing integration with calendar apps on a staff member's phone in conjunction with this facility request app so that all their issues are in one place.

Because this is a higher education institution, this should also follow standard accessibility rules since it should be a priority in any university platform.

To conclude, by clearly communicating information on a simple and easy to use interface, it simplifies the experience. What could be a major headache and simply tedious could be something quick that can be done in minutes - and that is what makes all the difference.

Made withand 💗 by Beatrice Trinidad in 48.8566° N, 2.3522° E

Made with ☕ and 💗

By Beatrice Trinidad at

N 40° 30.0864, W 74° 26.8345' 

Made with ☕ and 💗

By Beatrice Trinidad at

48.8566° N, 2.3522° E