Personnages dans les systèmes d'applications Web d'entreprise
Je participe à un projet qui remplacera un système d'information sur les étudiants dans un établissement postsecondaire. Je décrirais la portée de ce projet comme très large, comprenant environ 200 à 250 sous-processus connus (plus ceux que nous ne connaissons pas encore), qui sont regroupés en ~ 70 processus, qui sont à leur tour regroupés en 14 vastes domaines de processus (par exemple, admissions, enregistrement). Ce système unique sera utilisé par les étudiants, le personnel et les professeurs tout au long du cycle de vie des étudiants. Nous entrons actuellement dans une phase initiale de collecte des exigences qui durera environ 4 à 6 mois. C'est donc notre opportunité de nous engager dans des activités de recherche d'utilisateurs.
Je crois que les personnages sont d'excellents outils pour emballer et partager notre compréhension des publics cibles. Mais presque toute la littérature que j'ai lue (livres, articles, etc.) parle de personnages dans le contexte de systèmes à usage unique ou de systèmes à faible nombre de buts. Il n'est donc pas surprenant qu'une grande partie de cette littérature parle de minimiser le nombre de personas que vous avez (par exemple 3-5 personas distincts); cela a du sens pour moi et j'aimerais le faire.
Oui, nous avons trois publics principaux - les étudiants, le personnel et les professeurs - mais ceux-ci sont beaucoup trop larges pour être utiles comme artefacts de conception. À titre d'exemple, les étudiants internationaux ont des besoins très distincts des étudiants nationaux. Si j'avais 3-5 personnes par zone de processus, je regarderais quelque chose comme 42 à 70 personnes au total. Est-ce raisonnable, et encore moins réalisable?
Ma question est donc la suivante: quelqu'un d'autre a-t-il déjà eu de l'expérience dans le développement de personas pour des systèmes d'information avec une portée fonctionnelle massive, et si oui, comment avez-vous abordé le développement de persona? Combien en avez-vous fini avec?
J'en fais un maintenant. Je travaille pour un logiciel d'entreprise. Notre logiciel semble avoir au moins 10 fois la taille de la vôtre, cependant, nous sommes très conscients de nos types d'utilisateurs (types car il existe différents types d'utilisateurs). 1) les informaticiens qui administrent le logiciel 2) l'utilisateur réel 3) les personnes qui consultent, approuvent, commentent, collaborent au travail de l'utilisateur (appelez-le manager) 4) la partie prenante (essentiellement des personnes de niveau beaucoup plus élevé) et je veux juste jeter un coup d'œil ... ils n'ont peut-être même pas accès au logiciel, mais nous pouvons leur fournir une vue via un lien e-mail spécifique)
Je crée un personnage pour chacun de ces 4 types d'utilisateurs. Évidemment, je vais me concentrer sur # 2, mais je ne veux pas rejeter l'autre.
Fondamentalement, vous devez prendre quelques éléments en considération: 1) Ces utilisateurs utilisent-ils des fonctionnalités différentes (si oui, décidez comment les fonctionnalités seront séparées pour chaque groupe d'utilisateurs) 2) Si les mêmes fonctionnalités, les utilisent-elles différemment (si oui, décidez du nombre de façons de l'utiliser, grosso modo) 3) Sur la base de 1 et 2, vous pouvez décider du nombre de types de personnages.
Je ne crois pas que la personnalité devrait être différenciée parce que la démographie est différente. Mais c'est mon opinion.
Aurora Bedford fait un excellent travail expliquant les personnages et leur création et application . Un point clé qui peut vous aider est que les personnages ne sont pas des groupes d'utilisateurs. Il s'agit essentiellement d'une moyenne d'un ensemble de points de données. Pensez aux créateurs de vêtements pour le marché de masse. Ils doivent concevoir des vêtements qui peuvent être vendus sur étagère, pas sur mesure pour chaque client. Ainsi, un ensemble de moyennes est regroupé en "tailles". Très peu de personnes s'intègrent parfaitement dans une taille, mais la majorité des clients s'inscrivent généralement dans l'une des tailles données. Le nombre de tailles disponibles dépend des caractéristiques de la population cliente clé.
De la même manière, les personnages ne conviennent pas autant à chaque utilisateur que ce sont des modèles qui reflètent les caractéristiques de la majorité de vos utilisateurs. Une analyse minutieuse de la recherche d'utilisateurs de qualité devrait révéler le nombre de tailles (ou de personnages) dont vous aurez besoin.
Je pense que c'est une erreur de classer vos personnages par domaine de processus. La valeur d'un personnage réside dans la création d'une référence rapide afin que tous les membres de votre équipe de produits sachent QUI est l'utilisateur. C'est pourquoi ils sont généralement décontractés ou amusants - pour qu'il soit plus facile de se rappeler, par exemple, que "Bobby Beginner" représente un groupe de personnes réelles qui bénéficieront d'instructions supplémentaires dans tout le système.
Au lieu de cela, j'imagine que les zones de processus seraient un point de données que vous incluez sur chaque personnage. S'il ne sera pas utile de trouver une poignée de professeurs, d'étudiants et de personnel, essayez peut-être de choisir des catégories de rôles légèrement plus spécifiques: si vous deviez regrouper tous les membres du personnel en 5 groupes, quels seraient-ils? Le tri des cartes ouvertes sera utile pour cela.
FWIW Je travaille sur un produit d'entreprise et je développe 2 à 4 personas pour chaque catégorie d'utilisateurs. En ce moment, nous avons affaire à environ 5 groupes d'utilisateurs.
Les meilleurs personnages doivent être considérés comme des personnes réelles (quoique fictives) et non comme des "utilisateurs élastiques". En ce qui concerne les grands systèmes complexes avec de nombreux groupes d'utilisateurs, vous avez résolu le problème. Comment équilibrez-vous le fait d'avoir suffisamment de personas pour capturer la variance au sein des membres d'un groupe d'utilisateurs diversifié dans vos personas et d'avoir une poignée de personas saillants avec lesquels l'équipe de projet peut s'identifier?
La vision pragmatique de ce problème pourrait être de recadrer la question comme "Pour combien de personnages pouvez-vous créer de manière réaliste de grandes expériences?" Ensuite, choisissez stratégiquement les sous-groupes les plus importants sur lesquels baser ces personnages.
Avouons-le, pour tous les grands projets, il est presque impossible pour vous de concevoir un système avec des expériences utilisateur parfaites pour tout le monde, même si vous avez des ressources illimitées. Avec des contraintes de budget et de temps, il n'y a aucun moyen de rendre le système idéal pour tous les groupes d'utilisateurs. Alors, reconnaissons simplement ce fait et choisissons les sous-groupes importants et concentrons-nous sur la fourniture de bonnes expériences à ces personnes. Après tout, de bonnes expériences pour des groupes sélectionnés sont bien meilleures que des expériences médiocres pour tout le monde.
Comment décidez-vous quels sont les sous-groupes les plus importants? Vos parties prenantes seraient essentielles pour prendre cette décision. Les impliquer dans ce processus vous aide à identifier les domaines et les personnes qui comptent pour eux. Il y a aussi un avantage secondaire à ce que vous puissiez les impliquer dans le processus de création de ces personnages. Il contribue à favoriser un sentiment d'appartenance afin que vos parties prenantes adhèrent aux personnalités et à travers elles tout le processus de conception UX first.
Les personas n'ont pas besoin d'être limités aux produits à plus petite échelle. Je dirais qu'ils aident à hiérarchiser les caractéristiques/fonctions qui devraient être repensées ou même supprimées du produit repensé. De plus, ils peuvent servir d'outils de communication lorsqu'ils discutent des décisions de conception avec d'autres membres de l'équipe de projet.
J'ai récemment mené des interviews/observations d'utilisateurs et développé des personas pour une application d'entreprise dirigée vers une industrie spécifique qui a de même une base d'utilisateurs très large avec des modèles d'utilisation très différents.
Mon approche était de prendre les principales catégories d'utilisateurs (dans votre cas, les étudiants, les professeurs, le personnel) et à partir de là, d'identifier les sous-catégories d'utilisateurs dans chaque catégorie principale, comme les étudiants nationaux et internationaux que vous avez mentionnés. Les sous-catégories d'utilisateurs étaient des descriptions plus spécifiques mais toujours à nu des utilisateurs et de leurs besoins, objectifs, attributs, etc. sous forme de liste. Vous pouvez le faire sans procéder à des entretiens avec les utilisateurs; valider et compléter les détails au fur et à mesure que vous avancez dans le processus de recherche et communiquez avec les parties prenantes.
Cet exercice peut vous donner une meilleure vue de la plupart des types d'utilisateurs que vous allez concevoir pour ce projet et vous aider à extraire quelques personnages à utiliser comme public principal pour le projet de refonte. Vous pouvez vous concentrer sur les objectifs et tâches de haut niveau que le produit doit accomplir avant de plonger dans des domaines de processus spécifiques.