« Persona » : différence entre les versions

De EduTech Wiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
(Annulation des modifications 160921 de JeromeHumbert (discussion))
Balise : Annulation
 
Ligne 1 : Ligne 1 :
{{bloc important|Page rédigée dans le cadre du cours Conduite de la recherche (2021-2022) par [[Utilisateur:JeromeHumbert|Jerome Humbert]] , [[Utilisateur:Franck G.|Franck Grisard]] , [[Utilisateur:Tom Wünsche|Thomas Wünsche]] }}
{{bloc important|Page rédigée dans le cadre du cours Conduite de la recherche (2021-2022) par [[Utilisateur:JeromeHumbert|Jerome Humbert]] , [[Utilisateur:Franck G.|Franck Grisard]] , [[Utilisateur:Tom Wünsche|Thomas Wünsche]] }}
[[Fichier:Persona.png|alt=Exemple d'un persona dans la conception d'une application sportive.|vignette|Exemple d'un persona dans la conception d'une application sportive.]]


=== Problématiques et définition du codage ===
==Description==
Face à la multitude de formes et de sources des données recueillies, il est difficile pour un chercheur sur le terrain de classifier, trier et regrouper toutes ces informations. De plus, lors de la retranscription en verbatim d’entretiens par exemple, la quantité de données est très dense et pas toujours en rapport avec le sujet de la recherche.
Les personas sont des personnes fictives susceptibles de ressembler à un type d'utilisateur auquel est destiné un objet conçu. Ce sont des artefacts, en cela qu'ils sont créés de toute pièce par une équipe pour servir un but (Lallemand, 2016, p.194). Leur description est basée sur une première phase d'exploration qui vise à déterminer à quel genre de public doit s'adresser le produit final. Les personas représentent donc un moyen efficace de se représenter l'utilisateur et aide les concepteurs à les considérer comme personnes, à avoir une forme d'empathie pour eux et à ne pas les voir comme de simples chiffres statistiques. C'est surtout pour cette raison qu'on intègre à leur description des éléments humanisants, comme leur physique, leurs idéaux ou leurs émotions (Nielsen, 2004, p.123).


C’est ici qu’intervient le codage. Le codage permet d’attacher une étiquette sur une donnée ou un bout de celle-ci afin de l’identifier comme étant dans une catégorie précise. Via ces codes identifiant les catégories, il est plus aisé pour le chercheur de retrouver puis d’analyser les données. Cela implique la création de liens entre les données issues de sources diverses et permet au chercheur d’avoir rapidement toutes les informations d’une thématique en particulier dans un but d’analyse.
Outre la décentration du concepteur, les personas sont aussi un outil de communication au sein d'une équipe. Une fois les différentes personnalités fictives connues, on échange plus facilement au sujet des utilisateurs en se référant directement aux personas créés. Un groupe de chercheurs a interrogé des concepteurs habitués de cette pratique. L'un d'eux témoignait : "[Personas] made it easier for designers to get their designs and ideas accepted. So when we started out, the Distinguished Engineer would say, literally... 'I don't like it.' And you know, I'd answer, 'Well, it's not about you, it's about Jennifer, and Bob, and Rose.'" (Whittaker et al., 2012).


=== Types de codes ===
== Différents types de personas ==
Plusieurs types de codes peuvent être définis selon une échelle entre la description et l’inférence. De manière générale, les codes descriptifs sont plus présents en début d’analyse et, lorsque le chercheur décèle des “patterns”, des thèmes ou des leitmotiv, les codes inférentiels se forment.
Plusieurs types de personas peuvent être conçus afin de cibler plusieurs types d'utilisateurs du projet (Rind, R., 2007).
* Le persona primaire. Il représente l'utilisateur principal pour qui le projet est principalement conçu.
* Le persona secondaire. Celui-ci a des besoins et caractéristiques partagés avec le persona principal mais possède également des besoins divergents qui ne seront pas considérés comme secondaires pour le projet.
* Le persona négatif. C'est l'utilisateur qui ne va pas être prit en compte pour le projet. Cela permet de rappeler à l'équipe de conception de limiter le champs du projet aux besoins du persona primaire.
* Le persona acheteur. Ce persona représente le propriétaire du projet une fois achevé ou l'acheteur potentiel. Ses besoins sont donc différents du persona primaire et peuvent être pris en compte tant qu'ils n'interfèrent pas avec ceux du persona primaire.
* Le persona concerné. Ce persona n'est pas directement un utilisateur du projet mais représente quelqu'un qui sera affecté par celui-ci.
* Le persona supplémentaire. Permet de s'assurer que tous les types d'utilisateur aient été pris en compte pour la conception


