Role: UX Designer & User Researcher. Timeline: Apr 2026 - present. Team: 4 core, across 3 organizations. Live research build: https://sites.gsl.noaa.gov/idss/aware/ (for research purposes only, not an operational NWS product).
The Problem
Under Impact-based Decision Support Services, forecasters brief the people who have to act on the weather: emergency managers, airport operations, utilities deciding whether to cut power to a canyon before the wind arrives. That work asks a forecaster to hold three things at once - what the atmosphere is doing, what it means for a specific partner, and what they are legally about to publish.
The tooling did not hold those three things together. Forecasters read the situation in one system, reasoned about partner thresholds in a spreadsheet, and composed product text somewhere else again. Every seam was a place to lose the map, the zoom, or the thread. The brief was not to make a weather app; it was to ask whether one workspace could carry a forecaster from noticing something to saying something without ever making them start over.
Research
I watched before I asked: routine shifts first, then a live high-wind event where the pace changed completely. The most useful observation had nothing to do with data. Forecasters treat their map the way a pilot treats an instrument scan - position, zoom, and layer stack are working memory, and anything that resets them is not an annoyance but amnesia.
A card sort settled the data model. Given the full layer inventory on cards, everyone grouped by provenance - satellite, radar, surface, hazards - and nobody grouped by appearance or task. Six categories fell out unprompted, and that structure is the shipped layer catalogue, including the groups we cannot serve yet, which stay visible and dimmed. Threshold interviews on the utility side supplied the third thread: the product had to translate forecast language into a partner's decision, not just display it.
Process
Lo-fi work answered one question: where does the forecaster live? Three layouts went on the wall. One map with tools sliding over it; four modes sharing a single map; a fixed 50/50 split. The split died in the room - half a map is half a map. Four modes won, and became the views the product ships with: Overview to watch, Analysis to study, Alerting to decide, Briefing to tell. The map underneath never reloads.
The second lo-fi study killed my own first instinct. I had sketched a modal wizard for hazard authoring - pick a hazard, draw the area, choose impacts, confirm. Familiar and completely wrong: a wizard takes the map away at the exact moment a forecaster needs it, and forces an order onto work that loops. The replacement treats a hazard as one editable object. Geometry can come before the name; the valid window can change after the draft text is read.
Mid-fi fixed three rules that survived to production: authoring docks beside the map instead of covering it, the raw product text is visible while you are still editing the thing that generates it, and a readiness checklist is the only gate on issuance, with every item stating its own status rather than failing silently. The time controls got their own study and became a persistent bar shared with the panel, in three states, with keyboard transport - so playback survives reaching for another tool.
The Solution
AWARE is a single map with four ways to work on it. Overview is the watch floor, with 16 available layers across satellite, radar, surface and aviation, and hazards, drawn from NASA GIBS, RainViewer, Iowa Environmental Mesonet, the NWS API, the Storm Prediction Center, and the Aviation Weather Center. Analysis turns the same location into a configurable dashboard of map, chart, sounding and stat widgets. Alerting is the authoring workspace: 24 hazard types across six categories, geometry drawn onto the map, impacts derived from forecast grids, live NWS product text with its VTEC string, and a readiness checklist before the issue button. Briefing is the same event told to somebody who has to act on it, exportable to PDF.
Reflection
Designing for experts inverts the usual instinct. Simplification is the dangerous move here; taking away information a forecaster needs during a wind event has consequences a bounce rate does not capture. The work is clarification - same density, less overhead, better ordering. Shipping my own designs changed how I design: when you write the layer-loading code, you stop drawing states that pretend data always arrives. And the fastest way to settle a disagreement about an interface is to deploy it.