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.

Mobile and desktop/tablet view of the old item element list.

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.),

(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),

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.).

Old item element (480 px CSS width) — the red vertical line shows the problem of non-responsiveness.

The information architecture issues: deals structure (blue) is breaking the content structure .

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.”

Problem statement (top left), IA (middle), identified problems (bottom left) and design sprint steps (right).

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.

Every box was a placeholder for the content.

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.