Haaaaa mon sujet préféré !
Il y a de nombreuses façon, ça va dépendre du nombre d'utilisateurs.
La première est de mettre en place des outils "à leur insu" : ex : A/B testing ou statistiques d'usage.
Ensuite il y a ce qu'on pourrait appeler le "commentaire sollicité". C'est à dire, après une action qu'on cherche à mesurer, poser une question courte sur le degré de satisfaction. Et en fonction de la réponse, on peut aller plus loin pour qualifier le retour.
Evidemment, un formulaire de contact spontané.
Et le top du top, c'est une Roadmap publique qui prend en compte les demandes utilisateurs. Sptify a un super truc pour ça : community.spotify.com/t5/New-Ideas/ct-p/newide...
Au plaisir de rebondir sur le sujet !
Comment impliquer les utilisateurs finaux au cours du développement d'une application mobile ?
il y a 8 ans
par
Marrof
Pour que l'appli corresponde bien aux attentes réelles des utilisateurs, et non à l'idée que le développeur s'en fait.
collaboratif développement
4
5
7 réponses
Hé hé, il y a aussi des choses structurées qui existent depuis presque 60 ans avec l'ergonomie
et qui se sont fortement structurées dans les années 90 autour de l'ergonomie cognitive et des démarches de conception centrées utilisateurs:
Analyse préalable
- analyse de besoins, identification des profils utilisateurs
- Personnae et profils utilisateurs novice/moyen/expert
- liens entre l'usage et le découpage des menus, écrans, fonctions,
Definitiin de tes besoins dintegration utilisateurs
- Pourquoi veux tu les intégrer ?
-Quel protocole de tests ?
-Comment construis tu les choses pour que tu ne fasses pas que du oui-oui validation (chemins erronés, trappes, concurrence...)
Choisir ton moment et le nombre de fois
Au début, concepts, idees, living lab, tests in situ rapides
Ensuite tests sur scénarios
Questionnaire
Validations itératives....
A minima, critères bastien scapin/ergo logiciel. Regardes livres et vidéo Amelie Bouchet aussi
Quelques exempls aussi chez nous sur idenea.fr
N'hésites pas, je peux compléter la réponse aussi sur d'autres aspects
et qui se sont fortement structurées dans les années 90 autour de l'ergonomie cognitive et des démarches de conception centrées utilisateurs:
Analyse préalable
- analyse de besoins, identification des profils utilisateurs
- Personnae et profils utilisateurs novice/moyen/expert
- liens entre l'usage et le découpage des menus, écrans, fonctions,
Definitiin de tes besoins dintegration utilisateurs
- Pourquoi veux tu les intégrer ?
-Quel protocole de tests ?
-Comment construis tu les choses pour que tu ne fasses pas que du oui-oui validation (chemins erronés, trappes, concurrence...)
Choisir ton moment et le nombre de fois
Au début, concepts, idees, living lab, tests in situ rapides
Ensuite tests sur scénarios
Questionnaire
Validations itératives....
A minima, critères bastien scapin/ergo logiciel. Regardes livres et vidéo Amelie Bouchet aussi
Quelques exempls aussi chez nous sur idenea.fr
N'hésites pas, je peux compléter la réponse aussi sur d'autres aspects
@Julien : le lucky luke de Skiller sur ces sujets des applis mobile.
On peut faire classique: étude de marché, retour terrain, agence de com pour mieux cerner les besoins utilisateurs;
le réel : faire une ou des versions Beta, les faire tester à un groupe de personnes proches et de confiance (retour concret, critique sans complaisance, avec une bonne représentation de tous les profils; geeks, non geeks, ....)
Si groupe plus large, mise en place d'un retour analytics sur les usages en temps réel, fonctions utilisées, parcours d"utilisateur, pour faire évoluer ton appli suivant les utilisations.
Toutes les applis font du 'running learning' après un premier débugage, lance sur le marché et font évoluer les mise à jours pour fixer les bugs mais aussi intégrer des modifs issus des premiers retours massifs d"utilisateurs.
On peut faire classique: étude de marché, retour terrain, agence de com pour mieux cerner les besoins utilisateurs;
le réel : faire une ou des versions Beta, les faire tester à un groupe de personnes proches et de confiance (retour concret, critique sans complaisance, avec une bonne représentation de tous les profils; geeks, non geeks, ....)
Si groupe plus large, mise en place d'un retour analytics sur les usages en temps réel, fonctions utilisées, parcours d"utilisateur, pour faire évoluer ton appli suivant les utilisations.
Toutes les applis font du 'running learning' après un premier débugage, lance sur le marché et font évoluer les mise à jours pour fixer les bugs mais aussi intégrer des modifs issus des premiers retours massifs d"utilisateurs.
Chère @Marrof, peut-être quelques réponses dans la toute première question de Skiller : skiller.fr/question/1 :)
Que veux-tu dire par "impliquer" ? Pour le départ on peut faire simple: groupe Facebook d'early adopters, landing page etc... pour récolter des données qualitatives. Un early adopter a toujours envie de donner son avis. Twitter est un excellent outil également.
Après d'un point de vue quantitatif, construire un formulaire simple sur la base des retours quali pour mesurer des points spécifiques...
Après d'un point de vue quantitatif, construire un formulaire simple sur la base des retours quali pour mesurer des points spécifiques...
Par "impliquer" je veux dire, presque, "faire en sorte que ce soit les utilisateurs finaux qui créent l'appli selon leurs envies".
Car même en faisant analyse des besoins / étude de marché / etc.. il y a toujours une part d'interprétation de la part du développeur, et on peut partir sur une fausse bonne idée. Or dans ce cas, une version beta test est déjà trop avancée, puisqu'il s'agit d'apporter des légères améliorations (et non de changer totalement le concept de base).
Ce que j'en conclus, c'est qu'il faut dès le début se constituer un panel représentatif d'utilisateurs. On peut ainsi susciter l'échange régulièrement, et être réellement les réalisateurs de leurs envies.
Car même en faisant analyse des besoins / étude de marché / etc.. il y a toujours une part d'interprétation de la part du développeur, et on peut partir sur une fausse bonne idée. Or dans ce cas, une version beta test est déjà trop avancée, puisqu'il s'agit d'apporter des légères améliorations (et non de changer totalement le concept de base).
Ce que j'en conclus, c'est qu'il faut dès le début se constituer un panel représentatif d'utilisateurs. On peut ainsi susciter l'échange régulièrement, et être réellement les réalisateurs de leurs envies.
Les testst utilisateurs en face à face sont et restent, pour moi ergonome, une vraie façon d'impliquer les utilisateurs ou d'intégrer leur point de vue dans le développement.
la question à laquelle on s'affronte lors de la conception de produits, d'interfaces ou d'interactions "centrée utilisateurs" tient à l'écart entre les opinions émises et ce qu'il faut en retenir pour la conception
d'où la nécessité dans ton processus
- de définir/connaitre/identifier les utilisateurs : qui sont-ils ? que font-ils avec ton produit ? quelle est le processus global d'utilisation (pendant l'utilisation et hors utilisation)
- d'intégrer y compris les utilisateurs cachés : une grand mère qui gardent ses petits enfants le mercredi est une utilisatrice cachée du jeu pour enfant disponible sur la tablette, car c'est elle qui pilote la situation et l'utilisation. une infirmière est une utilistrice cachée d'une interface destinée au médecin; un enfant est une utilisateur caché d'un produit acheté par ses parents mais qui trainent ou qui se trouvent dans son téléphone
- de sortir des stéréotypes et de construire des vrais personnages représentatitifs des cibles : tous les jeunes ne sont pas des geeks, tous les vieux ne sont pas inaptes en informatiques, toutes les femmes ne sont pas génées avec les repères d'orientation ...
- de différencier le niveau d'expertise sur ton produit : découverte, première utilisation, utilisation régulière
dans les tests/itérations avec les utilisateurs
- quelles sont les difficultés réelles ? comment les identifier ?
- faire la différence entre ce qu'ils te disent et ce dont ils ont besoin
- faire la différence entre ce qu'ils disent et ce qu'ils font avec ton produit : par exemple tout le monde dis que la tente 2sec est géniale mais personne n'arrive à la replier
il est important
- de reboucler plusieurs fois avec des utilisateurs "externes" à ton équipe pour avoir des retours variés
- de ne pas faire appel qu'à du "en ligne", les comportements de réponse à questionnaire n'ont souvent rien à voir avec l'utilisation réelle des produits/interfaces
- les test peuvent se faire avec des maquettes mousses, des écrans papier, des protos, des produits finalisés, des 3D imprimées ... tout est intéressant pourvu qu'on sache ce qu'on veut faire tester
- ne pas faire de tests si on ne sait pas ce qu'on veut valider
- rien ne remplace l'appel au terrain et à l'observation, à la rencontre avec les utilisateurs
la question à laquelle on s'affronte lors de la conception de produits, d'interfaces ou d'interactions "centrée utilisateurs" tient à l'écart entre les opinions émises et ce qu'il faut en retenir pour la conception
d'où la nécessité dans ton processus
- de définir/connaitre/identifier les utilisateurs : qui sont-ils ? que font-ils avec ton produit ? quelle est le processus global d'utilisation (pendant l'utilisation et hors utilisation)
- d'intégrer y compris les utilisateurs cachés : une grand mère qui gardent ses petits enfants le mercredi est une utilisatrice cachée du jeu pour enfant disponible sur la tablette, car c'est elle qui pilote la situation et l'utilisation. une infirmière est une utilistrice cachée d'une interface destinée au médecin; un enfant est une utilisateur caché d'un produit acheté par ses parents mais qui trainent ou qui se trouvent dans son téléphone
- de sortir des stéréotypes et de construire des vrais personnages représentatitifs des cibles : tous les jeunes ne sont pas des geeks, tous les vieux ne sont pas inaptes en informatiques, toutes les femmes ne sont pas génées avec les repères d'orientation ...
- de différencier le niveau d'expertise sur ton produit : découverte, première utilisation, utilisation régulière
dans les tests/itérations avec les utilisateurs
- quelles sont les difficultés réelles ? comment les identifier ?
- faire la différence entre ce qu'ils te disent et ce dont ils ont besoin
- faire la différence entre ce qu'ils disent et ce qu'ils font avec ton produit : par exemple tout le monde dis que la tente 2sec est géniale mais personne n'arrive à la replier
il est important
- de reboucler plusieurs fois avec des utilisateurs "externes" à ton équipe pour avoir des retours variés
- de ne pas faire appel qu'à du "en ligne", les comportements de réponse à questionnaire n'ont souvent rien à voir avec l'utilisation réelle des produits/interfaces
- les test peuvent se faire avec des maquettes mousses, des écrans papier, des protos, des produits finalisés, des 3D imprimées ... tout est intéressant pourvu qu'on sache ce qu'on veut faire tester
- ne pas faire de tests si on ne sait pas ce qu'on veut valider
- rien ne remplace l'appel au terrain et à l'observation, à la rencontre avec les utilisateurs
J'adore cette question !
Beaucoup de (bonnes) réponses ont été données mais j'en trouve certaines un peu philosophiques.
Je m'explique : l'idée de l'utilisateur final est importante mais parfois et souvent erronée !
Il a souvent été attribuée à Henry Ford la citation suivante : "Si j'avais demandé aux gens ce qu'ils voulaient, il m'auraient répondu des chevaux qui vont plus vite !" (Pour les passionnés, je recommande la lecture de cet article de la HBR : hbr.org/2011/08/henry-ford-never-said-the-fast... )
Qu'il l'ait dite ou pas, cette citation est mentionnée (et attribuée à Ford) à chaque atelier sur l'innovation.
En revanche, cette autre citation (certaine) de Ford revêt un tout aussi intéressant intérêt : "Les clients peuvent choisir la couleur de leur voiture, du moment que c'est noir !"
Steve Jobs disait en 1997, "il faut savoir dire non !" ( www.youtube.com/watch?v=H8eP99neOVs )
Ce que ces 2 citations (avérées ou pas) et cette vidéo évoquent en moi, c'est que l'entrepreneur ou le développeur (s'il est le porteur de l'idée) doivent parfois imposer leurs idées et tenter de faire bouger les lignes. De là naissent les grandes applications.
Si maintenant (et la question est assez vaste pour laisser cette hypothèse), l'objectif est d'impliquer des bêta-testeurs, ou des "early-adopters" il existe plein de manières de le faire; certaines ont été citées mais dans le monde plein d'outils dans lequel nous évoluons il peut être intéressant de jeter un oeil à certains :
- partage de prototypes : pixate www.pixate.com
- wireframe, prototype, partage : azure www.axure.com
- prototype, collaboration, workflow : invision www.invisionapp.com
enfin pour les beta-test avant le lancement : TestFlight (iOS) developer.apple.com/testflight/
Il existe plein d'autres outils pour vous aider.
Si je peux me permettre un dernier conseil tirer de mon expérience : "N'écoutez jamais les power-users !". Trop souvent ils sont les seuls à vouloir faire quelque chose de très spécifique et vous détournent d'une approche de masse.
Bonne chance.
Beaucoup de (bonnes) réponses ont été données mais j'en trouve certaines un peu philosophiques.
Je m'explique : l'idée de l'utilisateur final est importante mais parfois et souvent erronée !
Il a souvent été attribuée à Henry Ford la citation suivante : "Si j'avais demandé aux gens ce qu'ils voulaient, il m'auraient répondu des chevaux qui vont plus vite !" (Pour les passionnés, je recommande la lecture de cet article de la HBR : hbr.org/2011/08/henry-ford-never-said-the-fast... )
Qu'il l'ait dite ou pas, cette citation est mentionnée (et attribuée à Ford) à chaque atelier sur l'innovation.
En revanche, cette autre citation (certaine) de Ford revêt un tout aussi intéressant intérêt : "Les clients peuvent choisir la couleur de leur voiture, du moment que c'est noir !"
Steve Jobs disait en 1997, "il faut savoir dire non !" ( www.youtube.com/watch?v=H8eP99neOVs )
Ce que ces 2 citations (avérées ou pas) et cette vidéo évoquent en moi, c'est que l'entrepreneur ou le développeur (s'il est le porteur de l'idée) doivent parfois imposer leurs idées et tenter de faire bouger les lignes. De là naissent les grandes applications.
Si maintenant (et la question est assez vaste pour laisser cette hypothèse), l'objectif est d'impliquer des bêta-testeurs, ou des "early-adopters" il existe plein de manières de le faire; certaines ont été citées mais dans le monde plein d'outils dans lequel nous évoluons il peut être intéressant de jeter un oeil à certains :
- partage de prototypes : pixate www.pixate.com
- wireframe, prototype, partage : azure www.axure.com
- prototype, collaboration, workflow : invision www.invisionapp.com
enfin pour les beta-test avant le lancement : TestFlight (iOS) developer.apple.com/testflight/
Il existe plein d'autres outils pour vous aider.
Si je peux me permettre un dernier conseil tirer de mon expérience : "N'écoutez jamais les power-users !". Trop souvent ils sont les seuls à vouloir faire quelque chose de très spécifique et vous détournent d'une approche de masse.
Bonne chance.