How we merged the search page with the content @Stylight // part one


We started thinking about giving something more to the user earlier this year. Stylight offers an amazing shopping experience with thousands of shops and is also the fastest growing fashion magazine in Germany; going from there to thinking of a new way of inspiring the user, it wasn’t so hard to close the gap.

We aim to give “shoppable” inspiration to people, there are many magazines that are so good at inspiring the user, Vogue, Elle, Cosmopolitan, but are not so good at translating this inspiration into something real, something the user can have in their hand.

We want to fill that gap and let the user embrace a new way of getting fashion content.

In order to do this we knew we had to put our products and our fashion content side by side; we were ready to lose some of our conversion rate, because we believe that a better experience for the user is worth more than few points of that.


Before going deep into how we managed this single, big project I’d like to give an overview of how we manage every single project here at Stylight, and how we managed to become the fastest growing magazine in Germany in less than a year.

Stylight is an agile company, so we use all the techniques you already know, scrum, sprints, and iterations. Earlier this year we made a huge switch that helped us to improve the way we work, we split the company into teams around products, now we have several teams (we are 200 people) and every single one is completely autonomous in improving the products it is built around (the website or app, for example) with designers, data scientists, developers, and product owners.

Being a lean company doesn’t mean only having a stand up every morning, or working in sprints, the most valuable skill at Stylight is the capability to change. If we understand that there’s another way of working, or there’s something we can do to improve the way we work, we test it and if we are satisfied we keep it; we don’t stick to the past or to the routine, we love to change if that brings any benefits to our way of work.

We don’t stick to the past or to the routine, we love to change if that brings any benefits to our way of work.

If we talk about the product, about the website, our way of working is really simple. We AB-test everything, every single feature we want to introduce is tested, this mean that we let the numbers drive our growth. We compare the numbers that come out of a new version of the website with the current one, and if we are happy about the results we stick to the new version. This then becomes the one we’ll use to compare the next test and so on. In order to do that we test one single feature per time so we know without any doubt where the gaps between the numbers come from.


At Stylight we have 2 teams that take care of the website, the search team and the magazine team. The first one, the search team, takes care of the search result page; the page the user get when they do a product search on Stylight. The second one, the magazine team, takes care of the rest of the website, the homepage, the content section with the post and so on.

The challenge was to let these 2 teams collaborate in order to merge the content we have directly on the search page; this may seem really easy, but we had a lot of questions and we had no answers. How this should be like? Will the user appreciate the content directly connected to the products? Will this cause a drop in our conversion rate? How much can we afford to lose in order to give a better shoppable experience to the user?


Before going deep into the project itself, it is useful to keep in mind how our search page is structured, in order to better understand the decision we took to integrate the content onto it

We can divide the page in 4 main areas:

  1. header
  2. side bar
  3. products
  4. shopping bottom content

In the header (1) we have the main menu that lets the user switch between the 2 main parts of our website: the magazine and the shopping. This is divided in the menu in all the main categories we have: women, men, dresses, shoes, sales, brands and shops.

In the sidebar (2) we can find 3 main areas, the side navigation, that lets the user browse all of our shopping categories; the related searches and the side content; and a text about the page where the user is.

The products area (3) is the biggest part of the page and is where the results of the search are displayed, here we can also find the breadcrumbs that let the user know where they are, the title of the page, the filter bar, and the list of the products.

Last but not least we have a footer (4) where the user can find some additional info about the page itself with some images and a text.


Our first iteration was really simple, the goal was to merge the SEO content we already had on the page with the products. In order to do that we designed two different mockups for the desktop view and another two for the mobile. When we plan this kind of A/B/C test we, as designers, work together in order to create 2 mockups that are as different as possible to one another. We do this because the result of the test needs to be as clear as possible and we can only have this if the user sees something that gives them 2 different experiences. When we evaluate the results of the test, we usually agree on the direction we want to take, and maybe also change the design, but in order to do that we really need a clear sign from the user.

Version A (original) B (content on side) and C (content merged)

The main difference between the 2 mockups is that the second one, design C, is really integrated within the products on the search page. In both the desktop and mobile view this means that the content is within the search page and the user can read it whilst they’re also scrolling through the products, this should give them a more fluid experience with less impact. The risk is that the user doesn’t see the content, or that they can’t distinguish it from the products, and be confused. On the other side, design B is really apart from the products and can maybe be seen as an ad or something that has nothing to do with the page.

On mobile design C was a big image in the middle of the products that could be opened revealing the whole content, design B was on the top of the page just in one column. This last design was a simple anchor link bringing the user to the bottom of the page where the real content was.


We ran this A/B/C test for one week, alongside this we did a user test with our UX researcher. The results of a test like this are never really clear and easy to read, especially because we need to merge the numbers (quantitative insight) with the user insight (qualitative).

Starting from the numbers we were really surprised to see an improvement of the COCR (click out conversion rate), as I said before, we were ready to lose some percentage points in order to give a better experience, but in this case we were improving the conversion a lot. Mockup A especially was really breaking our conversion.

From the user tests, the insights were much more complicated to understand, we didn’t have a clear winner but both of the mockups had some positive and negative points. In the desktop view the users liked design B more, the whole column on the right. Design A turned out to be too complicated for the user to understand. On the mobile side, the users got lost in design B because of the scrolling of the page at the click, and so they liked the big image of design A more.


Never trust only the numbers, use quantitative insights to pinpoint where to focus your qualitative efforts.

We got some insights from this iteration. First of all, never trust just the numbers, but use the quantitative insights to guide your qualitative research. We went deep into these numbers and we understood that there were somethings that were not clear at all, the improvement of the conversion was too good to be true. This is why we always pair this with a user test, the user value is often invisible to the numbers; most of the time good user value turns in better retention that you can see in the weeks or months to come, not in an improvement of the COCR in few days.

We never expect to have a clear winner out of a test, and this time was the same. There was no clear winner between design A and B, but some valuable insights from both, this means that we need to somehow merge the 2 versions and that the second iterations will be longer to design and code.

Animations and interactions are a big part of the user experience, the feedback on mockup B was completely wrong, 5 users out of 5 didn’t understand that they were scrolling the page till the bottom. In the next iteration the interaction of the user will be better designed and coded in order to avoid this misleading feedback.

If you enjoyed reading this maybe you should read the second part here.