02 - How I approached the problem
A.
Thinking about who this product is for
This product is meant for government, city councils, operations and planning teams .
Why it matters: This product will give stakeholders visibility on long term repeated issues instead of issues that is occurring now, which helps them to allocate resources to solving them.
B.
Defining what is a persistent issue
I defined a persistent issue as an issue that is:
The same issue that occurs repeatedly over time
At the same location
Why it matters: Defining what is a persistent issue will determine how data will be filtered, classified and displayed.
C.
Testing the data
Before designing anything I looked for and tested data to see if there are issues that are repeated at the same location. My explorations showed:
New York City has publicly available data to support this use case. Singapore does not.
Why it matters: I pivoted because of data availability and not because of personal preferences.
03 - My Key Decisions and Tradeoffs
Decision
Consequence
Switching from the Singapore context to the New York context
As mentioned, I pivoted because my goal to surface out persistent issues can only be done with publicly available data. After investigation, I realized that the data is not available for me to make a product with the same strong use case. However, the same design principles will apply to Singapore if I had access to the same type of data.
The product still showcases the same use case, but showing a different location other than Singapore.
I chose to focus on one data source
Because this is meant to be a proof of concept, not a comprehensive product that captures data from all sources.
The product uses one data source, so there might be a risk of not giving agencies the full picture on the situation.
I decided to use archived data instead of real time data
It would be beyond the scope of this project to link it up with real-time data. The current dataset is comprehensive enough to demonstrate the use case for this dashboard.
Data might be missing, or agencies might prefer to use real-time data sources.
04 - My constraints
What are the constraints, and why the app works like it is because of those constraints
Constraint
Implications
Archived data instead of online data
The dashboard has a timeframe and a minimum report threshold to let the user see how many complaints persist over time
Not pinpointing precise location of the complaints. Privacy concerns led to the decision to show rough locations.
The grid size representation matches a few city blocks which lets agencies still see the patterns of persistent issues but avoids address level precision while still showing where issues concentrate.
Avoiding Zip code representation on the map, but using it on the table
The grid is intended for agencies to analyze and identify a broad surface area. The zip code is meant for reference.
05 - What I Built
07 - Outcomes
What the dashboard enables agencies to see - Makes persistent issues visible across time instead of treating these issues as one off events.
Makes the agencies ask "why does this issue keep coming back?" instead of "was this issue resolved" when planning and allocating resources.