Native App for trivago

Native App Project Cover

Role: Lead Product Designer
Year: 2018

In 2018 I worked on a complete redesign of the trivago app used by millions.

The overall project lasted for 1 year and although the bulk of design and development was done in 6 months we had to tweak and improve the product in order to accept it from a business perspective.

As a lead product designer it was a big and exciting project, as it gave me and the team the opportunity to design it from a clean sheet and think holistically of the whole product and flow.

I explained how we initially pitched the app vision in a Medium article. As a result of a successful concept we got green light from management to work on something the whole team wanted. My role at that time was to create a complete flow and a high-fidelity prototype that collected all the feature and improvement ideas from the team.

Challenge

To explain better the challenge and goals of the redesign I have to briefly describe trivago's business model: a metasearch that compares hotel deals from different advertisers (websites where you book the hotel like Booking, Expedia etc.). You don't actually book on trivago.

In terms of a simplified version of the booking journey (graphic bellow) this is the area where the company wants to focus but also to extend the boundaries in a smart way.

graphic of trivago a hotel booking experience
trivago company focus and positioning in a hotel booking experience

Goals

  • ∙  Increase trivago's business value depth. Instead of sending travellers quickly to advertisers and maintain company's short term revenue strategy, try to explore more on the quality of these visits and booking conversion.
  • ∙  Maintain core trivago business KPIs. Although the priority of short term revenue metrics decreased we still had to keep them in mind and don't go beyond a reasonable threshold.
  • ∙  Give additional value to travellers. What is the reason to download and keep the app for a branded user instead of just using the mobile web version?!
  • ∙  Integrate well with Apple and Google platforms. Respect the patterns and guidelines to make users feel at home but maintain company's branded experience.
  • ∙  Create a flexible information architecture. In order to be future proof for modifying or adding new features. Something that we always struggled with the old app: most of the new features had to be "squeezed" in the wrong place and user flow.
Cross-functional app team during ideation workshops and design sprints
Cross-functional app team during ideation workshops and design sprints

Team

Just like when we made the app vision, the whole team (around 40 people) divided into mini cross-functional teams that ideally had to include one: Product Owner, Product Designer, User Researcher, iOS Engineer, Android Engineer and QA person.

Because the main features were already defined during the vision brainstorming sessions and design sprints the teams already:

  • ∙  Analysed the old app and identified product and usability issues. (using trivago personas developed by User Research and Design)
  • ∙  Analysed direct and indirect competitors
  • ∙  Ideated and conceptualised improvements and new features for the app

This time the cross-functional teams had to take ownership of individual features and create a concept with realistic constraints from technical and timeline point of view.

Role

As lead product designer my role was to:

  • ∙  Coordinate mobile designers (4 at that time) that were working individually for their own "feature teams"
  • ∙  Represent mobile app design in key stakeholder meetings
  • ∙  Work on a new design language
  • ∙  Be part of the "Search results", "Hotel details" and "Deals" teams as main product designer because this is the most critical flow from a business perspective — the booking funnel
Minimalistic workspace

Prototype and User Research

After the teams worked individually and collaboratively to align on the correct flow from one feature to another as a result I created a low fidelity prototype. This prototype had 2 main purposes:

  • ∙ Visualise the complete flow and information architecture of the app so that the teams could adjust, redesign or remove specific features.
  • ∙   As deliverable for our first in-house user test to gather insights as soon as possible.
Native app wireframe prototype
Some screens from the wireframe prototype

Although the user test results were very comprehensive regarding each individual feature and step in the flow, the main learnings were the following:

  • ∙  There were no severe usability issues in the flow
  • ∙  The transition from the app to advertiser (booking website) was confusing
  • ∙  Hotel rating on the card was not visible
  • ∙  Calendar caused confusion among some users
Participant during a user research session in our lab
Participant during a user research session in our lab

We iterated further based on the learnings though some obvious issues were attributed to the fidelity of the prototype (no colours, no calendar transitions) and the nature of trivago's product (we send people to another website).

Next we decided to move forward with a pre-alpha build. It was made using mostly platform native elements. This way engineers could focus on the functionality and not wait for pixel perfect UI from designers. In the meanwhile the design team had time to work on the new app design language and components.

By creating the build we hoped to add another layer of fidelity with colours and with more refined interactions compared to the previous prototype made in InVision. We ran another user test, this time an unmoderated one with more people as we had a build where one could navigate and interact more freely.

