Context

About SONYC

SONYC (Sounds of New York City) is a $4.6M, NSF (National Science Foundation) funded project that uses sensors, machine learning, data science to mitigate the construction noise pollution in New York City. This is a mobile app that users can see the real-time noise data, locate the source, and send the noise report.

Challenge

Noise comes from construction work, is one of the most consistently reported issues in NYC. When creating a noise report so that the noise can be investigated and resolved, New Yorkers have problems to provide noise details and locate a noise source. Thus, how might we use data to address the problem and help them to create a stronger report?

Discover

Kick off

Understand ecosystem, painpoints and datasets

• To fully understand the problems, I researched on stakeholders’ reports to understand the urban noise ecosystem - how has the noise been produced? Who is involved? What data from stakeholders we want to use to address the problem?
• I listened to existing user interviews and talked to some users to understand who are our users and what did they need. To empathize the experience, I called 311 to report the noise.
• I then had a meeting with hardware and data teams to discuss what data do we have and how we want to incorporate the existing progress to the product.

The noise ecosystem and current report flow

I mapped out this ecosystem after doing research. DOB and DOT (Departments of building and Transportation) issue permits to construction sites so they are allowed to work after hours. 311 handles the complaint, and hands the cases to DEP (Department of Environmental Protection). DEP sends inspectors to inspect the site and solve the issue.

We wanted to use data from DOB and DOT to show building and street sites that are currently under construction in real-time. This could help users locate a noise source from one of these sites.

Pain points and user needs

Our users are New Yorkers who have ongoing noise issue in their neighborhood. They want to make reports so the situation could be regulated, their voice can be heard. After the interviews, we pinpointed the pain points and need.

Data will be visualized

The team has designed and deployed sensors outside of residents’ apartment window. The sensor collects sound data 24/7. Logging to the sensor would allow residents to see the noise details.

The data from sensors and other city agencies can help residents to provide noise details and locate a noise source when creating a noise report.

Define

Solution

After finalizing the research, I worked with the team to map out the structure of the solution. The solution was to analyze the data from DOB, DOT and 311, as well as the data that collected by the sensor, then transformed them to the user interface to provide insights with users. These data-driven insights will help users to see the noise details, locate a source, and send the report.

Unlike the current noise report flow, the report will be sent to DEP inspectors directly. This will help inspectors to schedule efficient inspections.

User journey

Design

Highlight

Login to the sensor, see the real-time noise data and fill out personal information

• The data from the sensor has been visualized to key decibel numbers and sound wave. The goal is to provide real-time noise details so users can make a decision of creating a report.
• Filling out the form shows how the noise has affected the user.

Locate a noise source with the help of DOB and DOT data

• The goal of this phase is to provide data-driven insight that helps users to locate a noise source.
• The chips and pins on the map are datasets from DOB, DOT and 311, and the cards show detailed information about the data.
• Users can review report details before sending it.

Usability Test

Technical constraint

Iteration

Prototype

Evaluation

Usability Test

We tested the interactive prototype with 10 residents from Hudson Yard in New York City to see whether the features and solution helps them solve the problem, and whether they are able to achieve the goal through the journey.

Reflection

Make the appropriate design tradeoffs to resolve conflicts and convince stakeholders.

When I presented new design to the team, I was challenged to explain the reasoning. This push me always think about “why” behind each design decision, and have solid reasoning to it. Being able to make tradeoffs helped me to understand the constraints and other stakeholders’ perspectives, strengthening design rationale.

Using data to back the design decisions.

Another way to resolve the conflict was to provide multiple solutions and user testing data to back my design decisions. Stakeholders would come up with solutions that oppose mine, the way I handle was to mock that solution, and put both solutions to the testing and let the data speak. This often resolved the issue.

Conduct user testing in an innovatie way with the constrained budget and resources.

The team’s budget had been shrunken significantly due to COVID. We had to use inVision and Zoom to conduct user testing. I worked with the PM to write tasks, made additional screens to put tasks on, so the participants are able to read tasks and test the screens on the same platform. All the tests went great, providing lots of insights.

Next step