Dans les coulisses d’Explorer : Comment nous embarquons nos clients dans la conception produit | Analytics

L’approche « user-centric » existe aussi dans la conception de solution digital analytics. La preuve, nous impliquons nos clients dès les premières phases de développements de nos produits. Pour créer l’Analytics Suite 2 (notre dernière version produit), nous nous sommes focalisés sur l’expérience utilisateur en embarquant nos clients et l’ensemble de nos collaborateurs dans la refonte de nos interfaces. Explications…

Nos premiers pas vers la « user-centricity »

Dès la phase de réflexion sur le futur produit, nous avons sollicité l’ensemble des collaborateurs de la société, sous la forme d’ateliers, présentations, … Ces premiers échanges nous ont permis d’obtenir la matière nécessaire à la construction d’un prototype.

Nous voulions ensuite mettre le produit entre les mains de quelques clients le plus rapidement possible. Objectif : recueillir très tôt des retours dans le processus de développement afin de tester plusieurs points : l’IHM correspondait-elle aux besoins ? Notre vision produit était-elle en phase avec nos utilisateurs ? Les fonctionnalités étaient-elles réellement utiles, et intuitives ?

En obtenant ces réponses auprès des clients, nous pourrions ainsi :

• Prioriser très tôt les fonctionnalités par le recueil de besoins concrets et détaillés par nos futurs utilisateurs finaux.
• Utiliser des retours utilisateurs comme première source d’alimentation de nos backlogs.
• Construire une roadmap produit complètement en phase avec les attentes de nos utilisateurs

La mise en place du dispositif de « co-design »

Lors de notre événement annuel « Digital Analytics Forum » nous avons présenté notre vision d’Explorer, nouvel outil d’analyse et de reporting. C’était l’occasion idéale pour solliciter nos futurs clients-testeurs, avec des démos et des sessions de prise en main du prototype en « one-to-one ». Mais au-delà de ces échanges, nous souhaitions embarquer ces clients sur la durée. Nos ambitions étaient doubles : à la fois leur offrir la possibilité de suivre les évolutions du développement, mais aussi nous permettre de réajuster le produit au fur et à mesure des retours, sans attendre la release d’une version « grand public ».

La mise en œuvre un processus de « co-design » a donc consisté à impliquer des clients volontaires pour répondre à des questionnaires, participer à des ateliers, etc. Au final, 50 personnes ont participé à ce programme.

La phase d’animation du processus

Les processus de co-design ne peuvent fonctionner de façon pertinente que grâce à une approche « donnant-donnant ». Sans pour autant être fréquente, l’animation doit être régulière et alterner les éléments fournis par l’éditeur et ceux fournis par les utilisateurs afin d’entretenir la collaboration.

Nous avons ainsi chouchouté nos clients « cobayes » en leur proposant des éléments exclusifs :

• Une vidéo de présentation des tous premiers développements du produit,
• La mise à disposition d’une pré-version sur leur compte utilisateur,
• Un webinar de prise en main,
• Des newsletters d’avancement du produit

Ils ont ainsi eu le loisir de partager leurs retours via plusieurs canaux :

• Votes pour certaines fonctionnalités via un système de « fausses portes » sur l’interface
• Questionnaire se basant sur le modèle de Kano pour prioriser les grosses fonctionnalités entre elles
• Test ‘de préférence’ pour valider des approches fonctionnelles, notamment sur l’accès aux outils graphiques
• Formulaire ‘in-app’ pour partager les retours en conditions ‘réelle’ d’utilisation
• Entretiens en one-to-one

Les outils du « co-design »

Pour prioriser les fonctionnalités : Kano & fausses portes

Avec le questionnaire Kano, l’objectif était de proposer un certain nombre de fonctionnalités majeures, puis laisser les co-designers s’exprimer sur leur ressenti pour chacune d’elles. Les fonctionnalités suivantes sont apparues comme les plus satisfaisantes auprès des clients :

Fonctionnalités « Indispensables » :
Exporter une analyse
Croiser des dimensions dans un tableau, comme dans Data Query

Fonctionnalité « Attractive » :
Envoyer une analyse depuis Explorer vers un rapport, un tableau de bord, ou Data Query

En parallèle, et pour aller au-delà de la priorisation de fonctionnalités dans une liste (qui pourraient influencer les utilisateurs), nous avons voulu tester le comportement de ces derniers dans un contexte de manipulation directe. Pour cela, dès les tous premiers développements, nous avons disséminé des boutons censés permettre d’accéder à certaines fonctionnalités. Ce système de « fausses portes » nous a permis de mesurer les clics sur ces boutons, ainsi que sur des boutons de vote proposés derrière chaque fausse porte.

Les résultats obtenus via ces deux approches sont pleinement cohérents et nous ont permis de valider trois grosses fonctionnalités prioritaires :

• Envoyer une analyse vers un dashboard ou vers Data Query.
• Créer des segments à la volée depuis Explorer.
• Croiser des dimensions entre elles.

Les 2 premières fonctionnalités ont été mises à disposition dès le lancement de la bêta d’Explorer tandis que la dernière sera proposée dans les prochaines semaines.

Pour choisir une fonctionnalité : tests de préférence

Lors de l’ajout de nouvelles fonctionnalités ou de refontes ergonomiques, plusieurs pistes sont généralement proposées par l’UX designer. Chaque proposition est testée avec différents profils de collaborateurs en interne, et si possible auprès de clients (lors d’afterworks par exemple). Nous retravaillons notre copie jusqu’à ce que la fonctionnalité soit optimale.

Dans certains cas, nous proposons aux co-designers de choisir entre 2 maquettes avec la possibilité d’argumenter leurs choix. Le cas s’est présenté au moment de travailler sur l’accès aux représentations graphiques dans Explorer. Malheureusement ici, pas de préférence marquée, avec un improbable et parfait partage des voix 50/50 : on ne peut pas gagner à tous les coups !

Nous avons donc conservé l’approche initiale de nos prototypes, et ajusterons si nécessaire en fonction des retours de l’ensemble de nos clients après le lancement produit.

Pour recueillir l’avis des clients : Feedback ‘in-app’

En plus d’interactions ponctuelles, nous voulions aussi offrir aux co-designers la possibilité de s’exprimer spontanément sur leur utilisation de la solution. Nous avons donc intégré un formulaire simple, pour que l’utilisateur partage son expérience et son ressenti.

Nous avons ainsi collecté une centaine de retours, qui ont alimenté une partie de notre backlog et nous ont aidé à prioriser les fonctionnalités d’Explorer Bêta.

Les premiers résultats

Le choix et la priorisation de fonctionnalités sont délicats. Il faut trouver un savant équilibre entre des attentes fortes liées au produit existant, les nouveautés procurant une valeur incontestable, et bien sûr, notre propre vision.
Malgré cette difficulté (nécessaire), notre initiative de développements « user centric » a été pour nous plus que satisfaisante. Nos co-designers ont joué le jeu, et nous avons ainsi pu développer un produit réellement orienté utilisateur.

Nous souhaitons maintenir cette dynamique avec l’ensemble de nos clients, notamment en conservant le formulaire de feedback ‘in-app’ dans la version « publique » d’Explorer (puis en le déployant progressivement au reste de la solution). Les tickets de feedback font l’objet d’un suivi régulier afin d’alimenter les backlogs. Un prochain article y sera consacré.

Et toujours dans l’optique d’intégrer nos clients au plus tôt, tous nos produits ‘nouvelle génération’ font également l’objet de programmes beta.

Merci à tous nos clients-codesigners d’avoir contribué activement à l’amélioration de notre solution ! Continuez à nous partager vos retours !