top of page

Opendoors Community Issue Reporting

Google Design Challenge 

System

Design

March

2020

iOS

A community needs a robust and transparent system to make sure issues are being reported and organized properly. However, the communication between members and staff can be opaque, causing delays and frustration as the problems are resolved. Opendoors is designed around a system that automatically organizes information, and for an experience that aids better communication between members and staff.

G challenge hero.png
project hero.png

Analyzing the Requirement

The Problem 

No easy way for community members to report and track problems. The underlying issue is communication between members and staff.

The Requirement 

1) An easy and fast way for members to report problems, and 2) make sure members understand the issue was heard and know what to expect next. In addition, there are unspoken requirements on the management and staff side: 1) An effective way for management to track many issues being reported, and 2) make sure management properly organizes and optimally prioritizes work with the resource they have. So that members’ problems can be resolved quickly.


The End Goal 

Provide transparency to reinforce trust between members and staff in a community, and give members a great experience of living.

Screen Shot 2020-03-26 at 1.06.28 PM.png

Unpacking the Problem

What Kind of Community?

I chose to design for managed apartments that are open to the general public because excellent communication, transparency, and trust are especially important for communities like this as members come from a very diverse background inclusive of all perspectives. Besides, management in these communities is more motivated to improve member satisfaction.

User Insights

I used a combination of methods to gain insight: I immersed myself in industry articles, read apartment and app reviews, conducted a competitive analysis, and surveyed/interviewed target users to obtain firsthand insights. Here are some of the key takeaways, in order from most broad to specific:

Surprisingly, people still prefer to make a phone call or an in-person visit.

Despite almost all apartment complexes having a website where residents can do things online, most participants still prefer old fashioned communications for these reasons:

  • Logging in to a community website is more complicated than it should be, especially when members don't do so often enough to remember the password.

  • Websites are for one-directional communication, which gets the job done for things like paying bills. However, when it comes to things that require a two-way exchange, such as reporting and tracking issues, a website is not optimal. 

  • A timely confirmation/reply from the management is critical for building trust.

"I find it easier to put in a request with the office via a phone call or drop in. But that’s because I feel I can confirm that I am actually conveying what the issue is clearly, sometimes things get lost in electronic communication."

JoshuaB93

People like the flexibility of online communication but are concerned the message won't be correctly interpreted.

Most people consider an in-person conversation as the easiest and most accurate way to describe the location and nature of a problem, especially for mechanical issues. However, most members don't have the flexibility and luxury of time to arrange such a conversation.

This diagram illustrates what participants considered to be the pros and cons of different communication methods.

My First Board.jpg

The person who bears all the work is eager to share the responsibility.

Despite responses that issue tracking is a "small" thing that doesn't take much time to execute, it reportedly requires a relatively high mental load to remember the task and follow up. The person who bears all the work is eager to share this responsibility, although currently there are no proper tools on the market that can solve this problem effectively.

"I put a calendar invite for me and my husband about what we need to do. But sometimes my husband doesn't check the calendar invite, and it's up to me to make sure we get to them. It gives me a lot of responsibility."

Qian Hu, Designer

Luckily, members don't find themselves having to report issues often.

The most common cadence is having to report an issue every six months.

Screen Shot 2020-03-23 at 1.42.19 PM.png

User Persona

Every community member had a differing viewpoint, but to ground my explorations around a cohesive narrative, I created two personas based on shared traits found in the people I interviewed.

Meet Jingru, who is in her late 20s, and works in Tech. She shares an apartment with a roommate - Sarah, who is in her early 30s, and works at a university.

Jingru’s Problem 

  • She has a highly demanding job with long working hours. She feels that she doesn't have much time left outside of work.

  • She has to take most of the household responsibility because her roommate, Sarah, frequently travels out of town. Due to her busy work life, Jingru is struggling to stay on top of household to-dos. 

  • The most precious resource for Jingru is time. She continually seeks ways to free herself from trivial things: if she could automate or outsource sleep, she would.

Jingru.png

Jingru Cheung 

Female, in the late 20s.

Finished college in the liberal arts program.

