A weather app for water and outdoor sports users
Making complex weather data simple and usable
Origin: UX course project
My role: Entire process including research, user testing and iteration
Duration: 3 months
Platform: Responsive web app (mobile first design)
Outcomes: 10% faster task completion, increased user confidence in decisions
RESEARCH
What I learned from competitors
I analysed leading weather apps used by sports enthusiasts like Windy.com to understand what works and what frustrates users.
As a contrast I also looked at some simpler, everyday weather apps like Pixel Weather.
Windy.app
Windy.com
Windfinder.com
Pixel Weather app
Through competitive analysis, I identified three usability barriers and three potential solutions:
* Cognitive load: Dense layouts intimidate casual users and slow decision making
* Hierarchy: No clear priority in data presentation
* Accessibility: Tiny text and colour-only coding excludes many
* Customisation: Allow users to add what they need and remove what they don't
* Dashboard: A dashboard of modules like on Pixel Weather
* WCAG AA rating: Contrast, text sizing and icons with semantic colours
To validate these observations and uncover deeper user needs, I conducted qualitative research with the people who actually use these apps daily.
Voices and patterns from users
I interviewed 6 outdoor enthusiasts (windsurfers, hikers, swimmers, cyclists) and used affinity mapping to synthesize their feedback into actionable patterns. Four critical themes emerged:
Switching between apps → fragmented planning
“I use Apple Weather each day… for windsurfing I use Windfinder.”
“I compare two apps to get a feel for the probability of bad or good weather.”
Unclear sources → lack of confidence
“You have to know and check which model is best for your region.”
“I didn’t know swell was measured offshore.”
Map animations → hard to focus
“I’d prefer a static series of images for precipitation.”
No personalisation → irrelevant details slow decision making
“Today’s forecast at my location isn’t what I want to see first.”
PREPARE
The core problem: Water and outdoor sports users need faster, more accessible ways to interpret complex weather conditions when planning activities.
Success metrics: Reduced task completion time, increased confidence in planning decisions, decreased app-switching behaviour.
User centering my designs
I distilled insights from all six interviews into two personas representing distinct user needs and pain points that will form the basis of my designs.
Ari Riviera
Weekend Water Warrior
About: 42, Hamburg, Senior Accountant, married with kids.
Goals: Quickly compare conditions across local spots, customise my dashboard, view trusted forecasts side-by-side on an interactive map.
Frustrations: Constantly switching between multiple apps, overwhelmed by irrelevant data, difficulty reading some visuals due to colourblindness.
Naomi Simms
Risk-Conscious Outdoors Enthusiast
About: 26, Queenstown, Teacher, single.
Goals: Clearly labelled data sources, check multiple locations across various timeframes, clear risk indicators e.g. water level.
Frustrations: Manual cross-checking of data sources is time-consuming, rapid map animations are disorienting, fixed data patterns don’t match her needs.
Simplifying complexity
Weather apps contain dozens of interconnected data points (forecast data, weather models, locations, time ranges). To avoid creating another cluttered interface, I used Object-Oriented UX (OOUX) to map out core objects, their attributes and relationships.
Outcome: A clear content model that informed my wireframing.
Design System Approach
To iterate quickly while maintaining consistency, I built a scalable design system using Atomic Design principles in Figma. This included:
* Text and colour styles applied systematically
* Assets library (icons, buttons, patterns)
* Component library (buttons, modules, time slider)
Impact: Made iteration cycles possible without design debt.
Addressing accessibility
Considerations:
* 14 pt minimum text size with larger values for critical data
* 4.5:1 text contrast ratio minimum (WCAG AA)
* Semantic colour system reinforced with icons
* Summarise button for screen reader users and on-the-go planning
* Simplified language for complex weather concepts
These weren't added at the end — they shaped every design decision from wireframes forward.
Validating Splashboard's structure
I validated a sitemap through a remote card sort with five target users. The results aligned well with their mental models, and I used the feedback to refine the sitemap — for example, grouping related actions in the menu by priority.
DESIGN
Throughout the iteration process I used a cycle of design > prototype > user testing > improve.
I conducted three rounds of moderated and unmoderated usability testing with 18 participants total, iterating between each round to address critical issues.
Round 1 Results (6 participants):
✓ Users grasped the dashboard concept immediately
✗ 4/6 struggled with the time slider interaction
✗ Location context wasn't clear enough
✗ Some features were completely missed
I prioritised fixes based on severity and retested the most critical flows.
Home screen
Top Menu: Dashboards, Map & Search, Menu
Dashboard cards: Add, Remove, Rearrange
What I learned
* Set semantic colours before CTAs to reduce confusion
* Long swipe gestures are challenging for some users
* Clear CTAs reduce reliance on tooltips
Dashboards
Data modules: Add/remove/rearrange wide range of data sets
Severity warning: Shows moderate/high risk
Time slider: Observe changes hourly or quickly scrub through whole days
What I learned:
* CTAs must be visible without scrolling
* Module variety prevents scanning fatigue
* Innovation works best within established mental models
Map & Search
Map: All main actions within one click, e.g. search, units, rain, wind
Models comparison box: Compare 3 models side-by-side with an agreement score.
What I learned
* Add what's needed - remove what's not
* Adjust HSL values so red/yellow/green work for colourblind users
* When in doubt, simplify
Final product snapshots
Splashboard gives users like Ari and Naomi a customisable dashboard that surfaces only the weather data relevant to their specific sport and location — with clear visual indicators for risky conditions.
Core features:
* Drag-and-drop dashboard modules
* Multi-model forecast comparison
* Risk-based colour coding
* Responsive design (mobile-first)
Splashboard on desktops
Splashboard is fully responsive and designed mobile-first to prioritise clarity and focus. On desktop, the experience stays consistent — but makes use of the larger screen, providing all users' chosen data in one place.
REFLECT
Reflection and next steps
What worked:
* OOUX provided a strong foundation for complex information architecture
* Iterative testing caught major usability issues early
* Building a design system enabled rapid iteration
What I'd do differently:
* Conduct contextual field research (observe users planning trips in real time)
* Validate a business model e.g. two dashboards before a paywall for power users
* Spend more time considering edge cases like long place names, data blackholes
Future roadmap:
* AI weather interpreter (helps beginners understand data and set up dashboards)
* User-requested modules (driven by analytics)
* Community feedback integration