Associate Design Program - Interview Design Exercise

Community Issue Reporting

Rotato Snapshot.png


I participated in Google’s Interaction Designer interview process. I had one week to complete this exercise!


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 resolved quickly.

Design a system for a community of your choice, so members can report issues and track their resolutions. Show your process and how you arrived at your solution. Please include a sequence of high-fidelity mocks from your design solution.

Process/Methods Used

1 - Research

  • Internet Research

  • Reflecting on Personal Experiences

  • User Surveys

  • Pain Points

2 - Ideation / Iteration

  • User Flow

  • Sketches

  • Wireframes/Lo-Fi

  • Key Design Decision

3 - Design

  • Hi-Fidelity Screens

  • InVision Prototype

4 - Reflect

  • Takeaways

  • Future Considerations


This design exercise is not related in any of Google's products in any way. Any information in this case study is my own and does not necessarily reflect the views of Google.


Internet Research - Narrowing the Project Scope

To dissect the prompt, I did a quick Google search with a few different queries to determine my target audience and the situations/contexts they are in. More specifically, I searched for: types of residential communities, their maintenance needs, amenities, and common maintenance issues.

Single-Family Home

Privately owned; maintenance is required by the owner

No shared amenities and maintenance is done by the owner



Hybrid between condos and single-family homes

Tenants share costs within the entire building

No shared amenities and maintenance is done privately by the tenants

Multi-Family Home

Hybrid between single-family home and condo

Maintenance is done by the landlord if renting and owner if otherwise

No community amenities

University Housing

Resident adviser and maintenance staff are available to call for assistance and maintenance

Amenities include study rooms, game rooms, music practice rooms, kitchens, etc.



Maintenance and repairs are completed by staff as long as the tenant pays a shared fee with other tenants

Has amenities such as gym, pools, and clubhouse maintained by the homeowners’ association


Maintenance is taken care of as a community by all tenants

Financial responsibility is also shared among all tenants


Apartment Residential Community

Maintenance staff is available for assistance for all tenants

Some shared amenities such as the gym, the clubhouse, pools, parks, etc.


Retirement homes / assisted-living communities

Similar to apartment communities where there is maintenance staff available

Shared amenities include medical services, the clubhouse, game rooms, a library with computers, parks, etc.


Common maintenance/repair issues


Common maintenance emergencies

There are also emergencies that affect not only one apartment or dorm, but entire floors or buildings. These emergencies are often announced to the entire community with status updates that inform them when the issues are resolved. However, residents often only know about the status of the entire affected area, and not when the issue in their living space would be resolved.


Based on these different communities, I narrowed the scope of this exercise to two user groups:

  • Apartment residential communities

    • I live in a residential community with thousands of other residents

  • University housing (dorms or apartments)

    • I used to live in a college dorm and experienced living in another university dorm one summer

The other types of communities were too similar to each other, maintenance issues were resolved privately, or the user base would be too difficult to reach on a large enough scale to gather useful data (ex: retirement homes).

At this stage, I planned to focus research on these two types of communities to gather specific information about the potential users of these two communities.


Exploring the Problem Space - Reflecting on Personal Experiences

Living on the University of Michigan campus

From my own experience, college dorms are maintained by a specialized group of staff. The resident adviser can often solve some of the easier issues such as disagreements between student residents.

I also explored online request forms for a few universities (University of Michigan, Stanford University, and Columbia University) to see how they have designed the experience.

There are usually two types of maintenance requests: emergency and non-emergency.


Non-emergency requests

These requests are usually requested through the online university portal or from a phone number. They are sometimes even requested by visiting the management office. The portal is usually only easily accessible through desktop web browsers and difficult to access on mobile. It is also not very clear which type of non-emergency requests should be asked for through this form. Finally, the form also has some information that should be automatically filled.


Conversely, emergency requests are usually completed by calling a phone number and there is no way to request online assistance.

Living as a summer resident on the Stanford campus

During my ten weeks living at Stanford University in the summer of 2017 for my NASA internship, I had a few issues I needed to contact the maintenance team for. I was told by many students there that it was easier to call for assistance rather than submitting a request online. Those online requests usually take much longer and not much feedback would be given on when help would arrive.

Using the McKinley Resident Portal

In the apartment complex I live in, the community management uses an online portal for rent payments, community announcements and discussions, and service requests.

