trivago App redesign
- Project length: 4 months (Aug - Nov 2017)
- Entire apps team: 30 members (4 Designers, 5 Project Managers, Apps Team Lead, 8 iOS Engineers, 7 Android Engineers, 5 QA)
- Platform: iOS and Android apps
trivago's business model
trivago is a metasearch for accommodation, focusing on helping the user find the right hotel at a great price. The business model is cost per click. So instead of booking on trivago, online travel agencies, hotel chains, and independent hotels pay trivago for referring users to their site. And the benefit to the user is that they can see a range of prices from different providers.
Problems with the previous app
We set out to solve two core problems with the previous app:
1. Users weren’t learning about the details of a hotel on trivago
When you search for a hotel, you enter a destination, dates, and then you get a list of results. You might see a few hotels that looks interesting to you. With the previous app, users would then click to leave trivago, and they would get redirected to a partner website (for example, Expedia).
Expedia would pay for that click. But, because the user doesn’t know all the hotel details, it might not be right for them. So they won’t book. Which firstly isn’t a good user experience. But, secondly, this also isn’t good for our partners. Because they’re looking for high-quality referrals that lead to bookings.
2. The app followed the mobile web
At the time the apps were very similar to the mobile website. Meaning that they weren’t taking advantage of the full capability that both the iOS and Android platforms offer. Why download an app when you can just visit trivago.com in your browser?
Goal of the redesign
With these problems in mind, the goal of the redesign was to:
1. Increase business value depth
Provide a flow that allows users to decide which hotel they’re interested in, before being redirected to the partner website. Meaning the referral is higher quality and more likely to lead to a booking. This goal needed to be achieved whilst maintaining key business KPIs in the short term.
2. Native app design
Design a mobile experience that takes advantage of the states, modes, gestures and views that a native app allows. Utilising pre-existing platform components that users will be familiar with.
Design Sprints
The redesign started in August 2017, and Design Sprints were organised around different sections of the app:
- Landing: One of the first screens users see when downloading the app. It’s where users start their search.
- Result list and hotel details: After a user performs a search, what do they see and how do they access more information about a specific hotel?
- Map: How can we utilise the map to help users decide which hotel is best for their trip?
- Booking experience: The transition between leaving trivago and going to the partner website isn’t clear. How can this be improved?
Looking back, I think this was the wrong approach. As we tried to split the experience into different screens. But users don’t experience an app in screens, but rather flows across multiple screens. So I think a better approach would have been Design Sprints based on user flows.
Testing an initial prototype
The designers from each sprint then worked together to mockup a prototype, bringing together the individual ideas into a complete app experience.
This prototype was tested in-house at the trivago office, recruiting participants in the Düsseldorf area. I can’t share photos of the test itself, but here's a short summary of the findings:
- Overall no major usability issues. Flow works but there are problems with entry points, e.g. for reviews.
- The transition from trivago to the OTA caused frustration for some participants.
- Ratings should be given greater priority.
The landing experience
My main responsibility area during the redesign was the landing experience. With a key part being what's known internally as the “Dealform”. The search component that allows users to enter their destination, dates, and number of guests.
Destination selector
There are 2 key areas of the destination selector that I want to highlight:
- The input field placeholder copy “Try cities, places, airports” is designed to inform the user that they don’t just need to enter a city (which is most common). You can also enter other places, such as attractions, airports, train stations etc.
- A common use case for mobile is searching nearby your current location, so the option is given prominence.
Calendar
We wanted to keep the interaction simple, and users can set their dates with just a couple of taps:
- Full-screen calendar with large touch targets.
- User taps once to select the check-in date, then again to select their check-out date.
- If they select a check-in date, and then for the check-out date, select a date in the past. The check-in date changes.
The selected dates are positioned near the confirmation button, to allow the user to easily double-check their info before proceeding.
Rooms and guests
At the time, the mobile web team were experimenting with flows relating to the search experience. And there was an in-house user test that had a key finding relating to the rooms and guests selector. In the version tested, 3/6 participants were selecting the total number of adults. But not selecting the number of rooms. Even though in the task it specifies that 2 rooms are needed.
To try and address this problem, it was important to give the room selector more prominence in the design. So users understand that they need to additionally select the number of rooms. An important step for accurate hotel pricing. Which is why the selector is shown above the number of adults/children. To make it more visible to users.
With the UI, I want to give the feeling that each room was it’s own self-contained component. Similar to that of an actual room. Which is why I chose the card design. The default is 2 guests, 1 room. Which is the most common room configuration.
Problem with the destination, dates, guests flow
Partway through the process we noticed a problem with the Dealform flow. When a user entered their destination, they were taken back to the landing screen. It’s the same for dates and guests, once the user had entered their information, they were again taken back to the landing screen.
The issue is that it’s quite a long process. As the user needs to go back to the landing screen each time, and tap to open the next screen.
The final design
I addressed the problem above, by transitioning the user directly to the calendar once they’ve entered a destination. The new flow is as follows:
Destination → Dates → List of results
As we’re using the most common room/guest configuration as the default (2 guests, 1 room), this is not included as part of the flow. But can always be changed from the list of results. The hotel cards allow the user to browse the list and get an overview. Before tapping on a card to learn more about a specific hotel.
The hotel details page aligned with our original goal of increasing business value depth. I can’t share specific business metrics, but when first released, the app didn’t meet the requirements for us to be able to quality the redesign. So the team worked on giving prices higher priority (I wasn’t involved in these changes), to try and create more of a balance between prices from partner websites, and hotel related content.
Team video
A few members of the apps team shared their thoughts on the redesign. With the video being shared on trivago’s social channels.
Conclusion
Once the redesign had been qualified, we were able to achieve our original goal, of achieving the same business KPIs as the previous app in the short-term (and even surpassing the previous app in certain areas). This was a big achievement, as we felt the changes made to the increased visibility of hotel content, was a big step forward in terms of usability and increasing business value depth in the long-term.
The original deadline for both design and development was just a couple of months (it ended up taking roughly 4 months). Looking back, there was no clear reason why this deadline was so short. And it ended up causing stress within the team which was unnecessary. I could have spoken up more at the beginning of the project and voiced my concerns.
Read another project?
Back to Projects