Native App for trivago
Role: Lead Product Designer
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.
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.
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:
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.
As lead product designer my role was to:
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:
Although the user test results were very comprehensive regarding each individual feature and step in the flow, the main learnings were the following:
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:
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.
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:
As first basis for prioritising the content in the flow we used a generative user research in combination with business requirements.
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.
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.
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.
Design iterations that addressed these issues from different angles:
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):
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:
© Oleg Stirbu, 2019