UX Case Study - Weather notification application

Notifies users about the weather events they care about

There are thousands of weather apps on the App Store and Google Play. They all show today's weather and forecasts with sleek interfaces-so why design another one?

Various weather applications on the App Store and Google Play

Start Off

Problems

Weather apps are largely interchangeable, differing mostly in color and icon style. Their core job-telling you what the weather is like-is fine, but research shows there are still real problems:

1. People forget to check today's weather. Imagine heading out for a date at night without knowing rain is on the way.
2. Even if someone checked yesterday, it is easy to forget the forecast after waking up.
3. However beautiful the apps are, it is still tedious to open one every morning just to check today's weather.
4. Some apps push daily weather notifications, but receiving them every morning while still in bed-even when you don't need them-is annoying.

Research results via Google Forms

More than 85% of the people I surveyed had forgotten to take an umbrella before going outside, even after checking the forecast.

People still need, use, and want weather apps…

We have all stood at the front door wondering, "Do I need an umbrella today?"-then unlocking the phone, opening a weather app, checking the rain forecast, and deciding. But what if you forgot to check at all?

When this assignment landed, I decided to design a weather alarm-AWeather-that notifies users only about the weather events they actually want to know about, instead of being yet another generic forecast app.

Design a weather application with a distinctive identity among the many already out there.

#1. Observation

Goal & challenge

I wanted users not to need to launch AWeather often. On first launch, users set which weather events to be notified about (snow, cloudy, etc.) and what time and days to be notified. After that, they never need to open the app again unless they want to update the schedule.

Click the image to try the clickable mock-up on Marvel App

Job stories

I wrote Jobs to Be Done statements to design from the user's perspective.

1. When I wake up late, I want to be notified in advance about specific weather events, so I can prepare without having to check the forecast manually.
2. When I'm too lazy to check the weather every morning, I want to be notified only when it's rainy, so I can grab my umbrella and get a few extra minutes in bed.
3. When I set an alarm for a specific time, I want only relevant alerts-not a generic daily forecast, so I can avoid being bothered when the weather is fine.

#2. Ideation

Main purpose

AWeather notifies users about only the weather they care about, only when they care. This saves time and helps them prepare for specific events without checking the full forecast. Even if users forget yesterday's forecast or skip today's check, AWeather will alert them when one of their selected weather events occurs.

"Great UX is intuitive and saves users time."

Brainstorming

A simple flow:

1. The user downloads and launches AWeather.
2. The user sets alarms for the weather events they want to be notified about.
3. The user receives notifications based on those settings.

For example, if the user selects rain or wind, a push notification fires at the chosen time, only when it's raining or windy. I kept the application as simple as possible, with minimum depth, focused on a single task: setting an alarm. No other features.

Example - push notification from AWeather

In the example, the user has set an alarm for 9 AM Monday, if rainy. If it isn't raining on Monday, no alarm fires.

#3. Rapid Prototyping

Lo-fi prototypes

Using Kakao Oven, I built rough prototypes before moving to Hi-fi. (Click image to enlarge.)

Lo-fi prototypes (screens 1 → 4)

1. The intro screen shows a simple introduction and the launcher icon, with a "Start" button at the bottom.
2. On the "Select weather type" screen, users choose which weather events to be notified about. Selected types appear as weather icons at the top.
3. On the "Set time" screen, users pick the time and day with pickers.
4. On the final screen, AWeather confirms that everything is set. To change the settings, users tap "Alarm Settings" at the bottom and iterate from screen 2 to screen 3.

On the "Select weather type" screen, I deliberately limited the options. Notifications about ordinary weather (like sunny days) on a phone already full of push notifications would only drown out the more important ones. Push notifications should be reserved for weather events that demand action-bring an umbrella, wear a thicker coat. Too many options would also slow down setup. The available choices:

• Snow / Rain
• Thunderstorm
• Heat wave
• Strong wind
• Cold snap
• Fog / Cloud
• All of the above

Improvements

Usability testing

Based on the lo-fi prototypes, I ran usability tests with non-designer friends to prove the application's usability. Below are some pain points I caught during testing.

"If you want to improve a piece of software, all you have to do is watch people using it and see when they grimace, and then you can fix that." - David Kelley

Usability testing

Pain Point #1

On the original screen 3 (Set time), there was no Back button after choosing the weather events, forcing users to redo the whole step to change their selection. On the right, the improved screen adds a Back button so users can return directly.

Pain Point #2

After testing, most testers asked, "How do I check my alarm settings?" or "What does this 'Alarm Settings' button do?"

On the original screen (left), the launcher icon and long descriptive sentences provided no useful information. I removed them and instead displayed icons of the weather events the user selected, plus the time they chose to be notified. I also renamed "Alarm Settings" to "Edit Alarm" to clarify the button's purpose.

#4. Validation & Iteration

Based on feedback

With the improvements above, I ran another round of tests. The table below shows the results: a mission counted as succeeded if the tester completed it without struggle.

#5. Output

Hi-fi prototypes

After testing, I redesigned several screens based on the feedback and built Hi-fi prototypes. (Click image to enlarge.)

Based on the user's settings, a push notification fires on their phone. In this case, the user chose to be notified for Snow/Rain, Heat wave, or Strong wind at 9 AM every Monday, Tuesday, and Thursday. Once the alarm is set, users never need to launch AWeather again unless they want to change it.

Final flow map

After the first alarm is set, users can edit it from the bottom button on the final screen. Try the clickable mock-up on Marvel App.

Thumb zone

To deliver the best one-handed accessibility from any holding posture, I referenced an article by Samantha on the "thumb zone". Every interactive element in AWeather can be touched comfortably with the thumb alone.

Icons for AWeather

Clickable mock-up

Using the Hi-fi prototypes, I built a clickable mock-up in Marvel App for further validation.

Interaction

Small animations on mobile screens improve the user's understanding of process and result. In AWeather, I used motion to confirm when, and for which event, the user is being notified. (Click image to enlarge.)

What I learned

When designing, it can pay to focus deeply on one key issue rather than the whole picture. Trying to solve everything at once makes it easy to overlook what truly matters.

In AWeather, I wanted users to set alarms with as little depth as possible and complete the whole flow quickly. While that goal is valuable, my obsession with reducing depth made me overlook small but critical details-like the missing Back button (Pain Point #1).

Takeaways

AWeather is a weather alarm application that lets users get notified about only the weather events they care about, only when they want to be notified. Even if they forget to check the forecast, AWeather quietly reminds them to bring an umbrella or wear a heavier coat.