About Fravz
The Weather Web App
This is Fravz, a weather forecast web app for water sport enthusiasts. The goal has been to display complex weather data in an easier and more comprehensible way than competitor (web) apps, but also provide the user with additional data for their specific water activities. The ‚mobile first‘ project has been part of my 500+ hours Careerfoundry Immersion Course.
The challenge:
Bring clarity into complexity
Tools used:
The Approach
Challenge • Action • Results
Not only will I show you my way of working, but also give you insights into my way of thinking.
I divided the DESIGN THINKING process into 6 main sections.
2. Making sense out of the information
In each section I will proceed as follows:
CHALLENGE
ACTION
RESULT
First, I will give you an overview of the CHALLENGES I had to face during the process.
After that, I will describe a selection of the ACTIONS I took to overcome the challenges,
to finally let you in on the RESULTS of the actions.
This, however, is only an excerpt of a more extensive DESIGN THINKING process the design went through. Also, the process itself is not necessarily linear, but rather simultaneous and iterative.
1. Take a look around
CHALLENGE
When you are asked to provide a solution to a problem, it is natural to want to give the most obvious answer right away. The Dunning-Kruger-Effect implies, that this strategy might not be very successful. We don’t know what we not know. To enhance our creative abilities we can combine thoughts we already had or broaden our knowledge palette. The first way to go about it, is already inherent to the Design Thinking process. The latter we have to take care right now. So let’s take a look around ,make Sokrates proud and ask ourselves:
What is the problem and it’s environment?
What solutions are already out there?
What are the strongest competitors?
What are our business requirements?
Who are our users?
Problem Statement
Action
Competitor Analysis
Action
Business Requirements
Action
Interviews
Action
The bigger picture
Results
Problem Statement
- First insight into the matter
- Getting an overview of the issue
Having a starting point for the process
Competitor Analysis
Best-practices to build upon
Confusing and cluttered UI of competition
Unclear (and/or wide) target audience
- ROI heavily reliant on direct advertisment
Business Requirements
UX for high changing habbit barriers
UI with reduced information load is a competitive asset
USP through direct user appeal
USP through usage context driven data concepts
Interviews
Each water sport has unique information requirements
Users wish to have more information on the activity spot
Desire for a holistic information tool
2. Making sense out of the information
CHALLENGE
After this gathering process, we want to make sense out of the information obtained and use it to provide us with a foundation for our future design decisions. We need to lay a cornerstone for our Minimum Viable Product (MVP). So again, we need to ask ourselves:
Are there any associations between the gathered chunks of information?
Can we deduct any arche types of our users?
What tasks do our users have to do to achieve their goal?
What steps do they have to take to complete these tasks?
Affinity Mapping
Action
User Personas
Action
User Journey Maps
Action
The design foundation
Results
Affinity Mapping
- Satisfaction about weather apps correlate with the specific water sport activity
- None of the existing apps provide water sport specific data
- None of the competitor apps provide data on the local water spot distinctiveness
User Personas
Concise description of potential users
Personifications for different user requirements and needs
A focus for the MVP development
User Journey Maps
Default display: Summarized and easy to read weather data
Switchable to: Detailed and extended weather data
Add lifeguard recommendations in written form
Add data on eyesight, thermal lift and spot distinctiveness
Offer a data gathering and storage feature
3. Sculpting the Prototype
CHALLENGE
I already had a good grasp on WHAT information is presented WHEN to the user. But, how to design a prototype with limited TIME & RISK ressources? At this stage of the project, it is important to keep it simple (time) & agile (risk), because things will change. The DESIGN THINKING process helps us to achieve this.
note { sketch: stick with the MVP and sketch & draw as many solutions as time allows in low- and mid-fidelity wireframes !important; }
Questions that need clarification are:
What is the Information Architecture?
What could a navigation look like?
What information is displayed on each screen?
What items are displayed on each screen to transport the information?
Sitemap (r)evolution
Action
Mobile Navigation
Action
Building The Prototype
Action
The 1st draft
Results
Sitemap (r)evolution
Clear Information Architecture
Distinct feature areas
Clear ‚logged in only‘ areas
Mobile navigation
Easy and intuitive navigation
Web app conform
Technically and financially reasonable solution
Building the Prototype
Streamlined user journey
Reduced information load
To the terms and conditions of the specific water sport adapted UX
Improved information overview
A prototype for further iterations
4. User Testing and Revision
CHALLENGE
Now that we have our first prototype, how can we improve it? Design Thinking is also about the iteration and testing of the MVPs. But how to gather and organize the information? Among other methods I did two things. Asking the users in User Testing and asking a couple of fellow UX Designers for their feedback (special thanks to Francois; see you next year at the conference). After each step, I made revisions to the prototype accordingly.
Are there any errors?
Which errors need to be fixed first?
What do users think about the solution?
What are areas of improvments?
How to adapt for a better UX?
User Testing
Action
Peer Feedback
Action
Refining the Design
Results
User Testing
Improved UX through optional onboarding (onboarding had been client’s request)
2!! page solution for forecast feature improves UX
Changed location of ‚choosing forecast period‘ buttons
Changed location of ’show details‘ buttons
Improved structure and readability of ‚recommendations‘ area
Revision of forecast icons
…
Peer Feedback
Final background for the prototype
Increased contrast between information cards and background
Improved font sizes and text readability
Redesign of navigation menu
Redesign of the ‚Fravz‘ home icon (for fun)
…
5. Documentation
CHALLENGE
How can we communicate our design style to stakeholders and make data on design properties accessible to developers in an efficient way? Due to this is a rather standardized task, I will keep my expositions short.
How to provide stakeholders with an overview of the design style?
How to hand off design element properties to the development team?
Style Guide
Action
Hand Off
Action
Deliverables
Results
Style Guide
Style overview at a glance
Hand Off
Extensive data export for development
6. Final Version
The Weather Web App
This is the moment you have all been waiting for. The final prototype.
WHAT? You don’t like the dark version? Well, then check this out! Modern, ey?
You want to experience the prototype yourself? Sure, just click on one of the buttons below.