=== Définir les codes ===
== Avantages et limites ==
La définition des codes au moyen d’une liste des définitions (Codebook) est un élément très important du codage. En effet, le chercher créant les codes n’est pas forcément le même que celui qui va coder ou en d’autres termes attribuer les codes aux informations. De ce fait, n’importe quel chercheur pourra coder au sein de cette recherche en suivant les définitions de ces codes et ainsi chaque chercheur travaillera avec la même organisation des informations. D’où l’importance d'avoir des codes précis, explicites et univoques parmi les chercheurs.
Les personas permettent aux concepteurs de considérer les valeurs et besoins des utilisateurs ciblés en personnifiant des utilisateurs types du projet. Ainsi les concepteurs possèdent une vue d'ensemble de le public cible et détermineront plus précisément le cadre de leur projet. De plus, les personas sont souvent réutilisables pour d'autres projets et peuvent être utilisés par d'autres méthodes de conception. Ils sont donc à conserver précieusement.
Cependant, ils ne sont pas exempt de limites notamment à leur conception. Il n'est pas toujours chose aisée de produire des personas grâce aux données obtenues sur le terrain, cela requiert une certaine expertise. Autre limite, les personas doivent être intégrés au processus de conception et compris par l'ensemble des concepteurs pour pouvoir apporter un rôle pertinent au projet. Ce dernier point peut être vu par l'équipe de conception comme une tâche supplémentaire à réaliser dans une liste de tâche déjà conséquente.


=== Nomenclature ===
== Références ==
Il est fortement conseillé de choisir un nom de code le plus proche possible de la notion qu’il représente. Pour qu’un autre chercheur soit en mesure de retourner au plus vite vers le concept de base, il est important de proscrire les nombres comme code pour éviter de devoir retourner dans la liste des définitions pour faire le lien avec le concept. Plus c’est explicite, mieux c’est.  
Blomquist A. & Arvola M. (2002), « Personas in Action: Ethnography in an Interaction Design Team », Proceedings of NordiCHI 2002, New York, acm, 197-200.


Lallemand, C. (2016). ''Méthodes de design UX, 30 méthodes fondamentales pour concevoir des expériences optimales''. Eyrolles : Paris.
Matthews, T., Judge, T., & Whittaker S. (2012). How do designers and user experience professional actually perceive and use personas? ''Proc. of CHI 2012'', 1219–1228.
Pruitt J. S. & Adlin T. (2006), « The Persona Lifecycle », San Francisco, Morgan Kaufmann.
Rind, R. (2007). The power of the persona. The Pragmatic Marketer, 5(4), 18–22
[[Catégorie:Méthodes de recherche]]
[[Catégorie:Méthodes de recherche]]

Dernière version du 23 mars 2022 à 09:53

Page rédigée dans le cadre du cours Conduite de la recherche (2021-2022) par Jerome Humbert , Franck Grisard , Thomas Wünsche
Exemple d'un persona dans la conception d'une application sportive.
Exemple d'un persona dans la conception d'une application sportive.

Description

