1. Introduction

For the 3rd project of our UXDI7 course, my team and I redesigned the Skyscanner mobile app on iOS. Skyscanner is a travel fare aggregator that gets its users the best deals when booking flights, hotels and cars. 
 
In selecting the app, we wanted an app that was both widely used and belonging to a recognisable company. Skyscanner definitely fit the bill as a leader in the travel fare aggregator industry.

Fig 1.1, a Skyscanner app ad.

This was a challenging app to re-design. Problems were likely relatively insignificant and specific given that it was a core piece of technology for a mature start-up (that was acquired since last year) in a competitive space and had an Apple store rating of 4.9/5 (as of 9th July 2017). To deliver greater user value, the overall research direction focused on exploring and validating possible features to introduce in addition to possible unresolved problems the app might have.

2. Research

On the 1st day, besides planning the project, we undertook preliminary research that was easy to search online and could be done by ourselves to get a sense of the potential problem. This would enable us to better decide how to structure the questions of our user interviews given the limited resources time and people-wise to conduct them. 
 
This included;

  • Learning what business needs we need to factor into the app design by learning about Skyscanner’s business model, the purpose of the mobile app in relation to the website, and the brand guide.
  • Finding out how Skyscanner compared to other potential competitors such as Kayak, Expedia and Momondo by conducting competitive analysis on their UI and the available features.
  • Finding out what aspects of the app users were still dissatisfied with or felt were missing by looking through Apple store reviews of the Skyscanner app.
Fig 2.2, Competitive Analysis and Online User Reviews.

We discussed our findings when we came back. We divided the questions into 4 sections;

  • 1. when and how users used travel apps; to identify the context and motivation for their behaviour,
  • 2a. pain points in general with the app; to ensure we did not miss out any potential problems,
  • 2b. pain points with respect to specific problems; to validate the value of the specific features we had in mind of introducing based on the preliminary research,
  • 3. basic usability testing; to discover any additional UI redesign opportunities by making purely qualitative observations.

To ensure we had a large and diverse enough user base to collect our user research from, we collected data from 3 different age categories (18–25, 26–35, 36–45), with a roughly equal split between male and female travellers. Additionally, given that the app already had significant traction and a user base, we chose to gather data only from those who had used the mobile app before to ensure that they could highlight specific problems we could solve. In total, we interviewed 11 users.

3. Consolidation

Fig 3.1, Affinity Mapping in action and zoomed out view of completed map.

Once this was completed, we organised our qualitative data via the process of affinity mapping. This mainly consolidated into 4 broad I-statements of their pain-points that validated some of the features that we sought to introduce and allowed us to prioritise them for development.

Fig 3.2, Personas “Jason” and “Mandy”

Based on our findings we created 2 personas that distinguished themselves based on how much time and money they were willing to invest in travel planning;

  • a primary persona called “Jason”; a busy manager who prioritised saving time through ease of quality booking followed by finding cheap deals.
  • a secondary persona called “Mandy”; a budget conscious student who prioritised stretching her dollar by finding the cheapest possible deal.

The personas were divided along such lines as we found that users from the 18–25 group went to great and diverse lengths in order to get the cheapest possible prices. This included but were not limited to

  • changing the VPN when booking tickets,
  • creating excel sheets to find specific seasonal promo windows,
  • checking across multiple websites/platforms to see variations in prices,
  • last minute hotel bookings to try to get a better deal or free lodgings.

Although this gave us great cost-cutting travel ideas; this lead them to have distinct I-statements not easily grouped with other users. Their priorities also meant that the personas interacted with Skyscanner in 2 distinct ways. While Jason users tended to be exclusively mobile users, Mandy users tended to use mobile to explore options and gauge prices and used desktop to complete bookings for flights and sometimes hotels. 
 
Jason was made the primary persona for this project as an app re-design would give him the most value given his exclusive use of mobile to access Skyscanner (unlike Mandy). Additionally, it would be easier for our team to measure the returns of investment and make the business case as Skyscanner’s revenue is generated through successful bookings. Improving experience quality for Jason users would directly lead to more bookings directly through the app. In contrast, improving experience quality for Mandy users could lead to more booking via either the desktop or, to a less likely extent, the mobile app which would make it harder to quantify the impact of any redesign.

Fig 3.3, our Primary Persona’s Customer Journey Map when it was in a low-fi stage…
Fig 3.4, … and when it was completed.

In order to visualise Jason’s behaviour and examine how our proposed features were relevant to it we created a customer journey map. By mapping out his actions, his key concerns, and thus the opportunities generated at each stage, we could understand what problems our features should solve and where our target user group should encounter them as part of their usages of the app.

4. Ideation

We had to abandon some features as we could not ideate a manner which we were sure could be easily executed from both a UX and backend perspective (such as the desire for more personalised recommendations on when to travel). Ultimately, these were the following 5 features which we chose to be incorporated into the prototype;

Fig 4.1, some of the features we implemented, as seen in the presentation slides.
  1. Showing more complete reviews of hotels; rather than just aggregated scores or comments.
  2. Having a follow-up invitation to book hotels after booking flights.
  3. Finding the best deal within a travel window; rather than for fixed arrival/departure dates.
  4. Price alerts only when the price drops below a minimum; rather than when it has changed.
  5. Allow the “bookmarking” of hotels to return to at a later date.

