01Overview
Overview
Emergency managers work with an enormous amount of information. They need to understand the hazards affecting their communities, how prepared residents are, where gaps exist, and how those patterns change depending on location and population.
The information itself can be incredibly useful, but usefulness depends on whether someone can actually get to it, understand it, and make a decision from it. That was the problem we were working through with ResiliencePoint.
ResiliencePoint grew out of earlier work around an emergency-management dashboard called EM-Dash. As the product evolved, we began thinking beyond simply displaying information and toward giving emergency-management professionals a tool they could actively use to investigate preparedness data.
My role involved helping shape that transition through research, interaction design, usability testing, accessibility work, component design, developer handoff, and product QA.
02Understanding the Problem
Two needs in tension
Emergency-management professionals often have to make decisions across multiple layers of information. They may need to understand preparedness at a state level, then narrow down to a county, ZIP code, or another geographic area. They may be comparing hazards, looking at preparedness trends, or trying to identify where public education and emergency resources should be focused.
The product therefore had to support two very different needs:
- Give someone a useful overview quickly.
- Allow them to dig deeply into the data when they needed more detail.
Those goals sound compatible, but they created a difficult interaction problem. If we exposed everything at once, the interface became overwhelming. If we hid too much, users could not understand what information was available or how to get to it.
03Research
Researching how emergency managers work
Our design decisions were grounded in conversations with people working in emergency management and adjacent preparedness roles. We were looking at more than whether someone could complete a task. We wanted to understand how they thought about the information. Questions included:
- What information do you look for first?
- How do you define the area you are responsible for?
- When would you compare one location with another?
- Which preparedness statistics are immediately useful?
- How much information belongs on the dashboard before it becomes overwhelming?
- What terminology makes sense to someone working in emergency management?
- What needs to be exportable or shareable with someone else?
Those conversations showed us that the product could not simply behave like a traditional analytics dashboard. Emergency managers needed a way to ask increasingly specific questions of the data.
04Designing the Dashboard
A useful overview, first
The dashboard was structured to provide high-level information first. Quick statistics and trend cards gave users an immediate snapshot of preparedness without requiring them to configure a complicated query. Hazard information also needed a predictable default state, so the interface surfaced the top ten hazards rather than loading users into an enormous list without context.
Location was another major part of the experience. The product needed to support multiple jurisdiction levels, including state, county, and ZIP code. Map behavior changed depending on the type of jurisdiction being viewed so users would enter the experience at a useful geographic scale instead of manually correcting the zoom every time.
We also worked on navigation, including redesigning the side menu so moving between major areas of the platform felt more deliberate and understandable.
05The Problem We Found
An interface inside the interface
As the product became more capable, the query controls grew with it. Filtering was originally handled through controls that behaved more like dashboard dropdowns. That approach worked while the number of options was small. It did not scale.
Every new variable created another decision inside an increasingly compressed part of the interface. Users needed to select geography, hazards, and other criteria while still understanding the relationships between those choices. The controls were becoming an interface inside the interface.
Instead of making the data easier to explore, the dashboard was asking people to mentally keep track of too many selections at once. That was the point where the problem changed for us. We were not designing a better dropdown anymore. We were designing a query-building experience.
06The Pivot
Giving queries their own space
The biggest redesign decision was moving query creation out of the compressed dashboard controls and into a full-page query experience. This gave each decision enough room to be understandable.
Instead of opening several dropdowns and trying to remember what had been selected, users could progressively build a query. Selections were visible. Relationships between options were clearer. The interface could also support more complicated filtering without turning the dashboard into a wall of controls.
This changed the product from something that primarily displayed data into something that allowed emergency managers to actively investigate it.
07Designing for Real Questions
What the query builder made possible
Once the query builder had enough room to grow, we were able to introduce features that made the analytics much more useful.
Resident vs. Visitor Segmentation
Preparedness does not necessarily look the same for someone who lives in a community and someone who is temporarily there. A resident may know local hazards, evacuation routes, emergency systems, and available resources. A visitor may know almost none of those things. Treating both groups as one population could hide those differences. Adding a resident/visitor toggle allowed emergency managers to investigate the preparedness experience of each group separately.
Multi-Select Geography
Emergency-management work rarely fits neatly into one geographic boundary. We introduced multi-selection across state, county, and ZIP-level information so users could create queries that better reflected the areas they were actually trying to understand.
Local Safety Information Presence
ResiliencePoint also connects conceptually with HazAdapt's Local Safety Information product, or LoCo. We added the ability to investigate whether Local Safety Information was present for a given area, creating another way to understand the relationship between preparedness resources and preparedness behavior.
Location Buffering
People do not always interact with geographic boundaries as neatly as software does. To reduce problems around people located near a jurisdiction boundary, we incorporated a roughly 400 to 500 foot geographic buffer into relevant location queries. This helped prevent the system from treating someone standing just outside an administrative boundary as if they were completely disconnected from the nearby community.
08Results, Export & Sharing
Making the results understandable and portable
Giving users access to more data only helps if the results remain understandable. Trend cards helped surface changes without requiring users to interpret raw tables. Charts allowed patterns to be compared visually. Plain-language summaries provided another layer of interpretation so the interface did not assume every user wanted to analyze a chart from scratch. Users could also return to previous searches through query history, reducing the amount of repeated configuration required.
Emergency-management tools rarely exist in isolation. Information may need to move into a report, presentation, planning document, or conversation with another department. We therefore designed export functionality that allowed visualizations and information to be exported as PNG or PDF. Saving and sharing behavior was also explored as the query system matured. The goal was to make ResiliencePoint useful beyond the moment someone was sitting inside the application.
09Accessibility & Inclusive Design
Beyond WCAG compliance
Accessibility was part of the product process rather than something added at the end. I used tools and methods including accessibility reviews, WAVE testing, and GenderMag sessions to identify barriers that were not obvious from visual inspection alone. Across our work, GenderMag sessions surfaced four inclusivity showstoppers that could have prevented or seriously disrupted task completion for some users.
Those findings influenced interaction patterns, instructions, hierarchy, and how much knowledge the interface expected someone to already have. The goal was not simply WCAG compliance. Emergency-preparedness technology needs to work for people with different levels of technical confidence, domain knowledge, and familiarity with the product.
10Building for Development
Where design work meets engineering
My role continued after the design files were complete. I maintained components and design-system patterns in Figma and used Dev Mode to make implementation details easier for developers to inspect. I also worked directly with engineering during implementation, including:
- Reviewing implemented designs
- Testing product behavior
- Writing acceptance tests
- Identifying visual and interaction inconsistencies
- Clarifying intended component behavior
- Helping resolve gaps between the design and the production build
Our stack and product ecosystem included technologies such as Mapbox, Chart.js, Ionic, and Stripe. Subscription and seat-management functionality also became part of the platform as ResiliencePoint moved toward a sustainable product model.
11From Prototype to Production
Into real use
The ResiliencePoint MVP moved through acceptance testing between approximately May and August 2024. Seeing the product move into real use changed the nature of the design work. We were no longer asking whether the concept made sense in a prototype. We were looking at what happened when actual information, actual jurisdictions, and actual workflows entered the system.
ResiliencePoint ultimately reached production use with organizations including El Segundo, California and Oregon State University.
12What I Learned
When the structure stops fitting the job
The biggest lesson from ResiliencePoint was that adding features is sometimes a signal that the interaction model itself needs to change. The dropdown approach was not inherently bad. It simply stopped matching the complexity of the product. Trying to force more functionality into the same pattern would have made the experience progressively harder to understand.
Moving query building into its own experience gave the product somewhere to grow. It also reinforced something that has become a major part of how I approach design: when an interface keeps getting harder every time you add something, the problem may not be the new feature. The structure underneath it may no longer fit the job.