Cet article est publié sous licence CC BY-NC-SA
Les feedbacks, ou devrais-je dire, les retours utilisateurs sont essentiels pour la réussite de votre application web. Cela paraît simple et facile à mettre en place, dans la réalité, cela ne l’est pas du tout. Je vous propose d’étudier dans cet article les différentes façons de recueillir les feedbacks utilisateurs dans une relation entre équipes de développement (créatives, techniques, marketing) et les utilisateurs.
Tout au long du processus de développement de l’application, nous allons identifier les différentes implications des utilisateurs selon les phases de conception, développement et de mise en production. Ensuite, nous aborderons le suivi de la vie de l’application et de ses futures versions.
Prendre en compte les remarques et les besoins de l’utilisateur tout au long du développement et de la vie de l’application web est le but de la conception centrée utilisateur et du « ommunity driven development».
Cette méthode permettra à l’application d’être adoptée par le plus grand nombre et de la conduire au succès. Les utilisateurs sont considérés dès le début du processus de création de l’application puis, de façon itérative. Cela rejoint les méthodes Agiles, qui suivent par définition ce principe.
Pierre Trendel, invité sur le blog, avait déjà abordé la conception centrée utilisateur. De manière accessible, il nous expliquait que cette philosophie avait pour but «de satisfaire, de la manière la plus simple et efficace possible, le besoin d’un utilisateur.»
Satisfaire l’utilisateur passe par plusieurs étapes dont la première est de définir les utilisateurs types. Ces utilisateurs types seront le point de départ des propositions d’interface, pensées en fonction du profil (age, profession, niveau d’usage des technologies web …).
Des groupes d’utilisateurs différents seront à choisir : ils constitueront une première base de test. Ces tests seront menés par différentes méthodes (entretiens individuels, par groupe et tests en action de l’application).
L’ergonome doit s’approprier toutes informations relatives à la culture d’entreprise, de ses méthodes de travail ( tout particulièrement lorsque l’on développe une application métier ) et impliquer via des brainstormings ou des réunions les utilisateurs comme les décideurs.
Si une application était déjà en place mais est devenue désuète, il est, là aussi, très important de relever tous les pros/cons de cette application précédente. Ces informations sont précieuses et très utiles pour améliorer ce qui fonctionne bien et abandonner ou changer ce qui ne fonctionne pas.
Ensuite, on établira des scénarios d’usage qui détermineront et organiseront les fonctionnalités dans le design de l’application. Ces scénarios d’usage permettront de faire plusieurs propositions de wireframes. Les wireframes (design en fil de fer) n’auront pas d’impact visuel que le design pourrait entraver et ne gardent que les caractéristiques concrètes et fonctionnelles. C’est ce que l’on appelle le prototype horizontal.
On aura donc compris que l’implication des utilisateurs commence dès l’ergonomie. En ce qui concerne le design, cela se repose bien sûr sur des aspects subjectifs mais pas seulement. L’identité de la marque
Le designer va se baser sur l’identité de la marque. Il faut donc bien avoir défini son produit, ou créer la continuité avec la charte graphique de la marque. Le design sera ainsi en corrélation avec la cible visée et le positionnement de la marque.
Le design va évoluer et il est souvent conduit par le taux de transformation. Le taux de transformation peut être assimilé au taux d’utilisation d’une fonctionnalité lorsqu’il n’y a pas de notion de vente dans l’application.
Le AB testing design est un très bon moyen de connaître le design qui satisfera au mieux vos utilisateurs. Je vous invite à consulter le guide A/B Testing qui est très complet et avec de nombreux exemples.
Le titre vous a certainement fait sourire mais il est fréquent d’avoir ce genre de retour : « Mes proches trouvent que l’application n’est pas jolie, etc. » Il faut bien comprendre qu’effectivement un design peut ne pas paraître joli à première vue. Mais il faut faire confiance au designer qui connait les finalités de ce design. Il l’aura donc réalisé avec un œil professionnel et expérimenté, que parfois certaines personnes proches de vous n’ont pas. L’exemple de Jérémy Vanhove est parlant lorsqu’il nous explique le cas Cdiscount et de son identité visuelle lowcost qui améliore le taux de transformation.
Chez Synbioz, nous développons nos applications selon les principes Agiles. C’est à dire, entre autre, que nous approchons le développement sous forme itérative avec des retours clients fréquents. Ces retours clients ne sont pas des retours utilisateurs finaux dans la plupart des cas.
Il ne faut donc pas confondre le principe de développement itératif avec les utilisateurs finaux car celui-ci se déroule en plusieurs phases définies dans le temps. Les utilisateurs interviendront à l’étape de développement « alpha » de l’application et en « béta ».
Les utilisateurs sont les mêmes premiers groupes sélectionnés pour leur enthousiasme lors de la conception et qui ont permis de définir l’application. Ils sont donc les premiers à tester l’application. Cette étape permettra de confronter le produit avec les desirata des utilisateurs et aura une forte incidence sur la suite du développement.
La suite du développement va donc extraire les informations pertinentes recueillies et adaptera ou corrigera l’application pour arriver à la phase « béta ». La phase béta est la plus importante car souvent le produit est alors ouvert au public. A cette étape, toutes les informations sont donc importantes car l’application devrait être à un résultat proche du produit final.
Parfois l’application n’est pas encore ouverte complètement au public mais elle est disponible sous invitation. Souvent, c’est une question de gestion de montée en charge ou marketing.
La version alpha, qui est un prototype vertical de l’application doit être mesuré rigoureusement et avec un environnement de test semblable entre chaque utilisateur. Ce qui pourra être mesuré qualitativement et quantitativement sous les critères suivant :
Le même principe sera appliqué à la phase béta avec les mêmes groupes de test et l’ensemble des utilisateurs.
Le principe d’eye tracking (certaines sociétés sont spécialisées dans ce domaine) permet d’avoir d’autres informations très pertinentes sur différentes versions de prototype. Il repose sur une réelle connaissance utilisateur. Attention alors aux applications innovantes et au coût relativement élevé de cette technique.
Je lis souvent que le travail de community manager repose essentiellement sur la vie de la marque sur les réseaux sociaux. Parle-t-on de la marque ? Comment ? Faut-il créer le buzz ? Sa mission serait donc essentiellement de la communication marketing. Je pense que c’est réducteur. Les périmètres du community management doivent être bien plus poussés que simplement lancer une promo sur facebook. Son rôle doit être aussi de remonter dans les trackers de gestion de projet, les anomalies de l’application, les mécontentements d’utilisabilité et les bonnes idées des utilisateurs. Avec l’avènement des réseaux sociaux, c’est une nouvelle pratique qui se met en place. D’ailleurs un terme fait de plus en plus son apparition, celui de développement conduit par la communauté, le « community driven development ».
Pour commencer, il faut mettre en place une veille sur twitter. Analyser les tweets parlant du produit et remonter les tweets comme l’on pourrait le faire pour un feedback mail de l’application. Parfois d’ailleurs, un utilisateur ne voudra pas se confronter à vous et vous expliquer son problème. Par contre, il peut très bien être susceptible de faire un tweet, tout en préservant son anonymat. Grâce à un système de veille et d’archivage, cette information ne disparaîtra pas.
Les utilisateurs qui vous feront le plus de feedbacks, positifs (car il faut les archiver aussi) comme négatifs, seront les utilisateurs qui affirment leur affinité avec la marque (les ambassadeurs). Les pages fan facebook sont un très bon moyen d’avoir du feedback de qualité. Les utilisateurs et fans veulent des choses, vous le font savoir et il faut évidement leur répondre. Mais là aussi, il faut les tracker dans votre système de management de développement.
D’ailleurs, utiliser le service « question » est très intéressant pour les nouvelles fonctionnalités demandées par la communauté et pour montrer que vous les écoutez.
Il ne faut évidement pas oublier les mails. Le mail support est trop souvent cantonné aux équipes chargées de la relation client. C’est une erreur, en tous cas, c’est une erreur si l’équipe ne fait que des rapports à la division Marketing et que celle-ci ne s’intéresse pas au développement de l’application et à son amélioration continue. Ces retours mails doivent être archivés dans le tracker quand il concerne le produit. On évitera de remonter des problèmes liées à un carton défectueux par exemple et qui n’ont aucun rapport avec le développement de l’application web.
Il ne suffit toutefois pas de juste archiver ces remontées. Ces retours utilisateurs doivent être discutés. A vous de trouver votre rythme et de prioriser les développements.
D’autres outils existent pour mener à bien vos retours utilisateurs. Sans parler de Google Alert ou de l’application Mention, l’un des outils les plus connus est certainement « uservoice ». Il s’installe très facilement sur votre application et permet de faire des remontées directement dans votre tracker (si vous avez souscris à cette option).
En conclusion, je reprendrai les mots de Loic Le Meur “because you don’t manage a community, it manages you”. Écoutez vos utilisateurs, impliquez-les et cela sera la voie vers le succès pour votre application web.
L’équipe Synbioz.
Libres d’être ensemble.
336 avenue de Dunkerque
59130 Lambersart
5 rue de douai
75009 Paris
1 rue du Guesclin
44000 Nantes
Nos conseils et ressources pour vos développements produit.