Looks like your browser size is too small to view this page! Please switch to a desktop view to continue. 💻
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
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Hope you enjoyed following along on this journey. I appreciate you taking the time to check out my work ☺️