I completed a week-long design exercise to better understand how people seek to resolve repairs/maintenance concerns, and what might be the best way to implement a solution like this based on the constraints of my local campus facilities team.


UX Designer and Researcher


iPad Pro (Notability), Figma


Individual project


A design exercise for an interview process, with a time constraint of 1 week


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.

define the problem—

There wasn’t a lot of room in the prompt to re-establish the scope of work, but I pursued some “how might we…” questions just to get a better grasp on the limits I was working within. Overall, we want to improve the upkeep of campus facilities… but why? By continuously asking why for the primary “how might we” question, I explored defining the scope of the problem—who else is impacted by this solution? Is anyone else dealing with similar issues, and how can we scale and expand our impact?

Put simply, the problem was handed to me, but not the goal. I set out to establish a sense of purpose for this project.

Establishing context—

As I began, I had some initial questions: 

  • What is the process like for students today?
  • What's the process like for similar industries?
  • How do the experiences of the students and facility staff impact each other?

In working through the design problem, I began gathering data about the subject and complementary factors to help myself understand the context I’m working within. As I navigated the process and devised methods for understanding missing links, I ended up utilizing a few different research methods:


Understand what already exists, what’s effective or ineffective about their process

user research

I used methods like Guided Tours and both Group and Individual Interviews to better understand the experiences of students and facility stafff directional arrows to provide wayfinding

error analysis

Anticipate what can go wrong to create a more comprehensive, developed solution with scalability


I started by evaluating our school’s current system for sending repair requests, and I also looked at some similar environments where people report problems, like apps for reporting city issues (vandalism, potholes, etc.), and applications for submitting property repairs (apartments, for example).

In my competitive product analysis, I noticed that some city apps had developed a system that would allow you to report various types of issues (not just the usual vandalism/pothole reports). This encouraged me to consider the various applications that a product like this could have, and that it doesn’t have to only help improve the upkeep at campus facilities. What if it could improve the upkeep of cities, rental properties, community buildings, etc.?

Impromptu group interviews

Rather than creating a new product from scratch, my goal was to assess an existing process and design a new way of navigating it.

Instead of recruiting for and scheduling interviews (due to time constraints), I put together an impromptu focus group based on some students I found that were already gathered. I was interested in fostering a broader discussion amongst the group as they heard and responded to each others’ answers.

I asked them to consider the past few days or weeks on campus. Did you come across anything broken or unusable on campus? Was it an object, or a part of a facility? I asked them to tell me about their experiences and what that interaction looked like.

user journey maps

I then began thinking through the journeys of both users—the facility staff and the students—to better understand their obstacles and what else could go wrong in their current path, compared to the “ideal” path.

After interviewing both the students and facility staff, I found that students generally struggled to understand the process of reporting issues, and facility staff were spending a significant amount of time dealing with the consequences of that confusion. It’s important to understand both journeys as part of one process to better analyze the impact of each pain point, so I integrated insights from both users into one map to better understand their impact on each other.

The red highlighted areas indicate opportunity points, as derived from discussions with the Care Team (facility staff) and students.

key user insights

Students don't know what the process is for reporting issues. Often, they don’t try to report issues, or they call the phones which ties up resources/staff.
The Care Team spends a lot of time communicating. They’re frequently following up to get more info, answering questions about the status of projects, and handling duplicate requests.


In beginning the ideation phase, I evaluated the key insights from my user research and how that translated to design goals that can be implemented and measured.

error analysis

Before really diving into ideation, I began to implement error analysis, to make sure that I’d considered the impact of various features and how they relate to each other. What could go wrong and how can we get ahead of it? This also helped me understand the various pitfalls of my design, as I aimed to devise something adaptable—something that could be replicated across various industries for a similar use case.

Beyond the initial brainstorming session, error analysis was utilized at every step of the process. It’s less of a research method than it is a mindset to adopt while prototyping.

I realized that there were certain design objectives I needed to meet in order to make this product scale-able and able to cross multiple industries. On a smaller scale, I had objectives to meet to also resolve the pain points of the student’s approach to submitting concerns and that of the facility staff’s intake process.

The design should be familiar

Because you don’t have time to learn how to use it, or to be taught how to use it.

- The easier it is to report something quickly, the less likely users are going to seek other forms of communication via phone call/email.

- The facilities admin expressed a need to cut down on time spent on phone calls.

The design should be smart

Because you need to increase the efficiency of your staff. With apps that are smart enough to analyze the data, you can remove staff from tasks that can be automated, and focus their efforts on the tasks that require a human—such as customer service, client management, prioritization of projects, etc.

- The design must be recognizable and familiar to the users’ standard toolkit so that it’s easy to access/learn.

- Comprehensive reports can reduce the time facility staff spend on follow-ups.

The design should be adaptable

Because it should be relevant and usable for various clientele.

