Design Portfolio



The problem

The older iPaper search functionality was sub-par and didn't offer customers the right experience. Several clients noticed over the last years that searching for something specific in a digital catalog was frustrating. Designing for over 20 million users per month is a challenge in itself, but here it was crucial to figure out why the users were unhappy with the current functionality.

My role

I led the redesign of the iPaper search functionality for two months as part of a team including engineers and product managers.

The vision

I wanted to create an improved way of searching through an iPaper quicker and better by designing flawless experiences on all three platforms: desktop, tablet and mobile.


Recently at iPaper, users started asking for an improved user experience of the product, so we were aware that there were issues to solve. We just didn't know why exactly. With such a complex product and with over 20 million visitors per month, there could be multiple reasons. During the early stages of this project I remembered a line by Sarah Doody: "If you can't define the problem, then don't design the solution".

During the initial period I spent time together with our Key Account Managers, who have close contact with our customers and know about many of their complaints. They were a huge help in figuring out the real problem.

The older search functionality was designed many years ago and worked in a mysterious way. When users searched for something in an iPaper, the search results were shown on top of the catalog in the form of small thumbnails. The frustration came because the thumbnails were so small that they couldn't be used to preview the results. They were, basically, just a waste of space (see image below, where there was a lot of unused space left at the bottom).

Furthermore, once the user clicked on a thumbnail, she went directly to the catalog. This is good. But if she chose the wrong search result, she had to start the search all over again, because the results were already gone.

When searching, users were always kept in a loop, because they always had to go back and redo the search. The scenario above was a happy one, with the user only having to go through the loop (light blue) a couple of times, but the situation could be much worse. A user could go through the loop as many times as the number of results that the engine returned. After two or three times, they became really frustrated with this.

During this phase I spotted three main issues:

  • The thumbnails for search results should be either bigger or not be shown at all;
  • Search results should not disappear unless the user asks for it;
  • Some things might work well on desktop, but not on mobile. There was clearly a need for designing different solutions for different platforms.


Here I defined the project milestones and discussed them with the team. I've also decided to create quick sketches of my new solution to support me, because abstract ideas are easy to undervalue or overvalue. Once the ideas are sketched, therefore concrete, it's much easier for teams to give fair criticism. I always feel that pitching backed up by visual aids helps the audience fully grasp my vision. We agreed that the initial sketches were a really good starting point.

During the ideation stage, I went through a longer process of wireframing. All wireframe iterations were reviewed with the team several times; we collaborated very closely for this project. Four iterations were needed to agree on the final solution and by the end of this phase, we also agreed that during this project we set the groundwork for future improvements. The early design decisions had a major impact on the architecture of the redesign of other elements in the front-end.

For mobile and tablet we decided to create a full screen search experience, where we could make use of all the space to show big thumbnails. These thumbnails would end up being very helpful for previewing the results and make sure users would quickly find what they were looking. This made a lot of sense considering most iPapers are based on visual experiences. Previewing the results with big thumbnails would also ensure that there is a lower possibility of choosing the wrong result.

For desktop, the debate required testing to reach a conclusion. We were split between a solution where an overlay would cover some of the catalog (depending on the screen size, up to 35% of it) and one where we would replace it with a sidebar (on smaller screens the catalog's size would adjust). In this second case though, there were some technical constraints and a bit more development time was required, but we were willing to put the extra work into it knowing that this architectural change would be the base for future redesigns. 

Think-aloud user testing emphasized the sidebar as the best solution. The test users enjoyed the fact that the sidebar stays in place even when they navigate to a result, in case they made the wrong choice. They also appreciated that it would be easy to get rid of it when needed.


The visual design had to be as simple as possible. In the beginning, we discussed giving customers the chance to customize the sidebar colors, but we ended up saying no to it anyway. There was an internal wish for a longer time to simplify the product and this would have gone against the vision. Therefore, I decided to design using neutral colors that will not stand out against the colors of our customer's publications.


The search functionality has been developed in the final months of my time at iPaper, and seems to be a really good improvement. The new design received positive feedback from customers. The solution for mobile was especially praised, as it now offers a quick way to search through complex publications even on smaller screens.