Vous avez deux semaines et aucun budget de recherche. Comment validez-vous une refonte ?

Servez-vous de l'existant avant de demander quoi que ce soit. Les tickets de support, les enregistrements d'appels commerciaux, les logs de recherche interne au produit, les enregistrements de session et l'analytics répondent gratuitement à un nombre surprenant de questions. Ensuite mettez cinq personnes devant un prototype, même s'il s'agit de collègues proches du problème, et soyez explicite sur la faiblesse de l'échantillon. Terminez par un déploiement progressif pour que les vrais utilisateurs soient le contrôle final.

Deux semaines suffisent si j'arrête de traiter la recherche comme quelque chose qu'il faut commander. Les jours un et deux, je lis les tickets de support de ce parcours triés par volume, et je passe en revue les requêtes de recherche dans le produit, ce qui est en gros les utilisateurs qui vous disent ce qu'ils ne trouvent pas, avec leurs propres mots. Ensuite je passe une heure avec chacun de deux agents de support et quelqu'un du commerce, parce qu'ils entendent la même plainte quarante fois par semaine et que personne ne leur demande jamais. Ça me donne en général l'essentiel de la définition du problème. Puis je construis un prototype grossier et je lance cinq sessions non modérées sur une plateforme de test, ce qui coûte très peu et revient du jour au lendemain. Si je ne peux vraiment pas recruter à l'extérieur, j'utiliserai des gens en interne qui ne sont pas dans l'équipe produit, et je dis clairement dans la restitution qu'ils ne sont pas représentatifs, donc on traite les constats comme des signaux et non comme des preuves. Enfin, je livrerais derrière un flag à cinq pour cent et j'observerais. De vrais utilisateurs en faible volume sont une meilleure preuve qu'une étude parfaite que je n'avais pas le temps de mener.