Research: User Interviews

My first step was to understand the needs from potential users of this community. To begin, I posed myself high-level questions of what I wanted to seek out to understand. They were:

• Why do community members need a reporting system?
• How does a reporting system help its community members?
• Where are community members physically when they want to report issues?
• Do members feel connected to their community?

Broad Ideas Distilled into Specific Questions

Once I had a high level picture of what I was trying to do, I refined these inquiries into specific questions I could ask my interviewees:

Describe some common issues in your community...

Tell me about a time when a community reporting system would have made your life easier...

Tell me about a past experience when trying to report an issue in your community...

Tell me where you were physically the last few times you wanted to report or respond to a community issue...

Tell me about a time when you felt you were out of the loop with something going on in your community. How did you feel then?

Describe a time when you did feel connected to your community...

Interview and the Results

I asked two people I knew who lived in different types residential communities. The first, Daniel, lived in a mid-sized condo community comprised of approximately 200 units. The second, Steven, lived in a large apartment community with approximately 700 units.

Questions Posted to an Online Group

In addition to the 2 interviews I conducted, I wanted to see if I could cast a wider net and get feedback from more potential users, so I posted my question on an online forum (a Reddit subreddit :) and got a few responses. The questions can be summerized as:

What frustrates you about your community reporting system?

What would you like to see improved?

The results were:

Want rent payment to be accessible from community website

Want info & resources for more urgent maintenance issues in an easily accessible place

Would like a more visually appealing website and issue tracking system

Frustrated by lack of provenance and reasoning behind rules and HOA guidelines

Competitor Analysis

Next, I decided a competitor analysis would give me a lot of information as to what similar products were achieving. I compared the products from where my two interviewees lived. Right off the bat I could tell one product had much more thought and resources put into it, while the other was dated and lacking beyond basic features. One was warm and inviting, with large imagery and text leading the viewers eye, while the other overly technical, lacking in focus, and even functionally broken in places.

Organizing the results in a simple spreadsheet allowed me to easily compare and contrast the different features of these two tools.

User Profiles

From the results of my research I put together 4 profiles to represent the general makeup of the residents in my target community. This would allow me to more clearly understand who this newly designed product would serve. The four profiles encompassed a diversified group of community members that I hoped my solution would be able to serve.

User Personas

Then, I wanted to further realize my end user into personas that I could visualize more concretely. This would hopefully allow me to be more empathetic when working on my proposed solution.

Visualizing Common Problems with Storyboards

Though I don't always sketch out storyboards, here I felt it would help me visualize real issues members of this community might face. These stories focused on the subjects of my personas encountering problems around 1) a maintanence, 2) reserving an amenity on the property, and 3) calling a 24/7 emergency maintenance hotline.

Wireframing My Ideas

After getting a clear sense of possible issues in this community, I began wireframing solutions. Once I felt I had a solid idea sketched out, I annotated them for future reference and for anyone else who might need to see them. My primary solution was a responsive website that would serve as a hub for this community. Websites can be accessed from any device and can be easily found while searching online.

Exploring Alternatives

Though I knew my main solution was likely going to be a website, I wanted to explore other possibilities. The first alternative was a more robust mobile app. This is what I initially had in mind when I started the project, but came to realize throughout my research that community members having to download a mobile app could serve as a major hurdle for people who either do not have mobile devices or simply didn't want another app on their phone. Still, I felt it was worthwhile to explore.

Considering Non-web Alternatives

As designers we often think that the solution lies within some kind of website or mobile app, but that's not always necessarily the right approach. People sometimes prefer to interact with something other than a UI. These are two other alternatives that could be used in a residential community.

Had this residential community been much larger (and therefore less costly per person to staff someone on site), I could see the use of an in-person help desk be more convenient for residents. Often times being able to speak to someone face-to-face and explain your problem can get a faster resolution to your problem. Additionally, the psychological benefit of knowing someone is there to help you in a potential emergency (such as burst pipe or electrical issue) is reassuring.

Alternatively, a kind of intercom system could be implemented to allow residents to quickly communicate with the maintenance staff. However, with the ubiquity of mobile phones, this may not be necessary, but I still wanted to consider the idea.

The Final Design

The final design comprised a website with as much information as possible on the homepage, allowing users to get a glimpse of all the content without having to click off to a separate page (unless they wanted to dive deeper). I employed a two column layout in order to get as much information as possible above-the-fold while still hopefully not over-diverting users' attention. I placed official news and community updates in the main column, and contact info, maintenance and other useful bits in the wide sidebar.

What would a full-fledged app look like?

Though I came to the conclusion that a website would be most appropriate for this community, I wanted to explore some keys screens for what a more robust app could look like, using the same design language from the website mockups. Below are a few key screens which include a splash, home, ammenities and maintenance ticket request screens.

And here is a closer look at the navigation with custom icons.

Final Alternative: A Very Simple App

Lastly, I wanted to explore a more simplified version of an app. One that residents could download and keep handy on their phone, while not needing to get involved in more robust features. I'm envisioning this app is centered around one primary home screen with quick access to the different ways to contact the maintenance team. These are all the established ways people like to communicate, so it's hard to go wrong: email, phone, text message and chat.

What I Learned

This project taught me that solutions come in many forms. Often, they are simpler than we may have originally expected. I know my personal bias (and excitement!) going into this project as a designer was to create a feature-rich, robust solution like an app or web platform with all the bells & whistles one can imagine. However, often there is an unseen cost to more complex solutions in the form of cognitive overload and material price (i.e. $ upkeep). So, these must always be taken into account. Just because we can build it, should we?