Works at a major tech company.

Sarah’s Problem 

  • Her job requires frequent trips to academic conferences and visiting sister universities. She doesn't spend regular time at home.

  • When she is home, she would gladly help with household stuff. However, communication with Jingru is not easy, as she's always coming home late, and they don't meet often.

Sarah.png

Sarah Day

Female, in the early 30s.

Hold a P.H.D degree in biology.

Works for a state university.

Define a Strategy

With the problem unpacked, a holistic system that stores member data, amenities data, and staff data will be most helpful. The key client-side applications in this system are: 

  • A mobile app for members, which lets them interact with management and staff virtually. It should focus on fostering close communication and trust amongst residents, management, and staff. 

  • A desktop application for management, which allows them to log amenities data, monitor member requests, and manage staff schedules. Most importantly, it enables management to analyze request amounts and staff bandwidth and provides insights to improve the overall workflow. 

  • A mobile app for staff, which lets them manage their schedule, pick up new tasks, and communicate with members on-the-go. The app will automatically prioritize based on task urgency, the proximity of worksites, and member schedules.

My First Board (2).jpg

While knowing that a systematic solution would be ideal, the timeframe limitation does not allow for the quality design of an extensive system. I chose to focus on the members' experience, assuming the management and the staff solutions are built. This means that any behind-the-scenes resources that support the members' experience are assumed fulfilled. 

Why a Mobile Experience?

As mentioned above: 1) being able to communicate with management/staff without time or location constraint and 2) bypassing the requirement to log in every time are two foundational requirements to secure a good experience for members. Not to mention, a mobile experience can leverage built-in phone features, such as camera, location, and other sensors, to save time and cognitive load for inputs.

Why is Payment Included in The App?

Members should have a de facto go-to place for all things that need management/staff attention. By including other community management features such as payment, residents have additional incentive to download an app that they would otherwise use only 1-2 times a year.

Design Exploration

I decided to start simple and work from a high-level structure to a more refined experience and interaction.

Structure of the App

The high-level architecture and the landing page are essential clues to help users understand what they can do here. I started by exploring the two characteristics of Opendoors - utility and communication at its purest: a standard utility app, and a standard messaging app. Then, I explored designs that blended these characteristics to various degrees with the intent of optimizing the experience.

The open questions I need to contemplate are:

  • What balance of utilitarian and messaging jobs is most appropriate?

  • Should I anchor the chat threads around topics or people?

structure1.png
structure2.png
structure3.png

The User Journey

After developing a rough idea of the app structure, I decided it was time to focus on the primary use case: discovering, reporting, and tracking issues. I mapped out the workflow to understand what needs to happen in this process so that I can identify opportunities to improve the experience for members. Here is what that looks like:

My First Board (3).jpg

Through this process, I was able to identify some interesting areas to focus on:

  • How might we help uncover problems as early as possible? 

  • How might we make reporting problems as easy and precise as possible?

  • How might we make sure members get timely updates on their issues?

  • How can Jingru and Sarah manage chores/problem tracking asynchronously and fluidly?

How might we help uncover problems as early as possible?

Often, problems emerge much earlier than they are discovered. If issues were brought to community member's attention before they become perceivable, it would give a lot more leeway instead of a scramble to have it fixed.

The first thing that came to mind was the increasingly popular deployment of smart devices. I explored a solution that assumed Opendoors was connected to smart devices. When they detect a problem, Opendoors could send push-notifications to members or staff. A side benefit of this approach is that data on the problem and its location could be prefilled automatically.

I also explored solutions that leverage the community's help to inform members if something goes wrong. For example, a neighbor could message Jingru with a picture of her A/C is leaking water. But this approach is less reliable. It could bombard members with false-alarms.

Exploration: smart device detects a problem

smart detect1.png
smart detect2.png
smart detect3.png

Exploration: community discovered a problem

community detect1.png
community detect2.png
community detect3.png
dumb report2.png
dumb report3.png
dumb report4.png

How might we make reporting problems as easy and precise as possible?