The main learnings from the pre-alpha user research were the following:

  • ∙  No major usability issues were uncovered at this stage
  • ∙  Minor usability issues with Price Slider. Filter selection was confusing
  • ∙  There was a mixed reaction in regards to the booking flow and how this is aligned with the user's expectations of the product
Example of pre-alpha build screens for user testing
Example of pre-alpha build screens for user testing

Post research we decided to refine even further the build. The issues described in the second point were highlighted because of the rough state of the app whereas the point regarding the booking flow had to be analysed more extensively: We anticipated that there would be a slight shift in how trivago is perceived given the new flow (more steps, more content and information) but we assumed we were heading in the right direction as this was one of our initial goals — have better informed users resulting in more qualitative conversion.

Booking Flow and Hotel Card

Although I helped my design colleagues move forward different features of the new app I was the "design owner" of the booking funnel and will describe this particular product part. It's also the most crucial from the business point of view.

The booking funnel for us has the following screens:

  • ∙  Results with hotel cards
  • ∙  Hotel details
  • ∙  Child content for hotel details
  • ∙  Deals
  • ∙  Deal summary
  • ∙  Transition to advertiser

As first basis for prioritising the content in the flow we used a generative user research in combination with business requirements.

Generative research information provided by user research
Generative research information provided by user research

Regarding the hotel card (“item element” in trivago jargon) as we were always struggling with touch areas in the old app (way below the recommended 44 pt/dp) this time we went in the opposite direction and decided to take advantage of the hotel details screen and have the whole card one tappable area. The secondary level content was exposed then prominently in the details page in a form of an overview about the hotel (ratings, amenities, location etc.). More granular content had a dedicated child screen.

By doing this we followed our top level hypothesis: give users the right amount of information at the right time.

Booking funnel screens. First Iteration
Booking funnel screens. First Iteration

First Release

After all the necessary user research, refinements and iterations we decided to ship the new Android app on Google Store (5% A/B test). Although the final design language was not fully refined and the tech side not optimised we felt important to gain quantitative insights as soon as possible.

Business Metrics

I will not disclose absolute numbers for confidentiality reasons. Some of the metrics we use in the company are: Book Conversion (our new reference), View Deal conversion and Content Penetration. The business KPI numbers initially were really bad. Although we forecasted drops in our short term conversion, after all we don’t send people immediately with a prominent button to the advertiser website, to our surprise also the consequential booking conversion dropped way below our expectations.

When we analysed the penetration better we noticed there’s a problem on the first results screen too. Even though the card is one tappable area, less people proceeded to the next screen compared to the old app. Also with each step in our booking funnel less and less people converted in the end, dropping almost by half each time.

User research heatmap of the best performing hotel card redesign. Hotel Info vs Deals
User research heat-map of the best performing hotel card redesign. Hotel Info vs Deals

Design iterations that addressed these issues from different angles:

  • ∙  Adding a stronger affordance to the hotel card.
  • ∙  Removing the mandatory aspect of the booking funnel. We created 2 paths: for people that want to discover more hotel information vs others that just want to go to the offer.
  • ∙  Shortening the booking funnel. Removed some steps in the flow and made them non-compulsory. Especially successful was my proposal to make the mandatory deals list as optional and integrated in hotel details screen.
Final booking funnel flowchart
Final booking funnel flowchart

With the iterations mentioned above we managed to achieve the same KPI as the old app and surpassed it in some areas. Keep in mind that the old app was refined for years to achieve the same goals. The other maybe even more important aspect is that we now have a product tailored more to our branded users, flexible to add more features (another section, step in the flow etc) and that does justice to all the content we have about hotels. Many more things are yet to come.

But maybe the apps team can say more about what they like about our new release (bits of comparison with the older version included):

Video of apps team sharing their thoughts post release

Conclusion

Although the project was very successful and presented often in our company updates by management as an example of innovation in product development and workflow, looking back I still believe we could have improved some things:

  • ∙  Focus the team efforts initially only on our main flow as first MVP iteration. I believe we would have gained learnings quicker in things that matter most.
  • ∙  Testing early and ugly in a real life scenario with our users helped tremendously. Even if many of our team members (me included) were skeptical in releasing something unpolished.
  • ∙  Splitting the team in cross-functional groups that worked in parallel overall made sense but the alignment could have been better. Often the complete flow was split between teams and adjusted at a later stage with some compromises.

Download the new app from App Store for iOS and Google Play for Android.