Techblog: A new Face for Cliqz Quick Search

As of this June, Cliqz search has a new face on desktop. The longtime search UI already gets Cliqz users to where they want to go: on average, Cliqz answers more than 50% of all search queries directly from inside the browser — without having to wait for a Search Engine Result Page (SERP). So, why the change now?

Our UI started to show some signs for wear & tear. Over the years, we had added many new features, such as showing the weather forecast directly in the browser, a soccer Smart Cliqz with ongoing & upcoming league games, and direct links for streaming music from YouTube, Spotify, etc. As we pushed for getting these features out to users as fast as possible, we sometimes lost sight of design consistency, such as using the same styles for buttons with the same functionality, or consistent margins across different search results.

In addition, it got increasingly difficult to add new features or to fix potential bugs. This became painfully obvious when Cliqz expanded to additional countries, which required bespoke UI versions due country-specific search data. While we delivered in the end, it was clear that it was about time to create a more scalable and easier to maintain UI.

In January, Mozilla launched Firefox Test Pilot in Germany, its user-facing platform to test new browser features. Thanks to our close relations with Mozilla, we had the opportunity to run our redesign efforts in their Test Pilot program. They rolled out the established Cliqz search UI to about 10k users on Test Pilot.

Arguably, Firefox users are different from Cliqz users: they have different expectations towards the browser. Firefox users are not installing a new product (like the Cliqz browser), but continue to use something familiar. They are likely to expect a look & feel that nicely aligns with what they know and love.

The feedback we received from Test Pilot users suggested that the look & feel of our search UI was indeed an issue. For example, some users said that it was not obvious how to use the complementary search engine (e.g., Google), while others said that the presentation of results was wasting space. Our users told us we needed to change something. And we listened.

Of course, optimizing Cliqz search for Firefox was not going to be a single-sided effort, but a joint project between Cliqz and Mozilla — with the goal to create a shared product. In the previous months, we had already gathered valuable experiences working together remotely on smaller design & UX projects. But this time the challenge was bigger: changing the entry point to search in the browser. It became obvious that a closer collaboration was due to get this project done, and to get it done fast. A few days later in February, two of us from Cliqz boarded a plane from Munich to Toronto, Canada to meet with our design & UX colleagues at Mozilla for a week of focused, co-located collaboration.

We were lucky to be able to use Mozilla’s ample design space as a base, where we would get together every morning to plan the day, and then get things done. The first item on our agenda: to get an overview of the status quo by mapping out all current types of Cliqz results. Results include various Smart Cliqz, regular web sites, and items from the browser’s own history — all of which use different data. For example, web sites might come with a longish description, while history items do not have a description at all. This data forms the foundation of search results. Thus, it is imperative to not only have an overview, but to also understand the available data in depth in order to design a successful search UI.

To have an always-present visual overview, we printed out all available result types on paper and put them up on a wall behind our workspace. We took the opportunity to arrange the results from generic (e.g., a regular web site) to specific (e.g., weather information). This arrangement helps to recognize patterns and shared elements more easily, and to prioritize to start working on the most frequent results first.

We approached the design challenge at hand from two sides: first, from the data side — making sure to gain a shared understanding of the search result data at our disposal. Second, we defined a set of design requirements: consistency both within the search result presentation as well as with the surrounding Firefox browser, and extensibility to create a framework of only a few but re-usable design elements.

To further inform the design process, we also looked at user behavior data that was anonymously collected during the Test Pilot experiment. We saw, for example, that the majority of search results are selected using the mouse (i.e., by clicking on result), but that in more than 10% of cases users use their keyboard to select a result. Consequently, the new search UI needs to support both mouse and keyboard interaction.

During the design sprint, we followed an iterative process of discussing, creating, testing, and collecting feedback. It proved to be extremely helpful to have many fellow designers around (who were not involved in our project) to easily collect independent feedback. Mid-week, we took the chance to present the current design state at Mozilla’s UX design critique with designers from Mozilla offices around the globe who joined via video conference.

Over the course of the week, we touched and refined every single element of the UI — from icon placements, to alignments, to colors, to buttons and links, to highlight states. The outcome of this one-week sprint was a set of design specifications for the new search UI — ready to be implemented by our front-end engineering team in Munich.

All along, we worked with real data as soon as possible. While it is necessary to create visuals based on fake data to get started, nothing beats testing your designs with real data when working on complex, data-driven products like search. To facilitate fast testing, we put together a working prototype based on the current Cliqz add-on code. This allowed us to see new designs for arbitrary search queries and results immediately — everyone involved could experience their designs “come to life”. Now you would realize, for example, that some search results have more text in their description — thus won’t fit the design — or don’t have a description at all — making the design look broken. At the same time, the live prototype was a great communication tool to explain our designs to other stakeholders.

We tested early versions of the freshly baked UI in lab-based user tests to make sure that what we designed was actually going to be usable as intended. The next milestone was to roll out the new UI on Test Pilot (again) to another 13k users. This time, the feedback was positive, indicating that we had solved all search UI related issues.

The new search UI is live across Cliqz desktop products from end of June. We are looking forward to your feedback: let us know what you think about Cliqz’ new face!