Oops. 😬

Looks like your browser size is too small to view this page! Please switch to a desktop view to continue. 💻

Streamlining maintenance requests across a college campus.

Maintenance requests are less than ideal for all parties involved. The system lacks transparency, is overly complex, and actively makes users' lives more difficult. My design aims to address pain points for the entire life cycle of this process, and improve the experience of submitting requests overall.


My submission for the Google Design Challenge, created over the span of seven days. During this time I conducted user research and created three different user-facing platforms


Rapid prototyping
Visual design
User research
Competitive analysis


What does the existing process look like?

Students at Rice University currently have three options for reporting maintenance issues: submitting an online work order form via the university housing website, emailing maintenance directly, or calling the maintenance office.

Submitting a maintenance request is often an unpleasant experience. It’s highly likely that the user who is submitting this request was inconvenienced enough by the issue that they decided to take action. So it’s doubly important to ensure that this experience is an easy and efficient one for the user, such that the process alleviates stress and frustration rather than adding to it. I also remember hearing repeatedly during my time at Rice about the lack of transparency during the process of submitting a maintenance request — after submitting the request, a student waits uninformed and in the dark about the progress of their request.

Submitting a maintenance request is often an unpleasant experience. It’s highly likely that the user who is submitting this request was inconvenienced enough by the issue that they decided to take action. So it’s doubly important to ensure that this experience is an easy and efficient one for the user, such that the process alleviates stress and frustration rather than adding to it.

After a brief look at the existing system, I already identified several usability and design issues. Aside from looking like it was designed in the early 2000s, the terminology was vague and the layout and lack of hierarchy makes it a confusing form to fill out.


Break down the barrier between students and maintenance staff and provide more transparency throughout the work order process?


Understanding this process from different perspectives

To help me more clearly define the tasks this interface should support, I decided to conduct some user interviews to get a more holistic view of the problem. Guiding the creation of my interview script were a few burning questions I had:


  • How are requests prioritized for maintenance staff?
  • What are potential barriers that might keep someone from submitting a request?
  • What frustrations arise on either end of the process?
  • How can this interface make the maintenance staff’s job easier?
  • Should this platform be mobile or web based?

Insights from the reporting side

Of the five users I interviewed, I separated them into two user groups: users who report issues and put in maintenance requests, and users that receive these requests and complete the work.

I also took the opportunity to seek out an additional user in a different work role on the reporting side: the department administrator of the architecture school. Department administrators are responsible for submitting maintenance requests for an entire building, and interact with maintenance workers regularly, so they bring a new perspective to the table by understanding both ends of the process.


  • Lack of transparency and trust in the process.
    Users are not informed of the timeline of the job, so there is a mismatch between the user’s expectation of when the work will be completed and when it actually gets done.
  • Procrastinating submitting work orders
    Other than the SMR, the other two users mentioned that they would put off submitting issues that aren’t pressing until later, because the submission process is time-consuming.
  • Confusion with the terminology.
    The categories under which certain maintenance issues fall are presented unintuitively, causing users to have to search through long dropdown lists to find their specific issue.
  • Dehumanization of the process.
    Frustration about the timeline of the job is often due to a lack of empathy for workers. Users sometimes need to be reminded that there is an actual human behind this process.


“Sometimes, I’m not sure if it [a work order] is done...the way issues fit under the categories is kind of unintuitive.”

Insights from the receiving end

With this project, my biggest knowledge gaps lay in the processes of receiving and taking action on the maintenance requests, so these interviews were key in helping me understand this part of the work request process. During these interviews, I uncovered a new user role — the supervisor. Supervisors assign maintenance requests to the workers on their team, and also determine the priority of the task. I felt it was important to include this  user because of the important role they play, bridging the gap between the initial submitted request and the maintenance work itself.


  • Assigning priority to work orders.
    Maintenance requests are prioritized on a scale of 1 to 4 —
    1: Emergency, 2: High, 3: Medium, 4: Low. This scale determines the time frame in which a job must be completed.
  • The amount of work is sometimes overwhelming.
    Workers often encounter task overload, especially on days when they are assigned multiple level 1s and 2s in addition to having their regular level 3s and 4s.
  • Prioritization is not reflected in the job queue display.
    The existing system does not display each worker’s assigned work orders in order of priority, so they have to search through the job queue to determine what to do first.
  • Lack of support for supervisors.
    An actual person is responsible for assigning priority and workers to a work request. Supervisors are often flooded with many requests that they must ensure get completed.

So...mobile or desktop?

This was a big internal debate I had been trying to settle since I first read the design brief. The current system employed at Rice University for reporting maintenance issues is web-based, but on the receiving end, both web and mobile interfaces are employed. The participants on the reporting end of the process preferred a mobile interface for it’s convenience and flexibility, as did the maintenance worker, who mentioned that it was helpful to be able to check tasks on-the-go.

However, the maintenance worker mentioned that many of the older workers preferred the web-based interface, due to their difficulties learning the new mobile interface. Persons C and E also recognized that mobile would be more portable and useful for maintenance workers, but said that a web interface would be useful for those with desk jobs like themselves. Ultimately, I decided to create a mobile interface, but a corresponding webpage would be a beneficial integration into the product ecosystem as well.


Defining goals and features

  • Transparency. Increase transparency and communication on work progress and timelines to foster trust between users.
  • Awareness. Encourage students to submit work requests more frequently so issues can be detected earlier on.
  • Efficiency. Streamline the process of receiving and acting on work order to reduce stress for facilities staff.
  • Learnability. Be easy to learn and understand to accommodate the wide range of users with different backgrounds.