The perceived effort of reporting problems and the fear of miscommunication hold members back from dealing with them. One way we can help is to make reporting less open-ended.

I first explored an experience where members had enter selections: Where is the problem? What has the problem? And what is the problem? From a predefined list. But the process still feels long and daunting.

So I explored a smarter way to do it. Assuming we have data in the system such as amenities location, the make/model of equipement, and common problems, members would only need to specify one and the system would retrieve relevant data to simplify the rest. For example, if every communal amenity has a QR code label on its surface, members could scan the QR code to know its exact location, brand/model, and the common problems for this specific device. All they would have to do is select from the common problems or attach a free-form media/text. I mocked up solutions for different types of amenity issues: smart equipment, equipment, and non-equipment problems.

Exploration: manually select everything

dumb report1.png

Exploration: scan QR code to report

QR 1.png
QR 2.png
QR 3.png
QR 4.png

How might we make sure members get timely updates on their issues?

Not hearing back creates feelings of uncertainty; it hurts trust in a community. If we rely on management manually responding to every issue, the management resource will become a bottleneck for how soon members can get a response.

I explored ways to automate this process as much as possible. One solution was to create a chatbot that could give system updates automatically, as well as answer frequently asked questions, which would free management from busywork. Another solution was to automate task prioritization and staff scheduling using the backend system. However, this could make management feel a lack of control.

Exploration: issue tracking via chatbot

chatbot1.png
chatbot2.png
chatbot3.png
chatbot4.png

Exploration: standard issue tracking

standard tracking1.png
standard tracking2.png
standard tracking3.png

How can Jingru and Sarah manage chores/problem tracking asynchronously and fluidly?

Community members are eager to share household responsibilities, but sometimes, the communication between members wasn't as smooth as we would like. If Opendoors could know who was living together and allows co-managing of chores and payments, it would provide unique value to members.

I explored different ways to invite roommates/families: during onboarding, or by sharing an issue.

Exploration: invite roommates/families in different touch points

invite1.png
invite2_a.png
invite2_b.png

High-Fidelity Mockups

Visual Choice

The visual aesthetic should communicate Opendoors' two key characteristics - utility and communication. A neutral color, such as purple, will be best for the brand. I want the app to feel light-weight and friendly, so I chose a light canvas color to pair with the brand color. I decided to use illustration to add delight to the UI, as well as to convey a sense of openness and friendliness. I created a graphic to serve as my mood board.

moodboard.png

The human figures are from an open-source illustration. I modified them. The rest of the graphical elements are from my creation.

Sign Up & Sign In

My First Board - New frame (3).jpg

Workflow

HiFi_login1.png
HiFi_login2.png
HiFi_login3.png
HiFi_login4.png

Key screens

Discover & Report Problem

My First Board - New frame (4).jpg

Workflow

HiFi_report1.png
HiFi_report2.png
HiFi_report3.png
HiFi_report4.png

Key screens

Follow Up & Problem Tracking

My First Board - New frame (5).jpg

Workflow

HiFi_tracking1.png
HiFi_tracking2.png
HiFi_tracking3.png
HiFi_tracking4.png

Key screens

Final Thoughts

Improvement

There are a few areas I would like to improve if I have more time:

  • Get feedback from technicians on the issue-reporting flow. In particular, I want to know if the problem specification step provides enough information for technicians to work with. 

  • I would also delve deeper into security and privacy design. The current solution - requiring management to grant a security code to register, works fine as an MVP, but there's much more we can do to protect members' information.

  • I would audit the UI to make it more consistent. And more importantly, fix the accessibility issues like color contrast, font size, etc.

If the system is deemed successful, I would like to invest more in building tools for management and staff, such that we change the paradigm from fire-fighting issues to proactively preventing problems from happening in the first place. Something like an amenity-broken-risk score that predicts what amenities need maintenance soon would help.

Measure of Success

I would measure the success of this app by the number of conversations and the depth of the exchange between members and staff/management. These are key metrics because only when a community communicates extensively can a deeper relationship and trust can be built. I would also look at the member reviews/recommendations of the community as a secondary measurement.

bottom of page