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.

1. Take a look around

2. Making sense out of the information

3. Sculpting the prototype

4. User Testing and Revision

5. Documentation

6. Final Version

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.

„Design is never finished, only abandonned“

Let’s Work Together

TELL ME MORE ABOUT YOUR PROJECT
Let’s talk