Sun & Moon Explainer
A connected astronomical experience for The Weather Channel: sun, moon, tides, and stargazing as one system.
Overview
On the Sun & Moon explainer for The Weather Channel app, I was the final design gate. I worked alongside the designers and the engineering team, and I was the last review before anything reached production across web, iOS, and Android. The direction was set: sun, moon, tides, and stargazing reframed as one connected astronomical system instead of four isolated modules. My job was making sure the version that shipped to 100M+ people matched that intent, and that where a build couldn't hold to it, the compromise was a deliberate call rather than a quiet drift.
The challenge
The Weather Channel app already showed sun and moon data: rise/set times, moon phases, illumination percentages, twilight types. Comprehension was low. Users could see the numbers but most had no idea what they meant for their day.
Terms like “waning gibbous”, “civil twilight”, and “illumination percentage” are inherently technical. The existing presentation leaned heavily on raw data and charts that required prior knowledge to interpret. Tides were treated as a separate silo from the moon. Stargazing data wasn't surfaced at all. We were serving science to hundreds of millions of users, and nobody was reading it.
The reframe
Meaning first. Data second.
Instead of leading with charts and raw numbers, every module had to answer three questions before anything else: What is happening? Why does it matter? When is it relevant? The chart stops being the product. The chart becomes the supporting evidence for a sentence anyone can read.
The second half of the reframe: sun, moon, tides, and stargazing aren't four separate features. They're one system, all driven by the same astronomy. Once that landed, the connections became the design.
At the gate
Charts paired with one human sentence
The design paired every chart with one plain-language sentence: the chart as evidence, the sentence as the point. In a build under space pressure, the sentence is the first thing that gets dropped. I held the line on it. A chart without its sentence didn't pass review. Where a surface genuinely couldn't fit both, the rule I enforced was to keep the sentence and simplify the chart, never the other way round.
Tides as a connected system, not a silo
Tides belong to the moon, driven by the same gravitational pull, so the design carried that connection through shared language and visual cues rather than a separate oceanography panel. My check at the gate was continuity: in the shipped build, did tides still read as part of the moon experience, or had they drifted back into their own vocabulary and layout? Keeping that link intact through implementation was the whole point of the decision.
Stargazing as a real use case
Stargazing depends on moon phase, illumination, and twilight timing, so the design treated those as the planning signal instead of secondary data. That meant real screen space for what can look like a niche use case. At the gate, my job was protecting that space when build pressure wanted to shrink it, and confirming the signal stayed legible on a real device, not just in the mockup.
No-data states that still teach
Astronomical data is patchy: coverage gaps, seasonal unavailability, location quirks. The design called for educational fallbacks instead of blank modules or generic errors. Fallback states are the first thing a pipeline skips under deadline, so they were the first thing I checked. Nothing shipped that dead-ended on missing data. A broken-looking screen at 100M users costs trust faster than a missing feature does.
Modular patterns across platforms and tablets
The system had to flex across geographies, seasons, data availability, and mobile and tablet layouts while staying consistent. Tablet was where builds drifted most, stretched up from mobile instead of designed for the screen. I reviewed each surface on its own terms: split-view map and explainer on tablet, chart legibility, reading layouts that suited the medium. Consistent never meant identical, and the gate was making sure each platform earned its own layout.
Impact
Shipped across The Weather Channel's web, iOS, and Android at 100M+ MAU.
Every build cleared a final design review before release. Nothing reached users with the explainer's intent quietly broken.
Clearer educational framing turned raw data into something users could act on.
Tides surfaced as part of a connected astronomical system rather than an isolated silo.
Stargazing emerged as a new use case for the app without adding feature bloat.
Resilient experiences during data gaps. No more blank screens or broken states.
A reusable explainer pattern (chart + human sentence + progressive disclosure) extended to other weather features.
Reflection
Good weather design isn't about accuracy alone. It's about translation. Users don't want raw science. They want meaning. Whether the moon will be bright enough for an evening run, when golden hour starts for a photo, whether tonight is good for stargazing, when the tide will be right for a morning walk on the beach.
The senior work here wasn't authoring a screen. It was owning the last mile: being the final gate on whether the thing that reached 100M people matched what the team designed, and making the call when the build and the design disagreed. Good design dies in that handoff if no one owns it. I owned it.