Easy Community Issue Reporting App


A great residential community (e.g. condominium, college dormitory, etc.) provides a variety of amenities and a dedicated staff responsible for its maintenance. But there isn’t always an easy way for community members to report problems to management so they can be fixed resolved quickly. Design a system for a community of your choice, so members can report issues and track their resolutions



A mobile app that not only allows users to get their issues resolved in a timely manner but also helps them establish meaningful relationships with the invisible workforces in the community.


Target community: CMU campus dormitory 

Target user group: Freshman (1. They are required to participate in campus housing; 2. They will continue to be users of the app after they become Sophomores, Juniors, etc.)


More specifically, my solution aims at achieving these 3 goals:

  1. Incentivize users in community issue reporting 

    • Provide them a stable point of contact that is always there

    • Direct & transparent communication

    • Reward them for their efforts 

  2. Improve the student-staff relationship in dorms

    • Custodians and technicians should be recognized for their work 

  3. Foster student's sense of ownership over their community, making them more responsible for the shared living space



Prototype Walkthrough 


Experience the high-fidelity prototype yourself on invision.com through the link on the left.

Or you can scroll all the way to the bottom of this page to try an embedded version.




Phase 01:

User Interview 

There are many types of residential communities out there in the world, thus before I even touch any of the design parts, I want to first find out if I can identify a specific community that an easy issue reporting solution would bring the most value.  


I interviewed 3 students each with experiences living in both college dormitory and apartments. Through these interviews, I aimed to find out answers to these 3 key questions:


  1. What kind of issue do they report?

  2. What incentive motivates them in reporting community issues?

  3. What do they expect from the service team in return? 

"I did not know where to get the building maintenance people to help me at all when I lived in a dorm. But when I moved into my apartment, my leasing company was really clear about who I could email or how I can get them involved if something breaks down."

"It would be nice to know when the problem will be fixed though, cuz I'm constantly out during the day at school or somewhere else. I don't want to come back home, say, with the light still broken."

"I trusted the maintenance people (apartment) so it didn't matter to me if I would physically be there when they come to fix the problem."

"The only person I knew I could ask was my RAs (resident assistant) but I was like that introvert who tried to avoid talking to my RAs. I just felt awkward talking to them, so I never asked them for favor unless something is seriously wrong."

Interview synthesis:

  1. People have different mental models for apartment vs. school dormitory. They consider a dorm as more of a public space while considering an apartment a private space. 

  2. Students possess a greater sense of ownership over apartments.

  3. People are more motivated to report problems when for their apartments in comparison to dorms. 

  4. Students are very lost when it comes to identifying a point of contact for maintenance service.

  5. People tend to rely on others in issue reporting in dorms. --> "Someone else will do it."

  6. People cared greatly about whether their problems.

  7. They also care about when the fix will be done if the issue is urgent. 

* Scoping Decision #1 *

The preliminary interviews helped me in determining which community that I want to work with. 

Based on the findings above, it was clear that a better community issue reporting solution is in greater need for college dormitory.

Phase 02:


Before diving into more secondary research, I first did a coup rounds of brainstorming by myself to come up with some questions and initial ideas that can later be addressed. Being self-referential is usually not a bad place to start especially when the problem is broad. 

Phase 03:

User Journey Map - Current

Based on the recollections on community issue reporting that I collected from the first round of user interviews, I was able to gain a big picture of what did that process look like to each of the interviewees and how did they feel at different stages of that process. To fill in some details, I role-played as a dorm resident who wants to report an issue by going through the housing service website. 


Putting together these two pieces, I created a generalizable user journey map with respect to student's experiences over community issue reporting in CMU dorms.

Phase 04:

Service Provider Goals

To better understand the problem space from the service provider's perspective (which includes the school housing service, custodian and technicians on call, and dedicated resident assistant in my case), I reviewed many online artifacts including residence hall job responsibilities [1, 2, 3], research on custodian-student relationship that leads to students success, campus news from other colleges reporting on related topics [1, 2, 3, 4], etc.


Then, to create a consolidate the goals shared by the service providers specifically in CMU dorms, I created a goal map based on information found directly on the CMU Housing & Residential Education website.

* Scoping Decision #2 *

I decided that a light-weight mobile app will be the best platform to carry out the service. I learned that according to recent research, most people do own smartphones and that is the case for custodians too. Thus with an app, we can take advantage of its mobility and accessibility thus making sure everyone using this service are always in sync.


For instance, if a problem is already reported by a student then the rest need to have a way of knowing that right away. By doing so we can effectively allocate resources and not waste time on guessing if an issue is already been taken care of or not.

Seeing so much emphasis on education and personal growth is pretty amazing. I also believe that understanding one's responsibility as a member of a social entity is extremely important. Thus I decided to focus on a specific user segment: CMU first-year college dormitory residents who are still in the process of transitioning into a new shared living style. They want a better way to report problems just as anyone else living in the dorm. Moreover, they are still in the beginning stage of learning to how to behave as a responsible person.

Design Goals

Keeping all the research findings in mind, I identified 3 goals that I want to achieve with my design.



  1. Incentivize users in community issue reporting 

    • Provide them a stable point of contact that is always there

    • Direct & transparent communication

    • Reward them for their efforts 

  2. Improve the student-staff relationship in dorms

    • Custodians and technicians should be recognized for their work 

  3. Foster student's sense of ownership over their community, making them more responsible for the shared living space




