Work/IBM · Severe Weather Alerts

IBM · The Weather Company · Case study

Notifications as the entry point.

  • Android Native Patterns
  • Notification UX
  • Severe Weather Alerts
  • Competitive Research
  • Engagement Strategy
  • Material Design
Role
Lead Product Designer
Timeline
Aug 2016 — May 2017
Platform
Android
Surface
Android notification panel

Overview

For many users, the notification was the product.

Notification panels were the primary entry point into The Weather Company app for a large share of the user base. They were also the easiest place to lose trust: too dense, too frequent, or too generic and the user mutes you for good.

The work covered ongoing forecast notifications and severe weather alerts on Android M and N. The bar was a panel that earned its place on a crowded lock screen.

Strategy

Three questions, every notification had to answer.

  1. 01

    Why would a user want to see this, now?

    If the answer was uncertain, the notification was the wrong shape, the wrong time, or shouldn’t exist.

  2. 02

    How much information at a glance?

    Collapsed and expanded states were designed as different surfaces, with different jobs. Neither tried to do both.

  3. 03

    What signals severity without crying wolf?

    A consistent escalation: ongoing forecast, alert, warning. Visual treatment, copy, and sound followed that ramp, not personal preference.

Research

How everyone else was doing it, and what we should learn.

The team studied notifications from Tinder, Swarm, Duolingo, Timehop, and other high-frequency consumer apps alongside weather competitors. Patterns emerged around tone, personalization, and the difference between an update and an interruption.

A user-flow diagram mapped how a panel item should reveal detail, branch to the app, and reset state across the escalation ramp.

Design

From the ongoing forecast to the tornado warning.

A big-picture template for ongoing forecasts

The default ongoing notification carried a forecast graphic, key conditions and a compact call-to-action. Collapsed and expanded states were designed to do different work, not the same work at two sizes.

The full composition: collapsed, expanded, alert

Each state had a fixed role in the system. The collapsed state was glanceable, the expanded state told a tiny story, and alerts were never confused with either.

Severe alerts that earned the interruption

Tornado, severe-weather and other watch-and-warning states used escalation deliberately: stronger color, larger glyph, fewer choices. The system reserved the loudest signals for the moments that actually warranted them.

Outcome

A notification system across the Android weather app.

3

severity tiers: ongoing, alert, warning

2

Android versions supported (M, N)

Earned

presence on the lock screen, not assumed

Reflection

Notifications are a relationship, not a broadcast.

The product team had every incentive to send more. The design discipline was sending less, more deliberately, and reserving the loudest signals for the moments that warranted them.

The competitive teardowns mattered. They gave the system a language for what kind of partner the notification was being in the user’s day.