01Overview
Making preparedness information local
HazAdapt's Hazard Guides gave people general information about hazards and emergency preparedness, but preparedness is inherently local. The information someone needs can change depending on where they live, the hazards affecting their community, and the resources available around them.
LoCo, short for Local Safety Information, was created to bridge that gap.
The product gave emergency managers and resilience organizations a way to add trusted, localized information directly into HazAdapt's existing Hazard Guides. Instead of asking someone to leave the platform and search through government websites, PDFs, social media, or other resources, relevant local information could appear alongside the general preparedness guidance they were already using.
My role involved helping shape both sides of that experience: the tools organizations used to create and manage local information and the public-facing experience people used to find and interact with it.
02Understanding the Problem
General guidance only gets you so far
A general Hazard Guide can explain what someone should do before, during, and after a wildfire, flood, earthquake, or other emergency. What it cannot always tell them is what that guidance means specifically for their community.
Local emergency-management organizations already have that information, but it is often distributed across multiple places. Someone may need to find a city website, navigate to the correct department, locate a PDF, search social media, or already know which organization is responsible for the information they need.
We wanted to reduce that disconnect.
At the same time, simply putting more information into a Hazard Guide wasn't necessarily the answer. These guides already contained a significant amount of safety information. Adding local content without a clear hierarchy risked making the experience more difficult to navigate, especially for someone who might already be under stress.
That created two needs in tension:
- Local information needed to be visible enough to be discovered.
- It could not overwhelm or compete with the core safety guidance.
03Research
Understanding how local information fits into preparedness
Our research looked at both the organizations providing safety information and the people ultimately consuming it.
For emergency managers and resilience organizations, we needed to understand how they thought about local preparedness content. The information wasn't simply associated with a hazard. It could also relate to a particular point in the preparedness process and a particular geographic area.
That meant asking questions such as:
- Where does this information belong within a Hazard Guide?
- Which community or geographic area should receive it?
- How much information does someone need immediately?
- What information can be progressively revealed?
- How should an organization preview information before publishing it?
- How do we make local information recognizable without making it distracting?
- How does the experience translate to a phone?
- What happens when someone's connection is limited or unavailable?
The research helped establish that LoCo wasn't simply a content-management feature. It was a system connecting organizations, geography, Hazard Guide structure, and the public-facing preparedness experience.
04Designing the Content Workflow
Putting information where it actually belongs
The organization-facing experience needed structure.
Rather than giving emergency managers an unrestricted publishing tool and asking them to decide where their content should appear afterward, we connected the creation process directly to the structure already used by Hazard Guides.
Organizations could identify the appropriate:
Hazard → Stage → Space
This gave the local information context.
Instead of creating a separate library of local resources, an organization could place information alongside the preparedness guidance it supplemented.
The content model also needed to support different amounts of information. Some local guidance might only require a short message, while other information needed additional explanation.
Tier 1, Tier 2, and Tier 3 content allowed the experience to progressively reveal more information rather than placing everything in front of the user at once.
The creation tools also accounted for links, rich text, language options, and geographic assignment.
05The Problem We Found
More information was becoming more noise
Once we started putting LoCo into the Hazard Guide experience, another problem became much more obvious.
Local information had to stand out enough for someone to understand that something specific to their community was available. But every visual element we added also had to compete with the existing preparedness content.
Earlier explorations used combinations of icons, interactive elements, borders, badges, color, and other visual treatments to distinguish the local information.
Individually, those choices made sense.
Together, they could make the interface busier than it needed to be.
When multiple elements were given similar visual weight, users had more things to interpret before they could determine what actually mattered.
The challenge was no longer simply How do we make LoCo visible?
It became How do we make LoCo recognizable without making the entire Hazard Guide harder to use?
06The Pivot
Making relevance louder than the interface
Instead of continuing to add visual emphasis, we started simplifying.
The goal shifted away from making LoCo look like a separate feature inside the Hazard Guide. Local Safety Information needed to feel like part of the guide itself.
We refined the information hierarchy, iconography, interactive states, borders, spacing, color usage, and progressive disclosure.
Badge-style elements and other visually heavy treatments were reconsidered in favor of more neutral patterns that communicated additional information without competing with the primary guidance.
Internal taste tests, demos, and iterative reviews helped us see where the interface was asking people to process too much at once.
The result was a quieter interaction model.
LoCo didn't need to announce every capability of the system.
It needed to tell someone there is information here that is relevant to where you are.
07Designing for Local Context
Showing the right information in the right place
Geography was fundamental to LoCo.
Organizations needed to associate their information with the geographic area it actually served. That geographic relationship helped determine when Local Safety Information was relevant instead of showing every piece of local content to everyone.
This kept the feature from becoming another generic section of a Hazard Guide.
The experience was designed around the idea that someone should encounter local information because it was relevant to their context, not simply because more content happened to exist.
We also had to think about discovery outside the individual Hazard Guide.
If someone didn't know Local Safety Information existed, designing a good interaction inside the guide wouldn't solve the entire problem. LoCo therefore became part of the broader HazAdapt experience, including entry points that helped people recognize when local information was available.
Consistent visual cues were important here. Once someone learned how HazAdapt represented Local Safety Information, that pattern needed to remain recognizable elsewhere.
08Responsive, Multilingual & Offline
Designing for the conditions people actually use it in
LoCo couldn't assume someone was sitting at a desktop computer with a perfect internet connection.
The public-facing experience needed to work across desktop and mobile web. On desktop, interactive and hover states could help communicate that additional information was available. On mobile, the same interactions had to work without relying on hover behavior and without turning a smaller screen into a dense wall of preparedness content.
The product also needed to accommodate multiple languages, including English, Spanish, French, German, Russian, Chinese, and Japanese.
Translated content can change significantly in length, so components couldn't be designed around the assumption that a line of English text would occupy the same amount of space in every language. That affected component sizing, hierarchy, wrapping behavior, spacing, and responsive layouts.
Connectivity created another consideration.
Emergency information may be needed at exactly the moment someone's connection becomes unreliable. LoCo therefore had to account for offline or degraded-network conditions so previously available safety information could remain useful rather than designing the entire experience around constant connectivity.
09Review, Publishing & Engagement
The work doesn't stop at publish
Because organizations were publishing safety information, the workflow needed more structure than a typical content editor.
Organizations could create their information, preview how it would appear, review it, and submit it before the content became publicly available. The workflow followed:
Create → Preview → Review → Submit → Approval → Live
This created a deliberate separation between writing something and publishing trusted safety information to the public.
But publishing was only one half of the problem.
Organizations also needed some understanding of whether people were actually finding and interacting with the information they created. LoCo included engagement tracking around interactions such as Hazard Guide activity, Local Safety Information interactions, link activity, and geographic engagement.
A history log also gave organizations visibility into how their content changed over time.
Instead of publishing information and simply assuming people were finding it, organizations had a way to better understand how their local content was being used.
10Accessibility & Inclusive Design
Safety information has to work for more than one kind of user
Accessibility was part of the product process rather than something added once the interface was complete.
We considered contrast, hierarchy, interaction states, responsive behavior, language, and the amount of information someone had to understand at once.
The context made cognitive accessibility especially important.
Someone using HazAdapt might be casually preparing for a hazard weeks or months ahead of time. Someone else could be looking at the exact same interface while stressed, distracted, unfamiliar with the area, or trying to understand what to do quickly.
That changed how we thought about hierarchy.
Important information needed to be immediately scannable. Supporting details could still exist, but they shouldn't compete with what someone needed first.
Progressive disclosure became especially valuable because it allowed the interface to preserve detailed local information without requiring every user to process all of it immediately.
The goal wasn't simply to make LoCo technically accessible.
It was to make local safety information understandable under the kinds of conditions in which someone might actually need it.
11Building for Development
Turning the system into a real product
My role continued beyond designing the screens.
LoCo had to work within the existing HazAdapt product, design system, Hazard Guide structure, and responsive behavior rather than functioning as an isolated feature.
I worked with components and design-system patterns in Figma and collaborated with development during implementation. That included:
- Reviewing implemented designs
- Testing responsive behavior
- Checking interaction states
- Identifying inconsistencies between design and implementation
- Clarifying intended component behavior
- Reviewing accessibility issues
- Supporting QA and acceptance testing
One of the most important boundaries we maintained was what LoCo wasn't.
LoCo wasn't intended to become a real-time emergency alerting system or replace existing emergency-notification platforms. Its purpose was much more focused: allow trusted organizations to supplement HazAdapt's existing preparedness guidance with relevant local information.
Restricted-access functionality and other expansions were considered as possible future directions rather than being treated as part of the core experience.
12What I Learned
More information isn't automatically better information
LoCo reinforced something that became important across a lot of my work at HazAdapt: complexity doesn't disappear just because you put it behind a clean interface.
There was a lot happening underneath this product. We were dealing with hazards, stages, spaces, geographic areas, organizations, content tiers, publishing workflows, languages, accessibility, mobile behavior, engagement, and unreliable connectivity.
The UX challenge wasn't figuring out how to show all of that.
It was figuring out which parts of that complexity someone actually needed to understand at a particular moment.
Some of our earlier explorations exposed too much visual information at once. Simplifying the experience didn't mean removing the complexity that made LoCo useful. It meant putting that complexity in the right places.
The project also changed the way I think about designing emergency-preparedness products. You can't assume the person using the interface is calmly sitting at a computer and carefully reading every option. They might be on their phone. They might be unfamiliar with the area. They might have a poor connection. They might be stressed.
The interface still has to make sense.
The best version of LoCo wasn't the one that showed everything the system could do.
It was the one that helped someone understand what matters here, where I am, right now without needing to understand the system behind it.