Sommaire
1. Développement de produits avec recherche utilisateur basée sur Scrum
1.1 De Wayfinder à chercheur produit à responsable de produit
1.2 Dotation des moyens nécessaires à d’autres équipes
2. Le démarrage des Research Ops
2.1 Recherche de découverte et tests d’utilisabilité
2.2 Utilisation de plusieurs ressources
2.3 Présentation des conclusions
3. Testeurs appropriés et non biaisés
3.1 Problème : No-shows et testeurs inappropriés
3.2 Solution : Recrutement sans complications
3.3 Communication transparente et développement continu
1. Développement de produits avec recherche utilisateur basée sur Scrum
Le siège social de sipgate se trouve à Düsseldorf, avec 250 employés actifs. Ils développent des produits innovants de communication fixe et mobile pour des entreprises et pour des particuliers. Dans le cadre de leur activité, ils créent les interfaces entre l’Internet et la téléphonie.
Leurs produits sont développés selon le principe Scrum en sprints de 2 semaines Une équipe Scrum se compose toujours d’un product owner (responsable de produit), d’un scrum master et d’une équipe de développement (dev team). Dans le cas de David, le dev team se compose de quatre chercheurs, et David lui-même est le responsable de produit de l’équipe de recherche. À ce titre, il est le premier responsable des travaux de recherche de l’équipe. C’est lui qui décide des questions auxquelles il faut répondre et il est également responsable du Backlog Refinement.
Au début de chaque sprint, tout le monde se réunit pour planifier. Pendant cette étape, l’équipe essaie de planifier autant de tâches qu’elle peut gérer de manière réaliste. Les chercheurs sont responsables de leur mise en œuvre. Ils définissent comment ils veulent répondre aux questions et quelles sont les méthodes les plus raisonnables pour en répondre. À la fin de chaque sprint, il y a une révision du sprint et une rétrospective a lieu pour analyser la façon dont les choses se sont passées et décider ce qui devrait être fait différemment la prochaine fois.
1.1 De Wayfinder à chercheur produit à responsable de produit
David a commencé en tant que wayfinder chez sipgate. Comme le titre du poste l’indique, il a dû trouver son chemin chez sipgate – de manière totalement ouverte. Auparavant, dans son étape d’étudiant universitaire, il s’est impliqué intensivement dans le Design Thinking et il a étudié aussi Sciences de la communication. Toutes les méthodes à maîtriser par un chercheur lui étaient donc très familières d’un point de vue académique. En plus de ses études, il a également acquis de l’expérience chez une start-up dans le domaine des produits numériques.
Il a commencé à travailler chez sipgate parce que tous les deux, lui et la société, pensaient que c’était un bon appariement. Seul le rôle parfait pour lui restait à trouver. Cela s’est cristallisé avec le programme Wayfinder après seulement une année chez la société. Avec ce programme, l’employé et l’employeur découvrent en l’espace d’une année quel poste leur convient le mieux. Dans le cas de David, c’était finalement le rôle nouvellement créé de chercheur.
À la suite au programme, David a travaillé pendant six mois dans de différentes équipes en tant que chercheur produit. Quatre autres personnes ont été embauchées plus tard, et aujourd’hui elles travaillent en tant qu’équipe de recherche indépendante.
1.2 Dotation des moyens nécessaires à d’autres équipes
Sur les 250 personnes qui travaillent chez sipgate, environ 20 à 25 sont employées en tant que designers UX, et 5 d’entre elles sont des chercheurs. Comparé à d’autres entreprises, il s’agit d’un nombre relativement important.
Mais chez sipgate, la recherche utilisateur est importante pour de nombreux départements et rôles. Surtout pour les designers, parce qu’ils mènent régulièrement des tests d’utilisabilité. Mais aussi les responsables de produit souhaitant mieux comprendre l’utilisation de leurs produits et tester les derniers développements. Ils abordent tous l’équipe de recherche UX avec de questions diverses, l’amenant à considérer ce qu’ils sont capables de faire par eux-mêmes et quand ils doivent doter d’autres collègues des moyens nécessaires pour qu’ils puissent mener les recherches requises. Pour cela, ils les accompagnent dans le choix de la bonne méthode, donnent leur avis sur les questions à poser et bien plus encore.
L’équipe de sipgate au travail (Source : www.sipgate.de).
2. Le démarrage des Research Ops
Des recherches étaient déjà en cours chez sipgate avant que David n’ait commencé à y travailler. Cependant, à cette époque-là, c’était une pratique très peu structurée. Le rôle de David en tant que chercheur UX a définitivement apporté plus de méthodologie à la société. Auparavant, personne n’était spécifiquement dédiée à la recherche UX. C’étaient les designers UX qui se sentaient plutôt responsables de ce domaine. Mais ils devaient se concentrer sur la conception des produits et n’étaient pas en mesure de s’occuper de la mise en œuvre des travaux de recherche.
Les premières responsabilités de David étaient donc bien claires : Définir des stratégies, mettre en place des structures et des processus et sélectionner les bons outils, c-à-d développer tout ce qui concerne les Research Ops et tout ce qui est nécessaire pour accompagner les chercheurs d’une organisation dans le déploiement et la mise à l’échelle. Sans cette pierre angulaire, il est très difficile de mener de bonnes recherches.
2.1 Recherche de découverte et tests d’utilisabilité
L’équipe de recherche mène des recherches exploratoires pendant deux à trois mois sur les questions les plus importantes. Le but de la recherche exploratoire est l’investigation d’un problème qui n’a pas été clairement défini encore. Pour ce type de recherche, l’équipe part d’une idée générale et identifie les sujets sur lesquels se concentreront les futures tâches de recherche.
Un aspect important à prendre en compte ici est que l’équipe de recherche doit être prête à changer de direction à mesure que de nouvelles données ou perceptions émergent. Et cela fonctionne très bien dans le cas de David et de son équipe. Ils structurent leur travail à l’aide d’un Discovery Canvas, et ils travaillent sur celui-ci avant de transmettre l’information à l’équipe produit pour la mise en œuvre.
L’ensemble de ce travail de recherche implique six à sept entretiens hebdomadaires avec les utilisateurs. Et peut-être que cela se produise pendant quatre à cinq semaines. C’est une période très intense mais aussi éclairante pour l’équipe, qui aime mettre un twist dans les interviews avec les utilisateurs. L’équipe de recherche demande aux utilisateurs d’organiser les choses sur un tableau Miro pour voir comment ils imaginent la structure. Et actuellement, ils envisagent de commencer à utiliser Mentimeter pour représenter l’échelle.
Chaque équipe produit comprend un ou deux designers UX qui réalisent des tests d’utilisabilité après cette étape. L’équipe de recherche accompagne ce processus. Ils mettent à disposition tout le nécessaire et s’assurent que les designers UX peuvent faire leurs tests avec les personnes appropriées. De plus, ils vérifient de temps en temps si les tâches d’utilisabilité sont significatives et sinon, ils les optimisent.
2.2 Utilisation de plusieurs ressources
Chez sipgate, les chercheurs utilisent divers outils et services pour leurs recherches utilisateur. Lookback est utilisé pour les études modérées et RapidUsertests pour les non modérées. Miro est utilisé lorsque les choses deviennent un peu plus interactives et Figma est utilisé pour les prototypes. Chez sipgate, on utilise la plateforme de recrutement TestingTimes pour trouver des participants à l’étude appropriés. Et pour les sondages, on utilise SurveyMonkey.
David et son équipe font la plupart de leur travail en binôme. Peu importe que la tâche à accomplir soit la création de directives pour des interviews, la mise en œuvre d’interviews ou l’évaluation d’une étude. Ils sont sûrs que le plus grand avantage réside dans le fait que la qualité de leur recherche est nettement supérieure en travaillant de cette façon. De plus, il n’est encore jamais arrivé que l’équipe de recherche ne puisse continuer à travailler par manque d’informations. Mais ceci est quelque chose qui peut arriver rapidement si, par exemple, on ne prête pas d’attention pendant un bref instant lors d’une interview ou si quelqu’un est parti en congé.
2.3 Présentation des conclusions
Dans le cadre des révisions des sprints, l’équipe de recherche fait des présentations sur les conclusions de l’étude. Par la suite, il sera décidé quelles seront les prochaines étapes à suivre. Pour documenter les conclusions, David et son équipe ont créé un répertoire de recherche à l’aide d’une feuille Google. Le répertoire de recherche est un aperçu commun de toutes les études antérieures avec une référence aux connaissances acquises. Cela permet à toutes les équipes de récupérer facilement les informations concernant des projets du passé.
Dans leur ensemble de données, l’équipe décrit le groupe cible testé, en résumant les trois résultats les plus importants. Ils indiquent également pour quelle équipe cette recherche a été menée. Souvent, ils créent des vidéos de synthèse, car elles sont plus susceptibles d’être visionnées qu’un rapport de recherche classique. Des liens vers d’autres détails sont également inclus. Pour des raisons de confidentialité des données, généralement ils se filment eux-mêmes en parlant des conclusions, au lieu de montrer les utilisateurs réels.
Avec TestingTime, tous les documents requis peuvent être signés par les testeurs pendant le processus de commande, avant de débuter dans l’étude. Par exemple, un accord de non-divulgation ou un consentement à enregistrer le test. Par la suite, nous intégrons le document à être signé directement dans notre processus de recrutement. Chaque document est légalement signé, y compris la date, le nom complet du testeur et sa signature électronique. Tous les documents signés sont accessibles dans l’aperçu de la commande avant de commencer le test.
Présentation des résultats lors de la révision (Source: www.sipgate.de).
3. Testeurs appropriés et non biaisés
Dans le passé, sipgate recrutait des participants pour les études via Facebook, ainsi que des membres de la famille et des amis. Au début, cela fonctionnait, bien qu’avec quelques difficultés, mais après un certain temps, ce n’était plus possible. Cela demandait trop d’efforts et effectivement, pour les sprints d’à peine 2 semaines, le recrutement doit être rapide. De plus, ces personnes faisaient rarement partie du groupe cible réel et étaient biaisées, car au fil du temps, les mêmes personnes avaient participé à plusieurs reprises.
3.1 Problème : No-shows et testeurs inappropriés
Le plus grand défi pour sipgate lors de la recherche étaient les « no-shows », c-à-d les personnes qui tout simplement ne se présentent pas à l’étude. Et puis il y avait les « misfits » (testeurs inappropriés), c-à-d que leur profil ne correspondait pas au profil recherché ou que le participant avait des problèmes techniques lors de la réalisation d’études en ligne. Parfois, un microphone ne fonctionnait pas ou un navigateur n’était pas mis à jour. Pour cette raison, sipgate effectue des contrôles technologiques ou fournit des packages de goodies aux testeurs au préalable, pour s’assurer qu’ils se présenteront pour le test et que tout fonctionnera correctement.
3.2 Solution : Recrutement sans complications
Avant d’utiliser la plateforme TestingTime, sipgate travaillait avec une agence de recrutement. Mais ils n’étaient pas entièrement satisfaits du service reçu, et il y avait trop d’allers-retours. Le processus menant à la confirmation de la commande prenait trop de temps et était trop compliqué. David apprécie beaucoup le fait qu’avec TestingTime, de nombreuses questions sont traitées immédiatement à l’aide du formulaire de commande. Il n’est pas nécessaire d’envoyer des courriels inutiles pour obtenir les testeurs souhaités.
sipgate considère que l’un des grands avantages d’utiliser TestingTime est le fait qu’il est possible de recruter des personnes qui ne connaissent pas encore la société et ses produits. Sinon, il ne serait pas possible d’atteindre le groupe cible aussi facilement, ou il faudrait investir beaucoup de ressources financières et humaines, comme pour les tentatives initiales. Surtout, la société ne veut pas faire le recrutement elle-même via Facebook & Cie., car elle n’est pas douée pour le faire et cela ne fait pas partie de son métier principal non plus. David pense qu’ils ne pourraient jamais atteindre l’expertise de TestingTime et qu’en plus, ils devraient sacrifier la qualité.
Néanmoins, sipgate gère son propre panel de testeurs avec env. 1 000 personnes – toutes elles clients de sipgate. Les membres de ce panel sont des fans de sipgate, ce qui est la raison de leur inscription au panel. Mais pour certaines études, cela peut être un inconvénient, et pour les nouveaux produits, il est plus logique de mener des tests également avec de nouveaux utilisateurs potentiels. Alors, sipgate utilise le panel public de TestingTime pour environ 50% de ses études.
3.3 Communication transparente et développement continu
Ce que David apprécie particulièrement de TestingTime, c’est la transparence. Il est constamment et correctement informé de l’état du recrutement via son tableau de bord client. Il est également inscrit en tant que testeur chez TestingTime et alors il sait comment l’ensemble du processus fonctionne des deux côtés.
Tout comme sipgate développe continuellement ses produits, TestingTime fait de même. Nous menons régulièrement des recherches sur nos propres produits pour offrir la meilleure expérience utilisateur possible. C’est un autre atout que David trouve absolument génial. Il a récemment remarqué qu’il est désormais possible de créer soi-même des questions de screening. Il apprécie beaucoup cette caractéristique du produit, car il faut parfois une expertise du marché de la téléphonie pour créer certaines questions de screening pour mener les études. Lui et son équipe sont heureux de pouvoir s’en charger eux-mêmes s’ils le souhaitent.
En tant que testeur dans notre pool de clients, il a récemment participé à une étude de TestingTime. Une nouvelle fonctionnalité était en cours d’être testée, et celle-ci l’enthousiasmait, parce qu’elle facilitera sa vie de chercheur, la sienne et celle de bien d’autres (inscrivez-vous ici pour en savoir plus).
David est curieux et conseille à ses collègues en UX de suivre également cette approche. Son conseil est de faire des recherches au quotidien. Dans la vie privée aussi. Il suffit de demander à un chauffeur Uber pourquoi il s’est inscrit auprès d’Uber et non auprès d’un autre fournisseur. Ou lorsque vous achetez du pop-corn au cinéma, demandez ce qui se vend le plus : du pop-corn sucré ou salé ? Après tout, c’est en forgeant qu’on devient forgeron.