Based on the goals that I want to achieve with this app, I created a persona called Susan to help me focus on the design details.

Susan Lee

"I want to make an impact on the community through my experience here."

Susan is a CMU freshman studying Physics. She lives in Stever House, a freshman-only dormitory located on campus, and is super excited to start her new life here. Susan is a self-motivated and caring person. She is always conscious of what is happening around her and is willing to offer help when needed. Although there are still many things that she is still getting used to, she is ready to take on the challenge. 


– Want to contribute to the community

– Have a comfortable living experience 

– Want to create meaningful relationships

– Want to succeed in college life 



– New to everything and everyone on campus

– Have a hard time navigating through the campus 

– Seek connection to campus resources

Storyboards & Speed Dating 

I created a series of storyboards demonstrating different features and use cases for the app. Through this process, I want to understand what is their intention in using an app like this. What would motivate them to use it more often and what will turn them away. 

Storyboard #1

"Yeah, I think this is totally valid. It seems simple enough that I will probably actually use it. I also like how it is smart enough to know where my room is."

"This might be out of scope but just curious, what if I am reporting while having a sleep over at my friend's dorm?"

Storyboard #2

"I don't know if I want to get update on every steps in the process ... I think saying thank you is a great feature to have. But I probably don't want to type a  new note every time."

"Progress tracking is always good to have."

Storyboard #3

"I would probably only care if the issue would effect me personally."

"I wonder if I would still get notified if I'm on spring break or something. But I can think of cases when it would be good to know what's happening in the dorm remotely."

Storyboard #4

"I think suggestion will be very helpful especially if I am not super familiar with the campus yet."

"I don't like have a rank for student contribution. If I report a problem it's not because I want to be recognized by my classmates, and I really don't want to see myself on there. But I think it's nice to recognize the hard-work from our staffs."


With the feedback I got from speed-dating in mind, I started to map out screens.

I intended to use these frames as a way to quickly transfer scattered ideas from my mind onto paper. Thus it was meant to only map out the very high-level contents and how screens connect to each other. I also intend to use these to figure out the general layout of the app.


*Note that I took out the ranking/honor board feature as it was perceived very negatively in one of the speed dating session, and was perceived dispensable in the other.



I moved directly into Mid-fi screens because I personally work the best when I have real phrases, icons, buttons that I want to put into my design. Thus, for me low-fi is still a little too abstract for me especially given a very tight time frame for this specific design. 


I thought I was really clear about the goal that I want to achieve with this app, and that helped me a lot in making decisions on the fly as I was putting together the mid-fis.  I even made a few major changes to the app because the original design that I was going to implement was creaming to me that something is not right. So I just let myself fully immersed in the role of a  pick user and try to break the logic behind these design as I was creating the following screens..


As an example, I originally imaged to have one central place, similar to how Instagram handles feed, where all requests can be viewed by everyone that owns an account. That problem did not even jump out in dating, but when I started to put things together, I couldn't help asking myself: "But why would I need to know if someone's light bulb broke in the middle of the night?" Only after that, the idea of separating private space maintenance need and public maintenance jumps out at me.​

Evaluative User Testing

I was lucky to find a friend who is willing to spend 45min walking through screens I have already made during spring break. As a result, my mid-fis are heavily annotated with good insights. After the session, I dived right back into iterating these screens to prepare for the hi-fi prototype.


1. Users should have full control over whether or not to receive updates on any specific request. 

  • What if: One doesn't care about everything that is marked urgent but just one of them.

  • What if: One reported something just for the benefit of the community (ex. a broken printer that one does not need to use) and thus he does not necessarily care when the issue is solved. 
    • In this case, the user should be able to choose mute notification even on an incident that he reported himself.


2. Eliminate false positives (inaccurate report either intentional or unintentional).

  • Student ID integration

  • H  ave a real person approving each request (something the existing system already does)

  • (In the future, this can even be solved with good computer vision. This allows the system to automatically assess the situation by analyzing photo submissions from students.)


3. Provide more incentives to motivate students.

  • Although seeing other students engaged in helping the community can be perceived as an incentive itself, that effect is perceived rather passively.

  • Some kind of tangible reward might help students contextualize the fact that community issue reporting is mutually beneficial.

    • Reward should not have too much monetary value or otherwise might lead to increase false positives which work against point 2. 

    • A point system as an abstract representation of value (ex. x points = a free coffee).

    • Students should be able to reword both themselves or staffs who have helped the community.


Important Considerations



Below is an overview of the hi-fi screens. For details on design decisions on each screen, please refer back to the first section of this page.


  • If I had more time, I would want to interview custodians and technicians instead of trying to figure out how they would react to the design by reading about them.  

  • I would also want to spend time implementing micro-interactions in my prototypes to bring the experience to life. 

  • I realized that I spend too much time tweaking details in Figma, making everything pixel-perfect. I'm sure some of those were probably not necessary. 


Overall, I really enjoyed this challenge. Personally, I didn't really have a chance to complete a project from start to finish all just by myself. This experience definitely helped me gain a better sense of how I work best individually. I learned that I remain open to making BIG changes even at later stages into the process. In fact, when that happens, I was even very happy to move elements around and simplify my design. Discard everything that does not elevate the user experience and here we have something that will actually be able to solve a problem.


Yet as much as I enjoyed the challenge of working alone, this project also made me appreciate my team-project experience. I love getting feedback and,  though very cliche, learn from each other's strengths. 


Embedded Invision prototype!