.avif)
Introduction
Le mois dernier une partie des équipes design de Digilityx a eu l'opportunité d'assister à une conférence de Gautier Zimmerman (Head of Product & Design chez Malo qui change de nom pour devenir Heloa) et une table ronde organisée par User Testing sur la thématique : User Research & IA.
Sujet en vogue du moment nous avons donc pris le temps de vous résumer les apprentissages principaux.
Contexte
On commence fort avec une métric impactante : 75% de temps gagné sur la recherche utilisateur grâce à l'IA. Derrière ce chiffre se cache les détails d'une machine bien rodée. Commençons par le choix du LLM, ici le choix de Gautier et de ses équipes s'est porté sur Claude qu'il a présenté comme plus pertinent et plus à même de traiter une grande quantité d'informations en inputs afin d'alimenter les assistants créés.
Claude a aussi été présenté comme le meilleur LLM à ce jour pour structurer une assistance à la recherche produit. En effet on parle ici de plusieurs assistants car leur choix a été de créer plusieurs modèles afin d’assister les équipes produit et design dans l'accomplissement de plusieurs tâches distinctes sans s'exposer aux hallucinations parfois observées dans ce type de travaux ou simplement l'accumulation de biais. Ainsi plusieurs assistants se succèdent pour accomplir des sous-tâches définies comme par exemple : la définition des hypothèses de recherche, la vérification que ces dernières ne sont pas biaisées ou encore la rédaction d'un guide d'entretien. En tout, ce sont 6 assistants, tous spécialisés et indépendants, qui interviennent dans le processus de recherche :
- Malo User Research - Survey Creation
- Malo User Research - Interview Guide Creation
- Malo User Research - Defining Research Hypotheses
- Malo User Research - Survey Review
- Malo User Research - Interview Question Review
- Malo User Research - Methodologies
Détails de la mise en place
Rentrons un peu plus dans le détail, chaque assistant doit être paramétré ; dans les exemples présentés il y avait 3 paramètres : "Rôle", "Goal" et "Processus".
Programmer le “rôle”
Commençons par le plus facile le rôle ; ici c'est très classique si vous êtes habitué·e de l'usage des LLM vous devez préciser au sein de ce dernier quel rôle doit endosser le modèle. Exemple : "Vous êtes un expert en recherche utilisateur spécialisé dans les produits numériques et principalement les applications mobiles". Avec Claude sachez que plus vous donnerez de détails, meilleure sera la réponse. Ainsi la quantité d'informations partagée au modèle est très importante. Lors de la conférence plusieurs exemples de détails ont été partagés, on retrouvait par exemple le domaine d'expertise sectorielle, le nom de l'application sur laquelle l'étude se porte, une description de toute l'app etc.
Programmer le “goal”
Le deuxième élément de paramétrage était le Goal ; ici on va décrire ce que doit produire l'assistant, son objectif. Dans l'exemple exposé il s'agissait des hypothèses de recherche, s'en suivait donc dans les instructions vous l'aurez compris ce qu'est une hypothèse de recherche, son utilité, la façon dont on l'utilise en recherche utilisateur etc.
Programmer le “processus”
Enfin la description du processus à mettre en place et que vous connaissez bien si vous êtes un adepte de la discovery : comprendre le problème que l'on cherche à résoudre, se baser sur l'objectif de la recherche, le contexte (ce que l'on sait et ce que l'on ignore)...
Exécution du modèle et rédaction du prompt
Enfin vient le moment tant attendu : le prompt
Ici 3 composantes principales à exposer à notre assistant :
- la définition du problème :
- Description de la fonctionnalité : à quoi elle sert, comment elle fonctionne, où elle se trouve ?
- Les objectifs de la feature (chiffrés ou non).
- Objectifs de recherche (ce qu’on aimerait savoir à la fin)
- Contextualisation (les données actuellement connues qu’elles soient qualitatives et/ou quantitatives)
Conclusion
Cette conférence nous a beaucoup inspiré et raisonné en nous.
En effet nous avions commencé chez Digilityx à tester des modèles similaires, également sur la discovery mais aussi sur la définition de potentielles futures fonctionnalités clefs.
Les résultats sont prometteurs et l’utilisation de ces modèles nous forcent à constamment repenser la manière dont nous pouvons apporter de la valeur à nos clients. En effet partager l’entièreté des connaissances accumulées (data quanti, benchmark…) à nos assistants virtuels demande un rigueur et une organisation qui permet in fine d’accélerer nos phases de discovery, donc de les rapprocher les unes des autres (fini les 5 tests utilisateurs tous les 6 mois !) et ainsi améliorer la connaissance fine de l’utilisateur final de nos clients.