In order to understand what features to include in my design, I created a list of key tasks based on the research conducted. To further explore these tasks in the context of one another and the dependencies between tasks, I created a usage scenario timeline to visualize how Reparo could be of use at different points in the process.

Guided by the scenario timeline and user tasks, I created some rough sketches of ideas, thinking through the high-level flows and what elements should appear on each screen, as well as the overall user flow. Since a lot of the supervisor and worker interfaces rely on the effective and clear communication of information, it was helpful to visually represent my different ideas so that I could evaluate them easily.


Three different user flows for the three distinct roles

It became clear that Reparo would need three different access points that accommodated the three different user groups: students/staff submitting requests, supervisors who assign jobs to workers, and maintenance workers who complete the job.

Creating a seamless and effortless process for reporting issues

The main goal I had for the student/staff reporting interface was to streamline the process of submitting a maintenance request. To do this, I separated the submission process into two categories: submitting a repair tip and submitting a work request. The work request process requires a greater amount of detail, and would be used in scenarios with issues directly affecting building users.

To encourage students to submit more requests around campus and alert maintenance staff of issues that require their attention, as per the design brief, I modeled the repair tip submission after the ’Add a report’ feature on Google Maps. Currently, issues can be spotted by students going about their regular day, but they are deterred from responding because of the effort required to fill out a complete maintenance request while on-the-go.

Helping supervisors more effectively assign tasks

Supervisors can choose to assign a worker to a task either through the task details page or through the assigned task overview. One of the big pain points I identified during my user research was that maintenance workers often get overwhelmed by requests. Clearly showing each worker’s schedule and their assigned tasks can help supervisors more evenly distribute work orders between the workers.

Since each supervisor’s first step when receiving a work order is to assign the priority level, this was an important task to address. To make their decision, supervisors must first read all the details about a task to decide on the level of priority to assign. I wanted to reduce the friction in this process by making priority assignment as quick and easy as possible.

Helping supervisors more effectively assign tasks

In order to promote transparency about work orders, I felt it was important to create a quick and easy way for the maintenance workers to update the progress of the job they are working on. Since this is a mobile application, workers can easily update their progress while on the job site.

A feature that I really wanted to include was the ability to receive compliments from students/staff reporting the issue. Since the Rice is a relatively small school, the community is tight-knit and there is a strong tradition of giving thanks to facilities and maintenance staff. I felt that having a compliments section would also help to motivate workers and create a connection between them and the people they are helping through their work, and hopefully brighten up their day with a personal touch.

On the flip side, this also really helps to remind students that there are real humans working to solve their maintenance issues on campus, and can help to humanize the maintenance process.


Utilizing a tried and true design system to bring Reparo to life

I chose to use Google Material Design to transform my mockups into high-fidelity prototypes, since time constraints meant I didn't have time to create an entire design system. Reparo combines existing Google design patterns with new components I designed to accommodate unique features such as assigning priority levels and viewing maintenance workers' tasks for the week.

Distinctions between submitting a work order and a repair tip

In order to avoid confusion over the two methods of submitting maintenance requests, I tried to make the visual elements and interaction sequences as dissimilar as possible. I chose the button for the work order as that felt like a more formal action, whereas a swipe up for the repair tip is more nonchalant.

Using color to signal priority level

Color is important throughout this design, as it codes the priority of a task. The associations with urgency are familiar due to social cues. To differentiate the progress status, I used a different color palette to indicate various stages of the process, and placed it on the opposite side of the screen.

Reducing maintenance workers' cognitive load

Maintenance workers are able to view their daily work orders in a clean, decluttered space that includes important summarizing information. The tasks are organized similarly to a daily to-do list, which feels familiar and manageable. Most of the interaction patterns for the maintenance worker interfaces are also tried and tested by Google. I wanted to keep the interactions simple so that workers who are older or have less experience with technology can easily learn the application.



I really enjoyed working on this design challenge because the problem space is one that hasn’t really been explored, and the solutions for it are (generally) quite horrendous. As usual, talking to users was insanely eye-opening, and I only wish I could have talked to more people. Just through the interviews, I discovered a whole other user group that I had previously assumed was a role occupied by an algorithm — who knew an actual person had to sort through all these orders and assign them?

While as a designer, I never feel like my product is completely done, I’m pretty happy with where I ended up. I do wish that I could implement this product at Rice for real, my interviews showed me that the process that currently exists is far from perfect. Maintenance workers really are the unsung heroes of college campuses.

Looking forward 💫


Ideally, I would have been able to do this before developing the high-fidelity screens. I had planned to do some testing, but ended up not having enough time (classic, right?). I did run through the flows with a student and a professor with experience managing people, and those alone led to several improvements (most notably the overhaul of the supervisor’s ‘Overview’ page).

There were a lot of things I wanted to validate, like the compliment system and what should go on the supervisor’s overview, and there were still so many questions I had that went unanswered. I had to make a lot of assumptions, but hopefully most of them seem logical. So, if I were to continue this project, the first thing I would do is test the product on some users!


This would mostly be for the supervisor side of things, since I felt that the students/staff and maintenance workers had comparitively few tasks that all worked well on a mobile platform. However, since supervisors usually sit at a desk to work, having a desktop integration would likely be helpful in situations with high volumes of work orders.

It was an interesting challenge to fit a dashboard-like interface onto a single screen, and I took a lot of design cues from Robinhood. I would have liked to talk to a supervisor  (unfortunately I wasn’t able to find one) to better understand what kinds of elements would have been useful to getting an overview of the work being done.


Thanks for making it down here!

Hope you enjoyed following along on this journey. I appreciate you taking the time to check out my work ☺️

Don't be a stranger.

Back to top