01 Discovering & Defining the Problem

03 Ideation & Prototyping

04 Testing & Iteration

05 Refining the Design

I gathered information about several competitors like magicseaweed, windfinder, windguru, windy & glassy to see how they approach the matter, to spot weaknesses in their user experience and to identify underserved opportunities in the market.

My goals were to make better-informed decisions and to develop a strategy that makes my product stand-out against competitor offerings. Therefore, I used different methods: Competitor Profile, SWOT Analysis & UX Analysis.

_ Create a forecast app that allows water sport enthusiasts to pick up 

   accurate & reliable data they need at a glance

In order to gain deeper insights about Vela’s future users I interviewed 4 participants, who...

  ... exercise a kind of water sport regularly,

  ... have some experience in checking wind, wave and weather conditions,

  ... use mobile applications or websites regularly.

Additionally, 50 surveys were completed. Participants were recruited on social media in groups dealing with water sports.

The personas Jan, Annika & Tobias are exclusively based on the data from my interviewees & participants. Discussing projects using personas is more effective than talking about a general user audience. They serve as a communication tool and allow to stay much more focused during the design process.

User journey maps are another valuable & effective support in empathizing with the future Vela users and in visualizing the process a user goes through to accomplish a goal.  

In order to dive deeper into the processes, thoughts & emotional experiences users run through while using Vela, I created user journeys for each persona. 

User flows help to discover what pages or screens of an app are needed before entering the information architecture phase of a project and are informed by personas. 

It turned out that the user flows of Annika & Tobias were quite similar, which led to the question, if these two Personas are distinctive enough or if they can be combined in one.

I conducted a card sort session to check whether my assumptions about connections and structures related to those of the future users of the app.

The data confirmed some assumptions and helped to clarify others, that didn‘t appear as clear to me.

It led to seeing coherences in a different way and resulted in changes in my sitemap. For example, arranging the „Community“-functions under „Spot information“ or dissolving the utility navigation on the home screen and assigning these functions to „About“ and „Settings“.

Another significant issue was to think about the difference between importance and frequency of use when arranging the functions in a sitemap - a user might estimate a function very high, but how often will he/she really use it?

For Vela I started with low-fidelity paper prototypes to focus on the core structure and navigation of the app, instead of wasting time on visual design features or complex functions.

Also, I build a digital mid-fidelity prototype, which allowed me to show more detail and to get closer to the placement of UI elements and the basic visuals.

In the next step I created a high-fidelity prototype, that expressed how the application was meant to function. This upfront work took quite a bit, but was the basis to gain user feedback in following tests.

In this phase, I aimed for testing the prototype to find out how users attempt to complete tasks using Vela and to get insights about pain points arising during the test. 

I created a usability test plan and a test script, which helped me keep the structure of the conversation consistent throughout all tests to get valid and valuable information and insights that help to set the design direction. 

The tests took 30-45 minutes each. In case the participants didn’t navigate correctly, I guided them to the right page and still asked them for their impressions and expectations on this. If I had just accepted the task as not completed and hadn’t asked further, I would have missed out a lot of valuable feedback.

Preparing a performance overview sheet as a support during the tests was very helpful in terms of comparing, if and to what degree the tasks were accomplished and how much help was offered during the test. It made me think about in advance, how I can support participants without giving it away.

Besides that, testing was very, very helpful in gaining insights about how users think, what they expect and how this differs to my own mental models – so that was kind of healing.

Main problems that popped up in the test:

_ Too much navigation (submenus were considered superfluous)

_ Navigation to notifications & preferences was not clear enough

_ Shifting & deleting spots was considered too tortous

_ An important parameter was missing

The results from the usability testing regarding the navigation have made me think again about the nature of the navigation and led me to finally say goodbye to the drawer menu in favour of a bottom navigation.

The main reasons were:

_ I reduce to amount of topics, that before filled the drawer menu, so that

   I was able to set up a bottom navigation with three options.

_ The slimmed bottom navigation provides more clarity and easier handling

   for the user.

With the updated prototype I conducted an expert review to get more eyes on the project and to make important and iterative refinements. 

This feedback loop was a great tool to become aware of all the little mistakes that slip under the radar, but also to get different perspectives on how the designs I created are perceived. 

A lot of critical points and mistakes can be filtered by such an expert round, even before starting tests with users.