top of page

FLY UX

Brief: defining the user flow,the navigation and interactions of the single use case (Booking a flight on the FLY UX mobile app).

Target audience's motivations: be able to book a flight  effortlessly in just few clicks from  the comfort of their own homes or on the go.

Business vision: increase conversion, costumer retention and satisfaction.

DISCOVER(diverge):

​

In order to discover and understand the problem as well as the users main goals  I started by gathering as much as qualitative and quantitative data possible. 

User testings were conducted on 2 competitive airlines websites and apps while recording the users actions and thoughts. 

In fact I asked the users to verbalise their honest thoughts when they were trying to use the product.

​

​

PLAYBOOK: USER INTERVIEWS, USER TESTING BY USING COMPETITIVE AIRLINE COMPANIES, COMPETITIVE BENCHMARKS .

The softwares used for the process were “Reflector3” in order to mirror the mobile phone’s screen on the pc and “Silverback” in order to record the whole process.

​

 I ran an affinity map and costumer journey map in order to interpret and analyse the unstructured data gathered.

​

INSIGHTS:

I detected that the main pain points were:

  • flights informations not very clear.

  • too many different pages showing extras items to add or skip (it is a waste of time and not necessary).

  • the costumer doesn't like to discover the total amount of the price  only at the end of the process, the lack of the Paypal payment method is restrictive.

​

The main users goals :

​

  • Check for flight availability and prices

  • Pay securely

  • Get it done quickly

  • Be able to login on own user account 

​

​

​

​

​

​

DEFINE(converge):

​

With structured data on hand I defined the possible  information architecture and the ideal user journey in booking a flight.

I stated that the navigation should have been linear; the user flow should have been easy and effortless.

I defined the number of different screens that really matter.

To test out my assumptions I ran an online survey.

​

Special focus was given to the creation of a single " Add Extras" page by trying to render it less cumbersome and to the payment process as it is stated that 80% of mobile users abandon checkout related to card issues or security  fears.

​

​

PLAYBOOK: ASSUMPTION MAP, THE GOLDEN PATH, DESIGN PRINCIPLES

SKETCH (diverge)

 I sketched many variant solutions as possible such as different interactions and microinteractions:

how the system behaves, how it respond to actions, how communicates results and how it helps to fulfil intentions. 

PLAYBOOK: CRAZY 8'S, SOLUTION SKETCH

 

​

​

DECIDE (CONVERGE)

In this phase I decided to narrow down the various  choices to one solution; based on this 

 I created high fidelity wireframes: 

​

  • I reduced the number of screens 

  • I added a little tab with the price that automatically updates when items are added.

  • I decided to incorporate a progress bar in order to validate user's actions.

  • I made sure that the Paypal and Login options were available and at the same time increase the perception of security ( limited inputs, asking what actually is required, use auto format for number fields, use of credit card logos).

  • I set the "info details" as clickable link to view in a separated page.