Note: McKinley has one of the more robust and comprehensive online community portals, while many other smaller management companies lack this type of service.


Similar to the system used in college dormitories, this request form is for non-emergency requests.

The information I’ve hidden is auto-filled, which means that users can save time when filling out this form.

The resident can check the status of the request, rate the request, and view a history of requests.

I had 10 requests in about 1 year and 8 months of living in the community.

The visual design of the portal is still something to be desired (for example, the table would be difficult to view on mobile), but I felt that the content here would be useful to my design.


Maintenance staff came in at 2AM without resident’s approval.

Seems like the tenant should have received an advance notice that maintenance was coming and at so late of a time.

I also read through some of the community comments that tenants post. This one on the left was one that I noticed.

This may be a potential design opportunity

After these above reflections, I briefly thought about the platforms in which I would design the system on, which would be both desktop web and mobile. Being able to track the status of community issues on the fly may be an important need for users.

Despite all the research I have done so far, I knew that I still needed to hear from my potential users to definitely decide what and how I will design.

Focusing on the Users - Survey

Next, I brainstormed and created questions for the survey using my above information and research.

Each participant would complete eight or nine total questions, with college students taking an extra question about the school they attend. Four multiple choice, one multi-select, and three (or four) short answers.

The survey was posted in Facebook groups of different university groups and apartment residential communities across the United States.

Each one of my questions has a purpose. I will point out some of the questions here.


This first question is to screen out participants who has NOT recently lived in these two types of communities. I would not want to waste the time of people who are not currently or have not recently lived in these communities.

This question leads to two versions of the survey with slight modifications.


Knowing the most popular method residents use to request assistance can gauge the potential need of an online system for either group of users.


What features are missing and what needs improvement?


I want my users to tell me which device I should design for instead of deciding myself.

Differences in age or the school that students attend may affect how residents report issues and request maintenance. However, I wanted to keep demographic questions at a minimal.

Note: there is definitely a bias in the people I have surveyed. My answers do not represent all age groups and students from all types of universities.

Top Three Findings / Pain Points

Artboard – 2.png

An online community issue reporting system seems to be much less prevalent in apartment residential communities.

Directly contacting maintenance or the landlord by calling or text messaging is much more common.

What is the design opportunity?

There seems to be a much bigger need for an online solution for apartment residents compared to for university students.

Artboard – 3.png

There seems to be a lack of confirmation and feedback of the status of the request. Also, collecting requests?

What is the design opportunity?

Allow users to easily track the status of their request, whether help is on the way or that the issue has been resolved. And also allow them to view a history of their requests.

Artboard – 1.png

A mobile solution seemed to be preferred over a desktop web version (at least for apartment communities).

What is the design opportunity?

Focus designing for mobile users first.


Phones are faster and easier to access, especially in the case of emergencies and people usually always have their phone with them.

So now what?

After knowing what some of my potential users think, I decided to focus on designing a mobile experience solely for apartment residential communities, and leave designing a desktop version for future considerations.

My hypothetical user base now would no longer consist of mostly college students who are more tech-savvy than an average individual. Instead, residents living in apartment communities can vary greatly in socioeconomic status and needs.

So the design goals here are straightforwardness, clarity, and focusing on the users’ goal state.

Now it’s time to start designing for the user :)


User Flow

In section 2C, only the first screen in that section (Fix Request History) has been designed. The rest of that section are screens I would design if I had more time to conduct more user research.

Section 3 is an independent section when the user receives a text message about the updated status of their request.

I also chose to use Fix (instead of Resolve) in my app design because it is a simpler word to understand for users.

(Some of My) Sketches


One of the form designs I sketched


Two options of showing possible maintenance issues.

No need to be too detailed at this stage. Just exploring alternatives.

Wireframes & Key Design Decision