We decided to de-prioritise creating Mandy’s customer journey map due to the lack of remaining allocated time after creating Jason’s customer journey map. However, to further establish user value generated by the selected features, we examined how they could solve the needs of Mandy users. We found that with the exception of the 1st feature (flight-hotel booking integration), the features were mutually beneficial because they either;

  • helped both Mandy users and Jason users find better deals more conveniently (#3 and #2) or
  • still served Mandy users’ needs even if their original purpose was to serve a different need of Jason users. (e.g. #5. Jason’s desire for more detailed reviews to prevent bad booking experiences enabled Mandy to make better trade-offs by better understanding of what she is sacrificing for in exchange for a lower price.)

We could thus proceed with confidence, at least for the remainder of the design sprint, with focusing exclusively on Jason’s persona.

5. Prototyping and Usability Testing

To prioritise time our team split into 3 groups that worked concurrently.

  1. The product team focused on creating the prototype.
  2. The presentation person focused on consolidating the user research (personas and customer journey maps) and worked on the presentation.
  3. The usability person (me) focused on creating the scenarios and the methodology for the usability test as well as run them through before meeting actual users.
Fig 5.1, Some of our usability test participants.

To showcase improvements in user value we decided to conduct usability tests for both the new prototype and the existing application and to compare the time taken to complete tasks enabled by the new implemented features as well as their success rate. To ensure they fit Jason’s persona we chose 5 users who fell within the range of 26–35 and had experience using travel apps before. We recorded the process using the Silverback App.

6. Iteration

Fig 6.1, exact statistics and quotes from users.

Results were positive. When comparing the execution of key tasks between the existing app and the redesigned prototype; there was a 31% increase in the completion rate and a 43% reduction in time taken to accomplish successful tasks. User feedback was additionally especially positive for the hotel booking experience.

Changes made to the prototype were in response to user’s feedback relatively minute; such as by making the invitation to book hotels look less like an external advertisement to the users by including a Skyscanner logo to it or creating a space for more traveller submitted photos to give users a more comprehensive idea of the hotel experience.

However, an exceptionally long discussion centred around how to configure the solution for flexible travel plans searches in a way that would most benefit Jason users. Specifically, it was on

1. whether to give users the option to search for trips with additional configurations, such as a flexible travel duration range and the ability to search based on shortest flights only, on top of having a flexible arrival and departure date as well as

2. how to intuitively create, and where to place, a way for users to input their search preferences.

Fig 6.2, flexible flight dates feature (#2): original, iteration 1 (pre-usability test) and iteration 2 (post-usability test).
Fig 6.3 A discarded concept to enable more options for flexible user date searches.

We eventually decided to address only Issue 2 by changing the user flow (by getting rid of the need for a dropdown filter), feature location and labels. For Issue 1, we did not give Jason the option to search with flexible duration dates. This was because even though some of the users would have wanted this feature in theory and it was possible to create designs and give precise technical specifications to the backend developers, we did not specifically validate it with them during the 1st round of usability testing and did not have time to do another.

7. Prototype and Presentation

We used marvel and sketch to efficiently create a high-fi prototype that faithfully kept to the brand guide required by Skyscanner. Axure was also less relevant as there were no specific UI issues which we wanted to fix and thus less need to sophisticatedly replicate interactions.

Prototype link:
https://marvelapp.com/2c8h136/

Presentation link: https://drive.google.com/file/d/0B_1u1744mqULLTRNVDhPZklLX2c/view?usp=sharing

Fig 7.1, Our uniformed, brand-guide aligned presentation.

8. Next Steps

Moving forward from the prototype and the presentation, we could build on the user research by implementing more advanced features that could fulfil the needs of users to a more comprehensive degree. 
 
For example, the desire for a more integrated, all in travel planning platform that we discovered in our user research led us to introduce feature 1 to make the transition from flight to hotel easier. Other features that we could explore introducing, based on competitive analysis and suggestions from users, include integrating other types of bookings such as cars or information relevant to booking decisions such as their available dates based on their calendars.
 
Many of these features were de-prioritised this round because there were easier, more relevant, high impact solutions (which we implemented) and because we did not know Skyscanner’s developer capacity. However, they would make interesting follow-up steps given the time and resources. 
 
Additionally, we could have another project that aimed to solve Mandy user’s more unique needs as well as to explore how the mobile app can be better integrated in terms of data viewing and collection with the website. This goes beyond the backend issues discussed during the presentation and examines how we can improve more travel bookings on Skyscanner, across mobile and web platforms, for Mandy users. 
 
It would have been difficult to ensure a comprehensive job if we had to concentrate only on designing the mobile app, but a subsequent project that would potentially allow a redesign of the website as well would be interesting.

9. Learnings

I learned greatly from a well-rounded team with a diverse strengths as well as even and patient temperaments.

  • Being our first team project, we learnt many ground rules which we developed as part of our internal communication process. We made it a point to understand people’s frame of references during discussions, communicate regularly and responsively our progress and to resolve differences of opinion with respect to the persona or simply “KIVing” (Keeping in View) low impact/high differences topics.
  • I got a better grasp on effective project and product management. Our team ran a very focused project given that we anticipated that we were not expecting a significant re-design of the app. I greatly appreciated engaging and contributing to the collective thought processes of what processes, research and features were to be prioritised and de-prioritised. Deadlines were kept to mostly and unexpected delays were well accommodated. The division of labour utilised our respective strengths effectively and enabled us to work concurrently effectively.
Fig 9.1, creating visualisations of the flexible dates search process by tearing up paper.
  • I improved my capacity to communicate and think visually. Although I did not take part in the creation of the prototype directly, I made it a point to always try to sketch out suggestions for features and prototype editions rather than simply rely on verbal explanations or pointing. I also took time to observe the sketching and documentation processes of the graphic designers in the team.
  • I further honed my usability testing skills and user research skills; which continue to be my focus during the course.

Looking forward to the next one; and growing as I go along.

Fig 9.2, the Squad on the weekend; a blessing to have worked with them.
Show your support

Clapping shows how much you appreciated Joshua Wong’s story.