The goal is for the data to be organized simply enough that the same structure can be applied to similar use cases in other industries. While the direct need is of the students and facility staff, there is a broader market we can appeal to which can help justify the value in producing such a product.

- To clear up confusion, the app should welcome all sorts of inquiries related to campus upkeep. Facility staff noted that they get various inquiries beyond maintenance/repairs.

- The app should be open to interpretation. This can be introduced with customizable tags or categories, for example, based on the application (school, city, property management, etc.)

The strategy is that the simpler the concept, the wider the application…

If we’re spending the time to develop this, how can we maximize the market that we can appeal to?

usability testing + iterative prototyping—

In the interest of making a high-quality interaction (as opposed to a larger set of interactions at a lower quality), I constrained the scope to focus on two primary aspects—the process of the student reporting an issue, and the ability to access and track past reports. This scope will address the features that contribute most to the facility staff’s workload, and also serves to clarify what was unclear for students unfamiliar with the process. I tested each version of the screens with at least 1 or 2 participants so that I could continuously revise the set based on user feedback.

mid-fidelity prototypes

revisions based on mid-fidelity feedback

Through testing the the mid-fidelity prototypes, I learned that multiple pages slowed the user down, and that the report content wasn't particularly useful. 

I also learned that the notifications weren't a part of the app that users felt they'd use. However, I kept this component and hid it in a hamburger menu, as I believed it to provide impact on the facilities team's needs, even if students or similar users didn't use it a ton.

final design—

The final design relies on utilizing existing Google products, like Maps and Lens, and AI technology to sort and process student report data efficiently.

Since available funding for projects like this is very minimal, it was important to me to explore how existing Google products could contribute to a low-cost solution that could be applied to various different markets.

To summarize the interaction flow, this final solution aims to:

  • Reduce the learning curve of understanding how to submit reports for students
  • Increase the amount of information relayed to facility staff to reduce time spent on follow-up
  • Streamline and increase efficiency in how reports are translated through reducing duplicate reports on the initial Maps view, AI keyword recognition and auto-tagging with Google Lens
  • Bring awareness to what’s new with UW Facilities to prevent extraneous communication of frequently asked questions or common concerns
  • Maintain adaptability to be scale-able from the university campus to as large as a city-scale reporting service

pin your location, or view existing issues

Reports can be made by pinning an area on the map, or viewing any existing reports at your location. This prevents duplicate reports, and helps orient the user to issues that may be on their route for the day.

find more info on reports

When viewing reports, you can see both those that you've submitted and those that others have submitted. The reports can update you on the status of your submission, thereby decreasing the number of phone calls the Care Team receives and keeping users more informed on what the facilities teams does for us.

use google lens to expedite photo examination

Google Lens' ability to detect content in photos can help Care Team staff identify the elements of concern in photos submitted by users. This also helps students that may be unfamiliar with terminology, or have language barriers.

stay updated on maintenance concerns

When more urgent matters arise, as many maintenance concerns can be, you'll be the first to know through notifications on the app. This can help prevent additional issues caused by people interacting with faulty equipment or building facilities.


strategic planning of methods > research for the sake of research

Since this was the second design challenge I'd done this month, I found myself trying to be much more intentional with my use of research methods and time spent understanding the scope of work and the defined problem. It was interesting seeing the results from strategizing about my approach rather than just diving into research just for the sake of research. I’d love to do more work with this more holistic understanding of product design—combining the UX design and research, and how it’s impacted by business goals.

how would we measure the effectiveness of this solution?

By implementing the final design, we could test the effectiveness based on how much of the workload is reduced from the facility staff by tracking the variance in the time it takes them to sort through the new “tagged reports” compared to processing older submissions/phone calls from students. This could also indicate less frustration for students, if they reported fewer questions/complaints or reporting through atypical channels.

if i had more time...

If I had the opportunity to develop a prototyping plan, I’d love to observe the effect of this new design on the Care Team to further explore how we can make incoming data easier to digest for facility staff without complicating the process for students when the solution is implemented in real-life.

I’d also have liked to explore the concepts introduced by the facility admin with a wider pool of users. In my last iteration set, I met with the facility admin again and review any issues he might anticipate within my mid-fidelity design.

He had very specific ideas for what he believed would work, so I implemented some new ideas (see below). However, I ran into issues when testing this concept with users. Users expressed misunderstanding of the terminology, so I had to nix the idea based on time constraints. However, it’s important to note that I tested this in a very limited pool of participants, so I’d like to review this with a more diverse pool to really dig deeper into the misunderstandings and limitations of this alternate reporting format. I think it needs to be tested in a more formal structure so that we can thoughtfully evaluate how to improve this design scheme.


Click on the link above to check out the first project I ever worked on in my UX career, where I explored how someone might increase personal safety for individuals of various backgrounds. While it's one of the most redundant student projects, it's also one that still hasn't been solved.