The black color used here is not pure black (#33333 - to improve readability over pure white #ffffff).


This is the screen that users see after logging in.

They can know the status of their requests right away.

The bottom tab bar has the very prominent wrench icon that leads to a fix request form.


This is a history of the user’s requests in list view, which can be viewed in detail upon tapping on a list item. If the list gets too long, I can perhaps use some tabs separating the list by year.


I made a key design decision (shown below) on how the fix request form should be formatted and displayed for the user.

Design #1


Single-page form with auto-filled contact information to waste as little of the user’s time as possible.

Pro: No need for multiple screens and information is more compact.

Con: Is this too much information on a single screen?

Fix - Request Type Autocomplete.png

The “Issue name” input field has autocomplete (similar to Google search). The user can also jtype in an issue not shown in autocomplete.


Design #2

Fix Alternative.png

The fix request form is separated into four steps here.

The user can select a commonly reported issue or search and choose one of the options.

Fix Alternative 2.png

Users can upload up to four photos to make the jobs of maintenance staff easier.

Fix Alternative 3.png

Pro: Progressive disclosure - information is digested in smaller bits and users are able to focus on giving potentially more detailed answers

Con: Slightly longer process due to four steps instead of one screen.

Fix Alternative Review.png

The user can scroll through to review and edit the information they have entered previously. This step is similar to the form in Design #1.

Fix Confirmation.png

I came up with two different confirmation screens, with one being more text-heavy.

Fix Confirmation Copy.png

I chose this alternative design because as I thought that showing more visuals of the request progress (and less wordy) would be less mentally taxing on the user.

Both designs would use the same confirmation screen.


I ultimately chose Design #2 as a part of my hi-fi design because I valued clarity over compactness. Clarity is essential here because some of my potential users may be individuals who are less savvy with technology (imagine residents in lower-income neighborhoods). Plus, users need to focus on each step of the process to give detailed information on community issues rather than doing it all at once.


I designed for iOS due to the popularity of iPhones. I used iOS Human Interface Guidelines as a guide. I did also have Material Design guidelines in mind when, for example, designing cards.


Main color - #1E3799 (Dark blue) - Color of trust and safety

Also passes WCAG guidelines - Source

All of the colors I use pass at least the AA level.

Hi-Fidelity Screens

There is not much use of color in many of these screens because they are text and information heavy, and I did not want to add colors for the sake of having colors…

I made another design decision at the hi-fi stage.


Original design

History Hi-Fi Copy.png

I wanted to use both text and color to show the status of all the users’ requests.

However, I ultimately felt that the date of the request on the rectangles were unclear, and that the rectangles themselves were too large.

The design I chose

History Hi-Fi.png

I used a caption-style text as the first line to show the request status and date.

I also made the dates clearer (3/15 vs March 15th) and used a smaller shape (circles over rectangles) with an indicative icon.

Below are some of my key designs in motion.


The main user flow: fix request for a community issue.

Note: Log in screen is not displayed, but the user would log in with their email address and password associated with their apartment lease.


Text message and progress tracking for the user to know what is going on.

InVision Prototype

Takeaways & Future Considerations


How was my experience using the app?

I appreciated updates on the status of my requests through text messages and also by checking the app. I did not have to call a phone number to know when the maintenance staff would be arriving or the status of my request. I think, through research and my personal experiences, this is a mobile experience that should be implemented by many residential management companies. This app experience can potentially make everyone’s lives easier and to minimize resident complaints.

I did not create deliverables just for the sake of having it there.

There were a number of deliverables and UX methods that I thought about including, such as personas, scenarios, etc. But ultimately, I did not want to make them just for the sake of having them. I asked myself, do they contribute to the needs of the users and the given prompt?

Future Considerations

How can this be used as a Google product?

Apartment management companies around the world can sign up as organizations to implement this experience in their communities. The visual design of the app would have to be modified by more closely following Material Design guidelines to fit into the Google brand. There would also have to be a set of designs for management so they can manage their residents’ fix requests.


In surveys you cannot ask follow-up questions to participants’ answers. I would conduct interviews with potential users to get more detailed responses and stories of their community issue reporting experiences.

I would also expand the audience of my survey to students from other types of higher education institutions and people from more varied age groups. Perhaps there is room for design opportunities at smaller liberal arts colleges or for senior residents. (kiosk-like touch-screen on the wall)


I would expand my app design by adding more screens such as the details screen for past requests and how residents would give feedback for those requests. I may also design a web browser version after getting more survey or interview data before deciding.

Last but not least, I would do some A/B testing of my design alternatives that I have mentioned above to receive some concrete feedback from users.

Read other case studies: NASA / DaySmart Software / Amazon (Password-Protected) / Sanctuary / YourGamePal / Google Exercise