Weather-Aware Event Planner

I led product design, PM, and front-end to turn forecast signals into planning decisions. We shipped a wedding-first MVP and kept the system neutral so it can extend to other event types without new UI.

Forecasts tell you the weather, but they don’t tell you what to do. Planners need date-specific tracking and alerts that turn risk into actions.

Who: Couples and coordinators planning outdoor weddings first; the visual system is neutral so it can extend to other events.
Constraints: Shared internal platform; lean on familiar patterns to reduce onboarding.
Success metrics: Faster go/no-go decisions; users can set up tracking in
‍< 60s; emergencies are seen immediately.

Climate volatility increases the uncertainty of planning events; teams need a tool that translates probability into guidance instead of raw data.

I explored the following options for displaying time-relevant weather information:
- Calendar overlays: good for scanning, weak for multi-day windows & thresholds.
- Saved filters: flexible, but abstract and easy to forget; not tied to a concrete event.
- Notification-only rules: low effort, but invisible until triggered.

I introduced Trackers, an event-centric object that bundles date range + thresholds + clear together into a scannable cards.
‍
This unlocked a couple wins:
- Clarity: numeric forecasts as verbs (“Bring umbrellas,” “Consider rescheduling”).
‍- Leverage: one rules engine and component library that generalizes beyond weddings.
‍
Early signals: users created a tracker in < 60s in testing.  

Threshold-aware cards: When a user’s metric (e.g., precip > 50%) threshold limit is exceeded, the card turns yellow/orange and elevates the headline stat; a short action line translates it into a decision.‍

User control: Thresholds are editable per Tracker.

‍Progressive disclosure: “+” chips reveal optional conditions so users only see what they need, allowing for fast initial setup.

Consistent color mapping: Weather metrics use the same color across icons, chips, charts, and controls, helping users quickly recognize each metric throughout the product.

This page shows one tracker’s window (venue + dates) with only the metrics selected for that tracker.

Alerts panel: When a threshold is crossed, the tracker surfaces a clear alert directly below the chart, along with relevant guidance. Keeping alerts within the tracker makes them easier to connect to the specific event instead of burying them in the global weather view.
‍
Focused weather view: The chart keeps the same visual language as Home, but narrows the data to one tracker so users can quickly understand the conditions around that event.
‍
Edit on demand: Edit Mode toggles configuration without cluttering read mode.

I worked with engineering to define the Tracker rule schema, including operators, thresholds, and date windows, and turned it into a shared spec. That gave both front-end and back-end a common source of truth, so front-end could mock the API early and back-end could validate against the same types.

I also built a lightweight design system from scratch, defining core tokens for color, type, spacing, radius, and shadow, then using them to create reusable components and patterns. Updating the tokens let me make broad UI changes without manually adjusting screens one by one.