SF QuakeSafe (in progress)
For this project I am providing end-to-end product design, in close collaboration with a cross-functional team of PM, software engineers, data scientists, with some occasional design help. User research expanded the premise of this project to be a responsive web app allowing earthquake fitness lookup of San Francisco residential addresses, supported by mapping and resources for earthquake preparedness and retrofit contractors and grants.
Problem: Not all San Francisco homes are earthquake-safe
A large number of San Francisco homes have soft story foundations that are not properly retrofitted in preparation for earthquakes
Data on soft story buildings in need of retrofit is not easily accessible to the general public
Discovering the user
Explorations based on user research and organizational goals helped us broadly define the user as someone with concern about earthquake preparedness—and, either a San Francisco resident, or someone interested in living in San Francisco.
Defining the app's key functions
After completing both qualitative and quantitative user research, we validated that there is broad concern about earthquake safety in the target audience. We also discovered a need for certain earthquake preparedness knowledge and resources, in addition to making the soft story data available. To find these key functions, I combined organizational goals, research insights and personas into user stories, in which I found unique objects, actions, and attributes, which I organized into a prioritized conceptual model to be used as a guide for app ideation and interface layout.
Exploring semantic grid and archetype options
Once the key functions of the app were discovered, I took into consideration the target market, accessibility considerations, and archetype qualities, to explore some semantic grid options. We finally landed on a dashboard format after consideration, for accessibility reasons and to provide an easy single-glance report after address lookup.
Understanding user flows
Knowing the user goals and key functions of the app, I was able to surface which goals required simple user flows, as some were met by the single view of the dashboard format.
Establishing wireframes
Based on the user flows, I identified three screen modes needed: A home screen allowing address lookup, results in a dashboard format, and optional modals for additional information.
First visual design pass
Based on the wireframes, I did a first pass on the responsive sizes to better understand what elements and styles I would need to build out in components and the design system. Modals for the "About" and "Share report" links would show further details.
Layout iteration and testing
Interest in allowing the user to freely browse the map without needing to enter an address broke the two-page design, prompting a redesign to a single page
Interest in the Google Maps pattern resurfaced, prompting a need for A/B testing to establish preferred archetype
Concern regarding usability prompted need for usability testing; assembling script and tasks for interviews
Creation of responsive sizes for MVP
Learnings from collaboration and A/B testing preferred the dashboard layout
Responsive sizes produced for front end development, with modal and dropdown to follow
Next steps
Iteration on map visualizations
Usability testing and any iteration prior to build
Consider mailing all addresses where soft story is in need of retrofit
Analytics to assess MVP success
Explore and enhance visual design layer, for impact and engagement