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's risk visualization

• 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