Set up an user research shared database & apply insights on a search feature redesign for today’s and future’s use-cases.

Freelance - Research & Product design - 2 months - 2021


CRI projects is a platform for students, teachers and researchers to gather their pedagogic experiments and create a living network of researchers, where they can find inspiration, new collaborators, and ultimately display their results.



3/4 of key users didn't understand how to use the search fonction.

Despite the multiple ways to search and explore the network, users use it scarecely, and rarely end satisfied.


Stakeholders workshop

User research

Data analysis

Functionnal blueprint

User interface design


1. Realign the product team with today's users issues and motivations.

2. Start a written, collaborative database for user research.


Starting a written, collaborative database for user research.

The CRI's products are only a couple of years old, but they move with a fast pace on various topics, to propose solutions to a lot of needs from very different personas.

It was a blast to have the chance to work with them, but also challenging to find the right info about a specific topic, as every interviews or workshops they had, every decisions they made weren't documented.

It was key to have a full understandment of how users perceived and used the platform. While doing 1-1 interviews, I asked about the general behaviours and motivations, put everything on Dovetail, and created clusters of interests for the search function and also for the rest of their products.

It was well received and they followed up on it to add their own content .

Realigning the product team with today's users issues and motivations.


There was little user research communicated to stakeholders, so to understand their views of the problem we started with a workshop to know how they perceived their users motivations.

There was a lot of points raised, and to help prioritize, I followed up with 1-1 interviews. It confirmed certain points, but the main take-away completely shifted our view of the problem :

Algorithms intrication was not the priority.

We learned that :

• Focusing only on how the in-house algorithm will works with newly integrated Algolia would not define the success of searching on the platform for users.
• Users behaviours and goals were still very basics compared to the product team's ambition.
• There were existing behaviours that we could use to encourage a regain of trust towards a misunderstood feature.

The data collected is, to date, solely around general behaviours (number of uses, authentifcation status,...). A strategy to complete this data collection was talked about, but other parts of the product were prioritized.



Users need a better classification system and an easy way to use it.

This was already a major problem, and it was expected to grow bigger if the acquisition plan was successful. The current classification method was a first iteration, and its limitations where long past. Without a better system, it was like looking for a needle in a haystack.

To challenge that, we had :

Business goals

• Facilitate project contribution
• Facilitate networking
• Create a living network

Technical goals

• Intricate in-house algorithm and Algolia
• Have a new architectural & logical system for the classification system
• Create bridges between community admins

Design goals

• Redesign for what's motivate search usage
• Make the experience clean from every entry points
• Create an obivous experience for templating and tag-groups
• Create a result page more inline with users needs



We identified 4 points of contact that needed to change. The search bar and the results page of course, but also the tags mechanics and the template mechanics.

To communicate how it would change with the tech team, the blueprints above were made.



I analyzed best in class search functions to see why It was made that way, how their users could use it, and if there were standarts to use to facilitate the adoption.