Concept redesign · Federal · UI/UX
National Hurricane Center — Designing for Critical Decisions
A self-initiated redesign of the National Hurricane Center — the source of official tropical cyclone forecasts, watches, and warnings for the United States. During a storm the site stops being an information portal and becomes a time-critical decision interface, so it was rebuilt around threat, location, impact, timing, and action rather than around forecast products — designed to Section 508 / WCAG 2.1 AA from the first screen.
Self-initiated concept. Not affiliated with, commissioned by, or endorsed by NOAA, the National Weather Service, or the National Hurricane Center. Created to demonstrate accessible design capability for federal digital services. The storm, advisories, and warning areas shown in the mockups are illustrative.
01 / The challenge
Critical information was available — but you had to understand the system before you could understand the threat.
The National Hurricane Center serves a uniquely broad audience from a single entry point: residents trying to work out whether a storm will reach them, alongside emergency managers, meteorologists, mariners, researchers, media, and GIS professionals who depend on specialized forecast products.
The existing experience had grown around those products — forecast types, geographic basins, archives, and internal terminology. That works for someone who already knows which product they need. For the general public it asks for interpretation first, before the interface answers the questions that actually brought them: What is happening? Does it affect me? When? How serious is it? What should I do next? The task was to make those answers immediate without removing the depth professional users rely on.
| Area | What we observed | Impact on people in the path |
|---|---|---|
| Product-oriented architecture | The experience is organized around forecast types, data products, basins, and archives rather than around the decisions people make during an active threat. | You have to learn where information lives before you can learn what it means. |
| Weak emergency hierarchy | Warnings, news, forecast products, maps, navigation, and supporting resources compete within the same visual system. | Position and visual weight don't consistently reflect urgency. |
| High cognitive load | Multiple navigation layers, link lists, forecast products, basin selectors, and technical terminology appear at once. | Useful density for a meteorologist; more to scan for someone checking a storm under stress. |
| Forecast data ≠ personal impact | The interface communicates a great deal about the storm, but leaves the translation to the reader. | “What does this mean for my location?” stays unanswered on screen. |
| A fragmented mobile experience | The homepage carries no viewport meta tag and renders its ≈990px desktop layout on a 375px screen. A separate mobile site exists, but has to be found manually. | The most likely device during an evacuation gets the least usable view. |
Observations describe the legacy experience shown in Fig. 02, measured in-browser using computed styles, bounding boxes, and DOM inspection.
The shift
Before & after.
The same entry point, in the same frame: drag the handle to wipe between the redesigned site on the left and the legacy one on the right. The legacy view opens on a news list, basin and forecast selectors, and a static outlook graphic. The redesign opens on the storm itself — its warning status, the area it affects, and the two things you can do about it.
02 / Our approach
From forecast products to threat comprehension.
We reorganized the experience around the decisions people make during a developing weather event. Rather than asking someone to identify the correct meteorological product first, the redesign establishes a decision sequence and follows it in order.
- 01Threat
- 02Location
- 03Impact
- 04Timing
- 05Action
- 06Detailed forecast
Professional forecast products and technical data stay in the system as a second layer rather than competing with urgent public information — reachable in one step, but no longer carrying the same visual weight as a life-safety message.
Design decision 01 — Making the current threat unmistakable
From navigation-first to threat-first.
During an active hurricane the most important thing on screen is not which forecast product exists — it is the current threat. The redesigned view opens with warning status, storm, severity, the affected area, expected conditions, when it was last updated, and when the next advisory is due. Instead of the life-safety message living inside a technical product, it is the starting point of the experience.
Warning status leads the panel with an explicit label, so nobody has to open an advisory to learn that one is in effect.
Instead of several technical paths at equal priority, the interface offers one route to what to do and one route to the complete official product.
How old the information is, and when it will change, are part of the warning rather than something to infer from a file timestamp.
Design decision 02 — From the storm to the person
“Where is the hurricane?” is not the question people are asking.
A hurricane map answers where the storm is. For most residents the more urgent question is what it means where they are. We moved a location check directly into the primary storm interface, so someone can go from general storm awareness to localized warnings and expected impacts without leaving the screen the warning is on. The same capability stays reachable from the header as Check local risk, regardless of where someone enters the site.
The location field sits in the storm panel beside the warning it qualifies, rather than in a utility area elsewhere on the page.
Check local risk is a persistent header action, so the question can be asked from any page rather than only from the storm view.
The field accepts what people already know about where they are, with an explicit label rather than instructions hidden inside the field value.
The shift is from a storm-centric product to one that answers a personal question — the same forecast data, addressed to a location.
Design decision 03 — Progressive disclosure
Three predictable levels instead of everything at once.
Not everyone needs the same depth. Rather than presenting storm metrics, impact information, warnings, and technical advisory content simultaneously, the redesign organizes them into three levels that always mean the same thing — so the initial load is smaller without putting the underlying forecast further away.
Current warning, category, affected area, movement, wind speed, pressure, how fresh the information is, and when the next advisory arrives.
Expected wind, storm surge, and rainfall, with timing and location-specific risk.
The complete official NHC product, for the people whose work depends on reading it in full.
Design decision 04 — One experience across every screen
For a safety-critical service, mobile is not the secondary experience.
The legacy homepage declares no viewport, so a phone renders the ≈990px desktop document at roughly 0.38× on a 375px screen — legible only by pinching. A separate mobile site exists, but a person has to know to look for it. We replaced the split desktop/mobile model with one responsive information architecture: warnings, actions, forecast context, readable type, and hierarchy are preserved across sizes rather than compressed into them.
Design decision 05 — Public simplicity without losing professional depth
One product, several levels of expertise.
The goal was never to turn NHC into a consumer weather app. Emergency managers, meteorologists, mariners, researchers, and developers still need direct access to specialized products — Forecast Advisories, GIS & Maps, GRIB2, CAP/XML, RSS, and text products. Rather than mixing those tools into the public emergency journey, the redesign gives them a dedicated professional layer. Operational, technical, and experimental products stay available without carrying the same visual weight as an immediate life-safety message.
03 / Why it's compliant
In a life-safety product, accessibility has consequences beyond usability.
People may need to read a warning under stress, outdoors, on a small screen, with low vision or limited motor control, or over a degraded network during the event itself. So the redesign prioritized audiences by the cost of failing to receive or understand critical information rather than by traffic volume, and accessibility was treated as a design constraint from the start. Each decision below maps to the success criterion it satisfies.
1.4.11 · Non-text Contrast — AA
Text was designed against the 4.5:1 target and controls and interface states against 3:1, including the map overlays and the warning panel that sits over imagery.
Hurricane Warning, Hurricane Watch, Tropical Storm Warning, and Tropical Storm Watch each carry an explicit label and indicator alongside their severity color.
Every critical forecast visualization is paired with a meaningful text equivalent, so understanding the threat never depends on interpreting an image.
A clear H1, section headings, navigation landmarks, and predictable reading order replace tables used to position content visually.
Location and search inputs use explicit labels, predictable hints, and appropriate autocomplete rather than instructions embedded in field values.
Type and containers are sized in relative units so text scales to 200% without clipping or loss of function — separately, a 16px floor keeps that scaling from starting at the legacy baseline of 9.3px.
The criterion's floor is 320px with no two-dimensional scrolling. One responsive architecture re-ranks warnings, actions, and forecast context down to that width instead of scaling a desktop document to fit.
Navigation, map controls, the timeline, and the location field were designed around a logical keyboard order with clearly identifiable focus states.
The component system uses a 44px minimum for primary controls — beyond the 24px WCAG 2.2 AA floor, against a legacy baseline where most links measured under it.
The forecast timeline, layer toggles, and map controls are custom components, so each exposes a name, a role, and its current state rather than reading as an unlabelled button.
The contrast floor applied across the concept — text against its background, controls and interface states against theirs.
Default minimum target for primary interactive controls, chosen for one-handed use on a phone rather than for the minimum that passes.
Text floor for meaningful content, applied as a system constraint rather than decided component by component.
These are the rules the concept was designed against. The measurements in § 04 come from the prototype, not from a conformance audit of a shipped system — that would come after implementation.
04 / Measured impact
Before and after, evaluated the same way.
The legacy experience and the redesigned prototype were measured with the same in-browser method — computed styles, bounding boxes, and DOM inspection — so both sides of each pair below come from the same instrument rather than from an estimate.
10 of 231 sampled legacy elements failed, with a worst measured ratio of 2.15:1. The audited light-theme prototype recorded 0 of 351 sampled elements.
76 of 100 visible legacy links measured under 24px tall. The redesigned prototype recorded none, with 44px as the default minimum for primary controls.
Legacy content carried meaningful information at sizes down to 9.3px. Readable typography became a system constraint rather than an individual component decision.
8 of 11 legacy tables positioned content rather than presenting tabular data. Presentation moved to semantic layout patterns; tables stay reserved for real tables.
Location and search interactions now carry explicit semantic labels rather than relying on placeholder text to explain themselves.
The legacy forecast map offered no meaningful text alternative. Critical forecast information no longer depends on interpreting an image.
The legacy homepage served its ≈990px desktop document at roughly 0.38× scale. The redesign was verified at a 375px viewport as its own layout.
Critical interface behavior no longer depends on external runtime services — which matters most on exactly the degraded connection an emergency produces.
Legacy figures describe the homepage as captured on 20 August 2026 — the update timestamp is visible in Fig. 02. Counts that sample page elements move with storm activity, since an active advisory adds links and rows; the structural findings — the 990px layout, the absent viewport declaration, the 9.3px type, and the third-party dependencies — do not.
Threat first. Context second. Complexity when needed.
The redesign doesn't reduce the complexity of hurricane forecasting. It reduces the complexity a person faces when trying to understand it.