Prep Checks

01Overview

Overview

Emergency preparedness is usually presented as a checklist. Buy this. Store that. Make a plan. Prepare for this disaster. Prepare for another disaster. The advice is useful, but the experience can become overwhelming quickly.

Prep Checks was designed to approach preparedness differently. Instead of treating preparedness as one enormous list of things someone has failed to do, we explored how smaller guided activities could help people understand what they had already accomplished and what they could realistically work on next.

02Reframing the Product

From checklist to exercise

One of the most important language decisions was moving away from the word checklist. We began calling them exercises. That sounds like a small copy change, but it reflected a larger product philosophy.

A checklist implies that there is one correct list and that the job is finished when every box is checked. Preparedness does not really work that way. A household's needs change. A person's location changes. Hazards change. Family situations change. Supplies expire. Knowledge gets forgotten. Preparedness is a practice.

Calling the activities exercises made the product feel more like something users could return to and improve over time.

03Showing Progress

Helping users see progress

A major part of the experience involved showing users that the work they were doing actually added up to something. We explored progress indicators including a prominent purple progress bar and score-based feedback. The interface could show:

• Completion progress
• Average exercise scores
• Areas that still needed attention
• Preparedness items associated with an exercise

Instead of only telling users what was missing, the product could acknowledge what they had already accomplished.

Emergency Items

Exercises could connect preparedness concepts with actual emergency items. This helped bridge the gap between abstract recommendations and something a person could act on. Rather than simply saying "be prepared," an exercise could help someone understand which supplies or resources were relevant to the task they had just completed.

04Researching Motivation

Borrowing from game systems, carefully

We also explored gamification and motivation. The goal was not to turn disaster preparedness into a game. There is an obvious danger in making a serious topic feel trivial. Instead, we looked at what game systems do well:

• Make progress visible
• Break large goals into smaller actions
• Give people feedback
• Encourage continuation
• Show improvement over time

Those principles could be used without turning emergencies into entertainment. That distinction mattered throughout the design.

05Reducing Fear and Judgment

Encouraging without becoming unserious

Preparedness products can accidentally communicate that users have failed. If someone opens an application and immediately sees dozens of incomplete tasks, the interface may technically be accurate while still making them less likely to continue.

We wanted Prep Checks to feel encouraging without becoming unserious. That meant carefully balancing progress, incomplete actions, scores, recommendations, and educational content. The interface needed to say:

Here is where you are. Here is what you already know. Here is one useful thing you can do next.

Not:

Here are 47 things you have failed to do.

06Inclusive Language

Words carry assumptions

Language was also reviewed as part of the larger HazAdapt accessibility process. One example was changing wording around emergency services from "Trust in 911" to "Comfort in calling 911."

Trust is a complicated concept. People's relationships with emergency services can be influenced by personal experience, community history, disability, immigration status, race, identity, location, and many other factors. "Comfort in calling 911" asks about behavior and experience without making the same assumption about why someone may hesitate.

That type of language work became an important part of how we approached preparedness research overall.

07Designing the System

Part of a larger ecosystem

Prep Checks was built within the same broader HazAdapt design ecosystem as ResiliencePoint and Local Safety Information. That meant thinking about shared components, typography, interaction patterns, responsive behavior, and how someone might eventually move between different preparedness tools without feeling like they had entered a completely unrelated product. The Rubik typeface became part of that visual system, along with consistent component behavior across the platform.

08What I Learned

Designing how the task feels, not just how it functions

Prep Checks reinforced that behavioral design is not just about getting someone to click a button. It is about understanding how the interface makes them feel about the task itself.

Emergency preparedness is already intimidating. The product did not need to add another layer of pressure. The design opportunity was to make preparedness feel measurable, approachable, and possible.