Les personas sont des personnes fictives susceptibles de ressembler à un type d'utilisateur auquel est destiné un objet conçu. Ce sont des artefacts, en cela qu'ils sont créés de toute pièce par une équipe pour servir un but (Lallemand, 2016, p.194). Leur description est basée sur une première phase d'exploration qui vise à déterminer à quel genre de public doit s'adresser le produit final. Les personas représentent donc un moyen efficace de se représenter l'utilisateur et aide les concepteurs à les considérer comme personnes, à avoir une forme d'empathie pour eux et à ne pas les voir comme de simples chiffres statistiques. C'est surtout pour cette raison qu'on intègre à leur description des éléments humanisants, comme leur physique, leurs idéaux ou leurs émotions (Nielsen, 2004, p.123).

Outre la décentration du concepteur, les personas sont aussi un outil de communication au sein d'une équipe. Une fois les différentes personnalités fictives connues, on échange plus facilement au sujet des utilisateurs en se référant directement aux personas créés. Un groupe de chercheurs a interrogé des concepteurs habitués de cette pratique. L'un d'eux témoignait : "[Personas] made it easier for designers to get their designs and ideas accepted. So when we started out, the Distinguished Engineer would say, literally... 'I don't like it.' And you know, I'd answer, 'Well, it's not about you, it's about Jennifer, and Bob, and Rose.'" (Whittaker et al., 2012).

Différents types de personas

Plusieurs types de personas peuvent être conçus afin de cibler plusieurs types d'utilisateurs du projet (Rind, R., 2007).

  • Le persona primaire. Il représente l'utilisateur principal pour qui le projet est principalement conçu.
  • Le persona secondaire. Celui-ci a des besoins et caractéristiques partagés avec le persona principal mais possède également des besoins divergents qui ne seront pas considérés comme secondaires pour le projet.
  • Le persona négatif. C'est l'utilisateur qui ne va pas être prit en compte pour le projet. Cela permet de rappeler à l'équipe de conception de limiter le champs du projet aux besoins du persona primaire.
  • Le persona acheteur. Ce persona représente le propriétaire du projet une fois achevé ou l'acheteur potentiel. Ses besoins sont donc différents du persona primaire et peuvent être pris en compte tant qu'ils n'interfèrent pas avec ceux du persona primaire.
  • Le persona concerné. Ce persona n'est pas directement un utilisateur du projet mais représente quelqu'un qui sera affecté par celui-ci.
  • Le persona supplémentaire. Permet de s'assurer que tous les types d'utilisateur aient été pris en compte pour la conception

Avantages et limites

Les personas permettent aux concepteurs de considérer les valeurs et besoins des utilisateurs ciblés en personnifiant des utilisateurs types du projet. Ainsi les concepteurs possèdent une vue d'ensemble de le public cible et détermineront plus précisément le cadre de leur projet. De plus, les personas sont souvent réutilisables pour d'autres projets et peuvent être utilisés par d'autres méthodes de conception. Ils sont donc à conserver précieusement. Cependant, ils ne sont pas exempt de limites notamment à leur conception. Il n'est pas toujours chose aisée de produire des personas grâce aux données obtenues sur le terrain, cela requiert une certaine expertise. Autre limite, les personas doivent être intégrés au processus de conception et compris par l'ensemble des concepteurs pour pouvoir apporter un rôle pertinent au projet. Ce dernier point peut être vu par l'équipe de conception comme une tâche supplémentaire à réaliser dans une liste de tâche déjà conséquente.

Références

Blomquist A. & Arvola M. (2002), « Personas in Action: Ethnography in an Interaction Design Team », Proceedings of NordiCHI 2002, New York, acm, 197-200.

Lallemand, C. (2016). Méthodes de design UX, 30 méthodes fondamentales pour concevoir des expériences optimales. Eyrolles : Paris.

Matthews, T., Judge, T., & Whittaker S. (2012). How do designers and user experience professional actually perceive and use personas? Proc. of CHI 2012, 1219–1228.

Pruitt J. S. & Adlin T. (2006), « The Persona Lifecycle », San Francisco, Morgan Kaufmann.

Rind, R. (2007). The power of the persona. The Pragmatic Marketer, 5(4), 18–22