On the verge of failure
After a year of hard work with a radical redesign — we almost reverted to the old version. The business KPIs were way off.
With confidence and quick iteration we managed to fix it, and set an example of innovation in the company. Here’s what happened.
In 2018 I worked on a redesign of the Trivago iOS and Android app.
Used by millions.
As a lead product designer, it was a big and exciting project. It gave me and the team the opportunity to build it from scratch and rethink holistically the product. And flow.
My contribution
Product strategy User research Product design
The team
4 × Product Owners 4 × Product Designer 16 × Engineers
Year
2018
The vision
**In our pitch**, we outlined the direction of the new product.
We did a vision discovery exercise for a couple of weeks. It allowed us to get buy-in from the CEO and CPO.
My specific role was to create a complete flow and a high-fidelity prototype that unified feature and visionary ideas from the team.
I wrote about it in Trivago’s Tech blog.
What is Trivago
Trivago's business model — a metasearch that compares deals from different advertisers (like Expedia or Booking.com). You don't book on Trivago.
In a complete “book a hotel” JTBD — Trivago focuses on "Search and Compare" step.
But also explore boundaries in a smart way.
Goals of the project
-
Increase Trivago's product offering depth. Instead of sending travellers to advertisers — explore the quality of these visits and booking conversion. From quantity to quality of leads.
-
Improve or maintain business KPIs. The team could deprioritise short-term revenue metrics. Clicks volume. But we were still not allowed to go below a reasonable threshold.
-
Give more value to travelers. What is the reason to download and keep the app?! Instead of using the mobile web version.
-
Integrate well with Apple and Google platforms. Respect the patterns and guidelines to make users feel at home. At the same time, maintain the company's brand.
-
Improve the Information Architecture. To be future-proof and allow new features. Something that we always struggled with in the old app. New features had to be "squeezed" in the wrong place and wrong user flow.
The Team
Around 40 people. Divided into cross-functional teams. We included one: Product Owner, Product Designer, User Researcher, iOS Engineer, Android Engineer, and QA.
The main features were already defined during the vision sessions and design sprints — the teams already:
-
Analysed the old app and identified product and usability issues. Using Trivago personas developed by User ResearchCompetitive Analysis.
-
Conceptualised improvements and new features.
-
This time the cross-functional teams had to take ownership of individual features. And create a concept with “realistic constraints”. From a technical and timeline point of view.
My role
As a lead product designer my role was to:
-
Coordinate mobile designers. 4 at that time. They were working with their "cross-functional teams"
-
Represent design in key stakeholder meetings.
-
Work on a new design language and system.
-
Be part of the "Search results", "Hotel details" and "Deals" teams. As an individual contributor product designer. This is the most critical flow from a business perspective — the booking funnel.
Prototype and User Research
Teams worked 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 flow and Information Architecture of the app. So that the teams could adjust, redesign or remove features.
-
As a deliverable for our first in-house user test. To gather insights as soon as possible.
Main Learnings
User test results were very comprehensive about each feature flow. The main learnings were the following:
-
There were no severe usability issues.
-
The transition from the app to the advertiser website was confusing.
-
Hotel rating on the card was not visible.
-
Calendar caused confusion among some users.
Some issues were attributed to the fidelity of the prototype — no colors, no calendar transitions. And the nature of the product — we send people to another website.
But we iterated further based on the learnings that made sense.
We built a pre-alpha version. Made using platform native components. Engineers focused on the functionality. Without waiting for pixel perfect UIs from designers.
At the same time, the design team had time to work on the new design language and elements.
With the build we added another layer of fidelity. With colors and refined interactions, compared to the previous prototype, made in InVision.
We ran another user test. An unmoderated one with more people. Users could navigate and interact more freely.
The main learnings from the pre-alpha research:
-
No major usability issues were uncovered at this stage
-
Minor usability issues with Price Slider and Filter selection
-
Mixed reaction in regards to the booking flow and how it aligned with user's initial expectations.
We refined it further. We anticipated that there would be a shift in how Trivago was perceived. Given the new flow. More steps and content. But we assumed we were heading in the right direction as this was one of goals — have better-informed users. Resulting in a more qualitative conversion.
Booking Flow and Hotel Card
I was the "design owner" or IC of the booking funnel. It's the crucial funnel from the business point of view.
The booking funnel has the following screens:
-
Results with hotel cards
-
Hotel details
-
Child content for hotel details
-
Deals
-
Deal summary
-
Transition to advertiser
We used generative research — as the basis for prioritizing the content in the flow.
With the “hotel card” users always stuggled with touch areas in the old app — below the recommended 44 pt.
We went in a radical direction and made the whole card one tappable area. Now, we could take advantage of the hotel details screen that was not there before.
Second level content was exposed in hotel details. As an overview — ratings, amenities, location, etc.
And granular content had a dedicated “child” screen.
We followed our top-level product direction — give users the right information at the right time.
First Release
We shipped the new Android app on Google Store. With a 5% A/B test.
The final design language was not refined and the tech side not optimized. But wanted to gain quantitative insights as soon as possible.
Business Metrics
Metrics we use in the company were: Book Conversion (our new reference), Clicks Conversion and Content Penetration.
The KPI numbers initially were bad.
We forecasted drops in our short term conversion — Clicks. Now, we don’t send people immediately with a prominent button.
To our surprise also the Booking Conversion dropped way below our expectations.
When we analyzed the penetration we noticed there’s a problem on the Search results screen too.
Even though the card is one tappable area — fewer people proceeded to the next screen. With each step in our funnel — less and less people converted, dropping almost by half each time.
Fixing with design
Iterations that addressed these issues:
-
Added a stronger tap affordance to the hotel card.
-
Created 2 paths — for people that want to discover more hotel details. And for others that just want to go to the offer.
-
Made the flow shorter.
-
Removed some steps in the funnel and others optional. Especially successful was my proposal to make the “deals screen” optional. And integrate it in “hotel details”.
We managed to achieve the same KPI as the old app. Surpassed it in some areas. Even if the old app was refined for years to achieve the same goals.
Also, now have a product tailored to our “branded users”. flexible to add more features. And that does justice to all the content we have about hotels.
Maybe the apps team can say more about what they like about our new release. With bits of comparison with the older version:
Conclusion
The project was very successful. Presented often in our company All hands as an example of innovation in product development.
Looking back I still believe we could have improved some things:
-
Focus the team efforts only on our main flow as the first MVP iteration. We would have gained learnings quicker in things that matter most.
-
Testing early in a real life scenario. With our users. It helped tremendously. Even if our team members, me included, were skeptical in releasing something unpolished.
-
Cross-functional groups that worked in parallel made sense. But the alignment could have been better. Often the complete flow was split between teams. Then adjusted at a later stage with some compromises.
Download the app from App Store for iOS and Google Play for Android.