The Weather Won’t Decide Itself — A UX Case Study for the App I Wish I Had
“Can summer start already?”
“It better not rain tomorrow…”
“I wish it would snow for just one hour”
Any of these thoughts sound familiar? Whether you want the weather to be perfect, or you’re just looking for a change of pace, you never seem to have any say in the matter!
But what if you did?
1. The Challenge
For fun, I wanted to explore what the experience might be like if humans were able to decide the weather. For the sake of practicing mobile app design, I set out to create an app that brings the power of weather to our pockets.
First, I decided on a few parameters in order to narrow down my scope:
- The app will randomly appear on users’ smartphones, and then later vanish into thin pixels. It can only exist on one phone at a time — we wouldn’t want to give the weather conflicting instructions.
- Let’s start simple: Users get to decide the weather for ONE DAY only. Plus, I can’t imagine anyone wanting that responsibility all the time.
Alright, let’s get to it!
Brainstorm
I typically like to begin new projects with a stream-of-consciousness style writing/sketching session. This helps me frame my most important research questions and uncover any assumptions I may already be making. In this case, it’s also where I defined the parameters listed above.
2. Research & Discovery
To the best of my knowledge, there are no products as of yet that let anyone make their own weather — so if you are secretly developing this fascinating technology, you know who to add to your design team. :-)
Weather creation being a new and unusual experience, I made the goal of my research to discover what type(s) of weather users want, and their general attitudes toward the idea of creating it themselves.
User Interviews
To discover this, I not-so-small-talked with 5 potential users (between the ages of 25 and 56) about the weather.
I structured the interviews loosely around the following questions:
- What is your preferred or ideal weather?
- If you had ONE DAY to make the weather ANYTHING you want, what would you do?
Findings
After mapping out the qualitative research data gathered from my interviews, I came to some key insights:
- The most common favorite weather theme was “sunny,” yet the idea of what this meant differed from person to person.
- Most users preferred to customize temperature, humidity, rainfall, and the timing of weather events.
- While some users had many specific wishes about the weather, others felt overwhelmed or did not care to customize extensively.
I ended up creating two personas to capture the goals and attitudes of users who might encounter a DIY weather app on their smartphone.
Some weather stories based on personas:
Creative Carly: “When I encounter a weather app that lets ME decide, I want to have fun customizing and exploring my options, so that I can make something really cool and unique.”
Moderate Mark: “When I open up an app that tells me to create the weather, I want some examples or guidelines so that I can get the weather I want without worrying about it.”
Insights from “competitors”
Although my users have never created the weather before, I’ll bet the vast majority ARE familiar with using regular weather apps on their phones.
To get a sense of what and how weather information is typically presented, I had a look around 5 top-rated weather apps.
My observations:
- In each app, front and center was some form of “current stats” — at the very least the temperature, a summary (“Mostly Cloudy”), and a visual symbol to match.
- When not in summary form, information was presented with daily and hourly timelines. The daily ones were often vertical-scrolling and the hourly ones horizontal, but the reverse was also common.
- Numbers abound in weather apps, but some had additional graphs or charts depicting changes in temperature, rain, or wind level.
What I took away:
Firstly, weather apps provide a TON of info. While it may (or may not) be useful to look at, it probably wouldn’t be very fun to fill in the temperature, rain level, cloud cover, wind speed, wind direction, dew point, UV index, humidity, visibility range, and atmospheric pressure for EVERY HOUR — even Creative Carly would have a fit!
Secondly, though numerical parameters provide the most accurate description of the current weather, users have never created their own weather before and probably aren’t clear on which combination of numbers will yield the experience they imagine. This resonates with Moderate Mark especially.
3. Product Definition
Goals & Principles
After completing my initial discovery research (which is not to say that discoveries ended there), I defined two Product Principles to help guide my design execution throughout the process:
- Make the quickest path to perfect weather apparent, while providing multiple, meaningful ways to customize if desired.
- Use familiar concepts and patterns to successfully guide users though an unfamiliar experience.
What does success look like?
Okay, so my app likely won’t be a real thing anytime soon, but if it WAS happily installing itself on unsuspecting users’ phones, how could I measure success? Well, I think I’d want as many people as possible who opened the app to successfully complete the weather deciding process.
How can I capture their engagement?
How can I help them see it through?
How can I assure them all is well?
Though I can’t truly measure conversion rates, I believe that designing according to my product principles will make it more likely that users complete the process of creating their custom weather.
4. Design Iteration
By this point, I had in mind a general app structure that I wanted to explore in further detail. Most importantly, I wanted customization to be a completely optional and skippable step, unnecessary for great weather.
Prototyping on Paper
With my product now defined at a high level, I started working out ideas for the app’s implementation on screen-sized sheets of paper.
I like this method because I can easily switch between generating new ideas and refining the app’s structure in a format that’s always ready-made for quick user feedback.
User testing at this phase consisted mostly of the following dialogue:
AUTUMN: Pretend you just opened a mysterious weather app on your phone and see this.*shows screen*AUTUMN: What do you think? What do you do?USER: Well, I would...*user explains*AUTUMN: Ah, okay, so then you’ll see this screen. What do you think and do now?
Prototyping Takeaways
After multiple mini-rounds of showing prototypes to users and revising my paper screens, I had a better sense of how to create a weather-deciding process that offered the right balance of guidance and freedom.
My biggest breakthrough was the idea of themes. Allowing users to select a weather theme (Tropical Paradise, anyone?) would simplify their first touch with the app while giving them agency from the very beginning. And if they chose not to customize, great weather would still be the default.
Prototyping also reinforced that numerical information should be kept to a minimum. Descriptions and visuals made users more confident that they understood what kind of weather they would be getting.
Refining the Design
With themes and user feedback in mind, I began creating some basic wireframes in Sketch. Here’s the flow I initially came up with:
Although users responded well to the general app flow — choosing themes which could be customized — there were some key areas that needed revision:
- Originally, I had users select three themes at the outset. But some users preferred to keep the same theme all day! They could delete the extras, but why make them? I decided it was better to begin with just one theme, and let the customizers add more if they wished.
- The main schedule page was what took me the longest to get right. My initial way of having users dictate theme duration by resizing cards on a fixed-length timeline that also showed hourly temperature and allowed users to edit, add, delete, and reorder themes — well, getting all of those UI elements to play nicely together was a bit of a challenge.
Reworking the schedule:
In my attempt to better delegate features to specific screen space, I made theme card sizes static and put order/duration editing on a separate timeline page. I also moved hourly temperature to a horizontally-scrolling card at the bottom of the page, leaving the top area just for themes.
While these changes did help declutter the UI, it wasn’t the final answer. Let’s pause on that for now though, because I want to cover something else:
Content
Somewhere in the midst of my page structuring quest, I realized I needed to start getting specific about the content.
I already knew the structure of the content: themes. But what elements would themes include and how would users customize those elements? I knew that a narrative approach would provide a better experience than tons of numerical data, but which words would best facilitate the process?
Because content is integral to an app’s entire experience, I figured narrowing it down would also help me finalize the UI.
So, I consulted my discovery research where I had learned which weather variables users most wanted to customize. For the sake of simplicity (and safety) I thought it best to skip special events and natural disasters for the time being.
Temperature, sunshine, rain, snow, wind, and humidity were the final six customizable weather elements.
Depending on the theme, I then gave each element one of five possible values: none, little, some, lots, or max. The one exception was temperature, something that I did think was best expressed numerically.
Though not objectively quantitative, these values are intended to quantify in some sense. They key is that they are subjective quantifications that allow users to attach their own meanings:
AUTUMN: What comes to mind when I say "lots of rain"?USER H: Loud enough to hear it on the roof or the windowsUSER J: Just a decent amount of rainUSER G: Blackish skies and the rain is heavy and loud and we have to get a bucket to catch the leaksUSER S: The first thing I thought of was a rainforest
Whatever these users imagined, it wasn’t a number of inches. Let’s assume that once weather manipulation is technologically feasible, I would indeed perform the necessary research in order to match users’ mental conceptions with actual inches, percentages, and miles per hour.
As for picking/naming themes, the goal was similar: Create narratives that users could easily imagine and then fine-tune according to their subjective weather interpretations.
Final Iteration
Alright, time to get back to those final design changes.
After all my efforts to simplify the UI by bringing features out of the main schedule, I ended up reincorporating a different kind of timeline AND the entire theme customization feature back into the main schedule.
One reason for this second change was because I learned in later stages of testing that people wanted to reference their themes in context when deciding whether to customize and during customization itself.
So how did it all come together? Let’s break it down:
After a user selects their first theme, they may customize it, or else publish immediately:
Remember how one of my initial design goals was to make the quickest path to perfect weather apparent? After opening the app for the first time, it takes as little as 3 clicks for a user to complete the weather-deciding process. Hopefully that’ll drive up my success metric!
Theme elements are independently customizable. Can it snow on a warm day? You bet:
While the app needs to be practical, the weather doesn’t have to be. Users have full freedom to create whatever crazy combinations they wish. And if they want to play it safe? Default is always an option.
Added themes go to the bottom of the schedule. Users may also switch out or delete themes:
Since the weather day is 12 hours long (8am to 8pm), added themes must “steal” an hour from the first available theme above it. Switching themes, on the other hand, always preserves the length and schedule position.
The effects of reordering or changing theme length are mirrored in the hourly view:
Although the theme cards themselves are no longer physically resizable, users can still drag to reorder themes and choose when their themes start and end using the side arrows on the left.
Weather happens the following day by default, but users can always select a day that works better:
Date and location is set to the simplest thing that makes sense: tomorrow in your current city. But hey, if you want to make weather next week for your friend that lives across the globe, go for it!
Annnnd, we’re done.
Wow, if you made it to the end, thank you for reading my first ever article on Medium! I would love to hear your questions and comments, as this is also my first UX case study for a digital app.
You can see more of my design work at autumnbasinger.com.
And of course, don’t forget to keep a lookout on your home screen for a new kind of weather app. :-)
