Summary
In support of earthquake preparedness initiatives from the City of San Francisco, SafeHome makes obscure government earthquake safety data accessible to the general public, in addition to information on geological risks and preparedness resources. Now in final iterations before release of MVP, in close collaboration with engineering, data science, product management, content writer, and government stakeholders.
The team
Product Design / Product Owner (my role)
2 Product Managers
3 Front End Engineers
3 Back End Engineers
3 Data Scientists
UX Writer
Occasional research help
The problem
Seismologists predict a 63% probability that the Bay Area will experience a magnitude 6.7 earthquake in the next 30 years
First-floor level deemed not earthquake-ready in an estimated 400 San Francisco multifamily residences, affecting approximately 5,400 residents
Data identifying earthquake-ready buildings is not readily accessible to the public
The intended users
All who pay to live in San Francisco, and those considering it.
Initial research to discover key functions
While the original scope was to make local earthquake safety data accessibly available, we wanted to check user needs and to validate the idea. Due to budget constraints exploratory research was confined to surveys, with around 50 respondents, confirming the need for the original idea while also surfacing these priorities (based on object-action pairs):
Address lookup with building, liquefaction, and tsunami safety information
General earthquake preparedness resources, including escape plans and household preparedness
Browsable earthquake safety map of San Francisco
Ability to share building safety report
Information on the project and its data sources
Clear, actionable, and reassuring verbiage around earthquake safety
Competitive analysis revealed some similar tools targeted at more technical users, while also highlighting the need for an accessible option unified with preparedness resources.
Interface formats considered
Given the user priorities, I considered several archetypal layouts, built with Chakra UI per the engineering team. The interface archetypes considered:
Dashboard: alerts info prioritized
Google Maps pattern: user familiarity
Portal with Left Navigation: allowing for dedicated pages per data type
Chosen
Dashboard: A single-pane responsive web dashboard was chosen because it would be easily accessible to all devices and user types (including those with screen readers), while also providing an authoritative single-glance report after address lookup.
Not Chosen
The Google Maps pattern is focused around the map, which was decided against as the map was deemed to be secondary to the hazard data and resources, based on the discovered user needs.
Portal with Left Navigation was decided against since it would require additional interaction to use, possibly posing difficulty for those with screen readers and the less computer literate.
Defining user flows
Once a layout was decided on, I mapped simple ways for users to meet their needs.
Finding necessary screens
Based on the user flows, three screen modes were identified as necessary:
Home Screen: address lookup and branding
Building Report and Resources (dashboard)
Modals: supporting information
Layout iteration and testing
A concern from the data science side was that the two-page design did not allow users to immediately browse the safety map without entering an address, prompting redesign to a single page
Interest in the Google Maps pattern also resurfaced from the engineering side, prompting A/B testing, which confirmed the Dashboard as the preferred format
Visual refinement and data transparency
A concern regarding liability surfaced during initial research led me to want to contact the City of San Francisco to ensure the interface and alert language were transparent to the intent in the City's dataset, on which the project is based. A meeting with City representatives allowed us to redefine the alert language to be in accordance with the City's intent, and also to provide users with details on how safety is being judged by the City.
Additionally, a second exploration on the visual design layer, based on user research, allowed us to land on a more refined look-and-feel to better engage the audience.
Testing usability, visual design, and concept
In collaboration with the team, I designed a script to guide testing for usability, visual design feedback, and to revalidate the concept with San Francisco residents over Zoom. A pilot test allowed further refinement of the testing script and materials. Based on the testing, some prioritized findings are below:
Refinement before MVP
Ensuring alignment with the City's interests will inform further product refinement and required analytics, prior to release of MVP. Some prioritized improvements were made per the user testing feedback, listed and illustrated below:
Incorporating help of UX writer to make language improvements using less lingo, and expansion of bottom three preparedness cards into a more approachable content section
Solve for map confusion with more visible legend
Addition of search button for clear call-to-action (not shown)
Visual differentiation of Report page, while maintaining browsable map on Landing page (with no input required to browse)
Differentiated Report page
To call better attention to the search results, I made the header on the Report page different from the Landing page, a point that came up during testing. Maintaining a browsable map on the Landing page allows the user to gain information on first entry to the website without requiring input of an address. For now, the earthquake preparedness information remains constant below the map. Future iterations may have context-dependent earthquake preparedness content on the Report page.
Release phases
Next steps
Continue collaboration with City of San Francisco once initial product is live
Consider direct mailing addresses in need of retrofit with website details
Collect feedback for continued improvement