Designing a Flexible Organism for the Hotel Search Website
A case study about redesigning the item element of the hotel search result list on trivago’s website.
A few months ago, we at trivago — the hotel metasearch website — established the first version of the styleguide and the pattern library by using the Atomic Design methodology. This was a reference for redesigning the company’s products, including the hotel search website — the trivago’s core product.
Ironman
Shortly after introducing our first pattern library, developers renewed the CSS core of the hotel search website and migrated it into the pattern library under the project name Ironman. Christoph Reinartz documented the whole Ironman process. Ironman was a necessary step for further design updates.
Ironman was a shift from the fractured design full of inconsistencies, accessibility problems, and sustainability issues to the design system, based on the atomic design philosophy and common design language.
Item element issues
The last step of Ironman was a complete redesign of the item element on the hotel search website. By item element, I mean one of those 25 elements (hotels) that appear on the search result list, after you perform a search.
The old hotel search result list had following issues:
- poor user experience (inconsistent user interface, accessibility issues due to poor touch-ability, readability and unbalanced contrast, lack of white space, information architecture issues, hidden entry points, poor slide-out navigation, outdated design, user flow interruptions etc.),
- technical limitations (not fully responsive, technical debt, sustainability issues, legacy of design compromises due to older browsers, conflicts with the pattern library, no alignments between designers and developers),
- limited branding potential due to the technical limitations and the style inconsistencies (unaligned font sizes and styles, conflicting colour palettes and icon sets, lack of global style etc.).
All these issues had to be addressed in three main objectives of the redesign:
- to improve the overall user experience of the item element, make it fully scalable and responsive and touch-optimised on mobile devices,
- to improve the entry points and information architecture (IA) for the content and the deals section,
- to increase or to maintain the conversion rate for item elements.
Changing the collaboration
In the past, such projects were mostly done by one or two designers and by relying on the good practice of the Web and the data of past tests. In some cases, product owners already prepared low fidelity wire-frames and designers just “visually executed” them. For the item element, we really needed to think through all the listed issues, users’ needs, and business requirements, and find a solution that works from all these different perspectives. It was a perfect opportunity to get together other designers and challenge the existing approach.
At that time, my colleague from the Mobile team, Georg Bednorz, was about to “polish and align” the trivago Android app, which included the item element as well. Collaboration between the mobile and the web design team wasn’t so common back in the days, so first we still needed to work out how we could collaborate.
Benchmark and first user testing
Before digging into the concept of the item element, it was necessary for us to get more information about our competitors, users, business needs, legal requirements etc. First thing that we did was a benchmark — a competitive landscape analysis on how our competitors are structuring and presenting information, like deals, images, ratings/reviews etc. This helped us to distinguish ourselves from the others and to see how we can improve upon what competitors are doing.
What about the users? What information do they need? We decided to ask the users directly, so we did an online user testing. We took a screen shot of our old hotel search website, we randomly picked one hotel from the screen shot, and asked users, what information would they need to evaluate that hotel. It was a small sample, but rich with the qualitative data. Participants mentioned price, reviews, location and services (amenities) as the most important information they would need to evaluate the hotel. To our surprise, images weren’t priority and the hotel name wasn’t even listed!
Design sprint
We were aware of the (un)reliability of the small sample so we didn’t take these results for granted. But it’s better to have at least some clue than to rely completely on intuition. Before we started working on first concepts, Georg contacted me on Slack…
We decided to find our concept by doing a design sprint — Google Venture’s approach for finding solutions through ideation, sketching, prototyping and testing, by considering perspective of users, business and technology. Design sprint has five steps: Understand, Diverge, Decide, Prototype & Validate.
Ten people participated in the design sprint. Mobile and web designers, product owners, a UX researcher and a developer. We spent 2–3 days on the first three steps, then 1 week for polishing the first prototype for the user testing, and another week for applying the new learnings. On December 3, we had a presentation of the concept.
UNDERSTAND. In the first step of design sprint, we briefly discussed research results again, listed all the issues and formed a problem statement, that guided us through the design sprint. Whenever our discussion lost focus, we returned to the statement. The problem statement was:
“As a user, I want an item element where I can easily compare prices and hotel information.”
The next question was the IA of the item element. What would be the perfect IA for the users in order to compare different hotels? Again, we did the user testing on a small sample and asked participants, which information would they put into 4 yellow boxes to compare hotels (see below). The responders mostly replied with price, images, location and reviews. The participants would put images in box A and the reviews in box C. For the B and D boxes, results weren’t so significant.
DIVERGE. Sketching phase. We started sketching the layout ideas to address our problem statement. Everybody had to sketch 8 solutions (“crazy 8s”) in 5 minutes. We sketched anything, regardless of how realistic and viable ideas were. We iterated under short time limits, which forced us to think pragmatically. No artistic impression was judged. Then we put those sketches on the wall and gave a silent critique by using dot stickers (as votes). We repeated the exercise and realised that our ideas went into two general directions: (1) item element as a card, (2) and item element as an integrated part of the list.
We discussed pros and cons about both layouts. Card view (grid view) is based on the principle of enclosure — all the information on the card is perceived as grouped and related to each other due to the drop shadow or border around. Hence, cards are good for exposing the information about one particular hotel. Cards also work well with nice, big images (e.g. stylish rooms, good view) that are supplemented by the descriptive content, and are powerful tools for inspiration and emotional appeal. On the other hand, cards aren’t so useful for direct and quick comparison of text information (location, prices etc.), which is something we offer on our website.
List view is less inspirational, description-oriented and supports decision-making based on rational evaluation. Prices, distances or rating scores (the numbers) demand more cognitive processing, hence more time to compare. More visual weight in the layout also means longer processing time. A list supports quick scanning and direct comparison of information, and helps to shape the content into looking more compact (more information on the screen).
The next thing we did was storyboarding — sketching and describing a user story. We did several rounds of it, discussed each user story and exposed things we liked about those stories. Liking basically meant selecting small pieces that could be part of the bigger solution.
You have to give the user story a name, sketch step by step on papers, paste it on the board and later explain it briefly to everyone. A 10-minutes exercise.
DECIDE. At this step, we made a decision (1) on the primary layout (view) and (2) on the IA of the item element. This is the step where the concept needs to work and needs to make sense. We narrowed down the number of solutions to the most actionable and viable one. The overall conclusion was that the list view might be a better solution for presenting item elements as search results. It helps the users to compare deals, ratings scores and distances fast and easy, and to see more of the content (due to the compact structure). But when user stops comparing hotel information and focuses only on one hotel, card view helps to focus on the specifics of one hotel. In this case the user switches from comparison mode to focus mode and changes the reading pattern. The user scans the list with the F-pattern and once the card appears, they switch to the Z-pattern.
F-scanning (left) — reading the list of results in an F pattern, by seeing top left corner of the page first and then sliding down on the left side of the screen and only occasionally checking the information towards the right side of the screen. Z-reading (right) — user’s eyes glance from the left to the right side, then shifting diagonally down to the bottom left corner and glancing to the bottom right corner.
We decided to use a combination of both: a list view as a primary view, and a card as a secondary view. The search result list appears as a list, but when user focuses on the information of specific hotel, item element excludes itself from the list and functions as a card.
Second question was the layout and the AI of the item element or how to arrange following information: price & online travel agency partner, rating score & number of reviews, hotel location, hotel name (+stars), the image and the favouriting icon. On bigger viewports, the alternative deals and the dynamic content appear as part of the layout.
Font sizes and contrast ratios were derived from the styleguide, and selected upon the user testing results. The most important factors had to be most prominent, which in our case were the price and the click-out button. The button was the pattern library element, so it was already a thought out element. For the price, we had to check if the big font size works with the Vietnamese dong currency and its 8-digit numbers. We considered all possible situations.
We came up with two alternatives for the layout: (1) Alternative 1 with the image and the click-out button on the right side, and the deal info on the left side, which was kind of a “crazy idea”; (2) Alternative 2 with the image on the left side and the click-out button and price on the right side, which was kind of an improved version of the old item element.
The main problem with Alternative 1 was that the deal part (prices, OTA, alternative prices on the left side) was separated from the click-out button (View deal). The price and the View deal button are inherently connected and should be closer to each other. We also wanted to group the deals information together, so that it doesn’t break the content structure (and vice-versa). We decided to proceed with Alternative 2.
PROTOTYPE. In order to get a solid prototype for user testing, we polished the wireframe by (1) making CTAs and entry points clearer, (2) organising the IA, and (3) adapting the layout size of the item element. When we started with “pixel-perfect” discussions, we knew we are ready for testing.
VALIDATE & LEARN. Time for user testing (again). This last step of the design sprint took us a week, since we had to carefully prepare testing scenarios and mockups to test the following iterations: (1) entry points with additional links vs. entry points without additional links, (2) location icon vs. no location icon, and (3) the new item element entry points vs. the old item element entry points.
We prepared two mockups with the new item element — one with additional links as entry points and one without additional links for entry points, and tested them against the old item element list (live version).
We tested all the entry points in the item element. In general, additional text links improved the affordances of the entry points, but also added to the visual clutter that resulted in clicking on the wrong entry points. Links also outperformed the icons (location icon), so it didn’t make sense to keep both.
In comparison to the old item element, the new item element entry points performed better on average, especially for entry points for location, View all deals, and hotel details. This meant that we improved the content access points and the overall exposure of the content.
The final concept
We presented the final concept with mid-fidelity wireframes, in order to avoid distractions that might be caused by images or colours. It was important for us to present flexibility and scalability of the new item element, as a pattern library organism that can stretch across the different viewports. That’s why we prepared design mockups for the most common viewports (in px): 320, 360, 414, 432, 480, 600, 720, 768, 780~. Don’t get me wrong — the item element would be fully fluid, regardless of these CSS widths. Also it makes no sense for designers to prepare in the future mockups for all of these viewports.
Beside the wireframes, we also presented the behaviour of the structure (blue boxes on the image below) in conjunction with item element’s scalability and all the possible entry points/clickable areas (red boxes).
Probably an interesting thing to mention is the breakpoint at 600 px CSS width, when the content structure and the deals structure flip from the row-arranged system into the column-arranged system, in order to preserve the IA and to make space for the alternative prices column that comes in at the next breakpoint.
After the presentation, we tested the entry points on mobile. The click-out button was especially something we were interested in, since we used the pattern library button without a CTA string (View deal), and only with the arrow icon. It worked, users recognised it in a similar way as the old button with the CTA string. Now we knew, that the risk of losing clicks on the button on account of other entry points is not as high as we thought. In general, the entry points in the new version performed similar to the entry points in the old version.
Collaboration with developers
Once design mockups were ready, the item element went into development. It was built in the pattern library. My responsibility was to fully support front-end developers in this phase. Support how? By aligning on design details at different media queries for common devices breakpoints, by checking paddings, by consolidating font sizes,… everything. Dropping design mockups on developer’s desk and complaining later about things behaving differently as in the concepts doesn’t help anyone. This is a “brothers in arms” thing. In the end, we all have the responsibility to deliver a completed product and to deliver it on time. And we delivered ours by the deadline!
Item element 1.1 and acceptance
Item element was live and it went into multi-variant testing. In the meantime, we did 10-15 iterations and tested them. From small changes, like changing the colour of the price, to general adjustments that gave birth to the item element v1.1. This was a switch from the list to cards, that were arranged as a list. Basically, there is the same logic as in the previous version, but instead of using a 1 px separation line, we used smaller padding between the cards. The rest of the layout stayed as it was.
After testing the new item element for few weeks, we decided to accept it!
At the beginning
We will continue iterating on the new item element and we’ll keep looking for things we could improve. However, we managed to achieve the goals of the project and to transform the item element into a flexible organism that can stretch through different viewports, regardless of the content. But we are only at the beginning.
I learnt two things from this project. First, how collaboration can change the paradigm of solving problems. Design sprint turned out to be an effective approach not just for discovery of ideas but for shaping them into solutions with business value. Things can move very fast when you’re working with people that care about the product. I’m not saying that a design sprint is the best general approach you can use, but it certainly helped us to change our perspective in order to change the product.
Second, I learned how the power of proof, one of trivago’s core values, can be really powerful. Because in the end, you have to be able to explain your solution to the product team, otherwise they won’t recognise the efforts of the teamwork. If you’re uncertain about something, then say it, because uncertainty is normal. But try not to leave yourself clueless. We achieved our power of proof through user testing that always gave us that small piece of knowledge that confirmed that we might be going into the right direction, but also, that we are still only at the beginning.
p.s.: Thanks to Ian Devlin, alessio zazzarini, Sarah McGivney and Mirja Wagener for helping me with the article.
