chargement des résultats

Postes

  • ·
  • ·
  • Astuce pour vos test utilisateurs: Regardez vos tests sans le son.
    Vu sur linkedin et je pense que cela fait sens si vous étiez le seul modérateur par exemple. (cela m'arrive souvent.) Il est facile de se concentrer sur les ressentis et les émotions du participant, relancer et manquer de voir un comportement. wikihero-image-id: 1232
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment utiliser chatGPT sur les projets de test utilisateurs
    Webinaire gratuit en Anglais organisé ce mercredi à 15h , où le head of UXR de UBS partagera son REX sur le sujet. Lien de l'event: https://www.linkedin.com/events/7117140238702911488/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Pourquoi la recherche stratégique à besoin d'être redéfinie
    Très bon article qui sort un peu des sentiers battus de ce que lit on ce moment sur la différence stratégique et évaluative. Par définition l'évaluative est stratégique et le défi de l'utilisabilité n'est pas un problème simple. (si votre produit ramène des revenus) A découvrir ici
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: Comment la recherche utilisateur à un impact sur les processus organisationnels

    J'ai relevé un défi que j'ai réussi à relever avec succès : faire évoluer les pratiques de recherche sur la production d'éléments monétisables (rex ici)

    En démontrant qu'il était possible d'obtenir des résultats exploitables plus tôt, cela est devenu un processus standard. Ainsi, des tests utilisateurs axés sur la monétisation dans les jeux doivent maintenant être effectués avant la sortie du jeu.

    Ces tests ont entraîné des changements dans la façon dont la production crée les éléments de monétisation, à la fois en termes de planification et de livrables. 

  • Nous avons entamé des discussions avec les designers sur les types de matériel expérimental nécessaires pour effectuer ces tests.
  • Par exemple, nous encourageons les concepteurs à créer des prototypes plus tôt et à mettre en place un flux de production permettant des itérations et une anticipation, afin de maîtriser les coûts.
  • D'autre part, la recherche utilisateur permet de modifier l’approche des designers et des producteurs quant au processus créatif.
  • Ce qui est paradoxal dans cette histoire, c'est qu'il n'est parfois même pas nécessaire de mener des recherches utilisateurs.
  • Les concepteurs, en créant des prototypes, sont déjà capables de détecter et de résoudre 70 % des problèmes par eux-mêmes.
  • En revanche, si une approche plus traditionnelle en cascade avait été utilisée, avec une spécification détaillée, une construction et une finalisation tardive, rien ne fonctionnerait lors de l'interconnexion de tous les éléments.

    Ainsi, la recherche utilisateur contribue à modifier le flux de travail de manière significative. Ce qui est intéressant, c'est que historiquement dans le domaine des jeux, la recherche intervient à la fin du processus. 

    Dans d'autres industries, la recherche utilisateur peut être présente dès le début mais absente à la fin, cela dépend du contexte. 

  • Historiquement, dans notre cas, nous provenons du contrôle de qualité (QC). Nous utilisions des tests effectués par les développeurs eux-mêmes, et souvent ce sont les éditeurs qui assuraient le contrôle de qualité. Les éditeurs intervenaient à la fin du projet pour valider et décider si le jeu serait publié ou non.
  • Nous avons entrepris de remonter le processus jusqu'à la phase de pré-conception. Je pense que dans les milieux créatifs, l'expérimentation est souvent limitée à des essais internes, et le produit n'est exposé au public qu'à la fin. Il s'agit d'une mentalité spécifique qui freine notre progression en termes de conception et de prototypage plus précoce.

    J'ai beaucoup réfléchi à ce problème où la recherche est réalisée en amont mais pas à la fin, ou à la fin mais pas en amont, et cela m'a amené à réfléchir aux types d'informations et d'observations que vous pouvez fournir en fonction de la phase du projet.

  • Pour les demandes de type prospective ou portant sur l'intention, nous réfléchissons en termes de risques, d'opportunités et de limites. Cependant, pour que cela se produise, les concepteurs (ou autres parties prenantes) doivent être ouverts à cette mentalité. Cela permet d'anticiper, mais pas de prévoir exactement.
  • Pour les demandes d'évaluation, nous procédons à des tests pour déterminer ce qui fonctionne et ce qui ne fonctionne pas, et nous cherchons à comprendre pourquoi. Pendant longtemps, la narration dans les jeux n'était pas testée. C'est pourquoi nous avons commencé à travailler sur un projet visant à montrer qu'il était possible de tester des extraits de scripts, des scènes coupées et à réaliser des montages vidéo pour évaluer la compréhension de la narration.

    En conclusion, pour réussir à faire évoluer la production, il est essentiel de proposer en tant que chercheur des méthodes et des idées d'observations potentielles. Ensuite, il faut co-construire avec les concepteurs dans leur exploration du design et leur processus créatif.

    Pour donner un contre-exemple où la recherche est très présente en amont mais moins à la fin, je pense à l'industrie automobile et à d'autres domaines fortement axés sur l'ingénierie. 

    Dans ces cas-là, les recherches se concentrent davantage sur les neurosciences et les aspects scientifiques, comme la conception des cockpits et la charge cognitive. 

    Malheureusement, il y a moins de recherche effectuée après l'implémentation.  Il suffit de regarder la tendance des écrans tactiles. Il faut quinze étapes pour effectuer une action qui était auparavant réalisée avec un simple bouton, et l'on se demande pourquoi ils n'ont pas testé cette conception jusqu'au bout. Parfois, l'esthétique prime. Dans ces cas-là, on réalise que la recherche utilisateur peut être très présente en amont, mais moins après l'implémentation. Dans notre domaine, c'est l'inverse : la recherche est très présente lors de l'implémentation, mais beaucoup moins en amont, lors de la phase de conception.

  • merci! Utile
  • Pas utile
  • Pas sûr
  • REX, sur l’utilisation de la biométrie et de l’eye tracking.

    Dans la continuité de mon doctorat en neurosciences, j'ai rejoint Ubisoft en 2014 en tant qu'expert en données biométriques pour les playtests. Pendant plusieurs années, ma principale mission a été de déterminer comment intégrer les outils de neurosciences tels que l'eye-tracking, l'activité cardiaque et l'électrodermale dans les playtests quotidiens. Mon objectif était de définir quelles mesures utiliser, quelles données collecter et dans quel but. J'étais également responsable de la réalisation de ces tests avec ces outils.

    J'aimerais maintenant partager des cas où l'utilisation de l'eye-tracking est pertinente, ainsi que ceux où ce n'est pas le cas.

    Par exemple, pour les menus, l'eye-tracking n’est pas le plus utile. Il n'y a pas de contrainte de temps, et c'est un point essentiel à prendre en compte pour décider d'utiliser ou non l'eye-tracking.

    L'eye-tracking permet d'observer l'attention, ce qui est d'ailleurs une pratique courante en neurosciences. L'attention correspond aux priorités que notre cerveau attribue à différents objets visuels, car il ne peut pas tout traiter en tant qu'information. L'avantage de l'eye-tracking est qu'il nous permet de savoir sur quoi l'utilisateur se concentre au lieu de ce qui était souhaité. À partir de là, nous pouvons déduire les changements visuels à apporter pour attirer l'attention où nous le souhaitons.

    Dans le cas des menus, l'utilisateur.trice est généralement fixé devant son écran et dispose de tout le temps nécessaire pour visualiser les éléments. Dans ce cas, d'autres méthodes de recherche utilisateur sont plus appropriées pour évaluer la validité d'un menu.

    Les menus ne présentent pas de défis visuels, mais plutôt des défis de compréhension et d'architecture de l'information. L'eye-tracking n’est donc pas le meilleur outil pour étudier l'utilisateur dans un menu, sauf dans des cas spécifiques de sites web avec des aspects marketing.

    Pour évaluer l'utilisabilité d'un site web, l'eye-tracking n'est pas nécessairement idéal non plus comme pour un menu sauf si on s’intéresse aux premières secondes et “au côté appealing du site web”.

    Le recueil verbal des pensées à voix haute (think aloud) combiné aux tâches de l'utilisateur et aux retours d'expérience suffisent généralement.

    En utilisant cette approche, l'utilisateur peut expliquer ce qu'il a fait, comme dans cet exemple : "Tu m'as demandé de chercher des sandales sur un site de vente en ligne. J'ai cherché, mais je n'ai pas trouvé la barre de recherche. Ensuite, dans le menu arborescent, je ne savais pas où trouver les sandales."

    Ces informations peuvent être obtenues sans avoir besoin de l'eye-tracking.

    L'eye-tracking est plus pertinent lorsque l'enjeu est de capter l'attention de l'utilisateur dans les cinq premières secondes, notamment pour des marques prestigieuses comme L'Oréal ou Chanel. Dans ces cas-là, les concepteurs peuvent chercher à attirer l'attention de manière spécifique sur leur site web afin de créer une expérience utilisateur émotionnelle qui retiendra l'utilisateur. Dans de tels cas, l'eye-tracking devient pertinent plutôt qu’un test avec de la verbalisation à voix haute.

    Mais alors dans quel contexte utiliser l'eye tracking?

    Il s'agit de situations où il y a un défi visuel, un défi visuo-attentionnel lié à la surcharge cognitive. 

    Un excellent exemple est lorsque vous êtes aux commandes d'un avion ou dans un cockpit de voiture, où il y a des enjeux de sélection d'objets. 

    Dans de telles situations, l'utilisateur ne peut pas être interrompu pendant qu'il effectue ses tâches. Verbaliser la tâche briserait complètement sa concentration visuelle, en raison de la charge cognitive et des considérations sociales, rendant le "think-aloud" impossible. C'est là que l'eye tracking devient pertinent.

    Les décisions doivent être prises rapidement et il ne faut pas manquer d'informations visuelles cruciales.

    En utilisant l'eye tracking dans ce contexte, on peut observer : "Cette information a pris la priorité alors qu'il n'a pas vu ce retour visuel important, et sa réaction a été erronée, ce qui a entraîné son échec." 

    Ou encore :

    "Il était concentré sur un autre retour visuel qui est apparu simultanément, il y a eu un problème de synchronisation entre les deux, ce n'est pas bon."

    En ce qui concerne les échantillons en eye tracking (car on me pose souvent la question), nous n'avons pas besoin d'un nombre plus élevé de personnes par rapport aux tests utilisateurs, car nous ne faisons pas d'analyse quantitative. 

    Si, par exemple, sur six personnes, aucune ne remarque l'objet visuel que nous souhaitions qu'elles voient, et qu'elles regardent toutes ailleurs de la même manière, six personnes suffisent pour détecter un problème de conception et de design. 

    Cependant, il y a des moments où l'on s'oriente davantage vers le marketing et où l'on s'intéresse davantage à la science visuelle, tels que l'ordre d'observation des objets, ce qui attire le plus l'attention, ou sur quel objet le regard se fixe le plus longtemps, traduisant une préférence. 

    Dans ce cas, 12, 16, 24, voire 32 utilisateurs peuvent être nécessaires. 

    Cela relève davantage de l'analyse quantitative, avec l'utilisation de cartes de chaleur et le calcul du pourcentage de temps passé dans certaines zones, par exemple. Cependant, cela devient plus avancé.

    Dans la plupart des cas, je réalise des études qualitatives en utilisant l'eye tracking, tout comme je mène des analyses comportementales. L'utilisateur est placé devant une page web avec sa souris et explore de gauche à droite, tout comme moi je le fais avec l'eye tracking.

    Ce que je dis sur l’eye-tracking n’est pas vrai pour toute la biométrie, d’ailleurs en ce qui concerne l'activité cardiaque et l'électrodermale, il s'agit d'autres outils utilisés pour d'autres raisons, principalement pour mesurer l'état cognitif. Honnêtement, aujourd'hui, nous n'avons pas encore bien compris comment les utiliser efficacement. C'est encore un domaine complexe qui nécessite des recherches et développements supplémentaires. 

    En revanche, l'eye tracking est une mesure directe et fiable. Vous obtenez le point central du regard de l'utilisateur, sans perte de données, même si l'utilisateur porte des lunettes. Vous pouvez même utiliser des lunettes spéciales, telles que les Tobi Glasses, qui sont parfaitement adaptées aux commutateurs et aux jeux mobiles, offrant une précision suffisante pour l'ergonomie cognitive. 

    En gros, l'eye tracking est fiable, à condition de rester dans une certaine plage de précision et de ne pas s'intéresser à des objets visuels trop petits.

    L'avantage de l'eye tracking réside dans le fait que c’est une mesure directe du point central du regard de l'utilisateur, contrairement à l'activité cardiaque, électrodermale ou EEG, qui sont des mesures indirectes. 

    Par exemple, dans l'activité électrodermale, nous observons les réactions physiologiques qui sont elles-mêmes influencées par des états cognitifs. Il existe de nombreuses cascades entre ces mesures et les états cognitifs eux-mêmes, ce qui entraîne une grande quantité de bruit dans les données. 

    La fiabilité de la mesure pose donc problème et vient la question : “qu'est-ce que je mesure réellement dans l'activité électrodermale ? “

    De plus, ces mesures sont très sensibles aux mouvements, donc si l'utilisateur effectue des mouvements avec les mains ou si des artefacts de mouvement sont présents, cela génère beaucoup de bruit et entraîne des pertes de données.

    En conclusion, bien que les mesures physiologiques comme l'activité cardiaque et l'électrodermale offrent une donnée continue et quantifiable, elles sont souvent bruitées, ce qui rend leur interprétation et leur transformation en retours exploitables difficiles. C'est un défi que je n'ai pas entièrement réussi à relever avec l'activité cardiaque et l'électrodermale, mais j'espère que d'autres personnes y parviendront à l'avenir.

    De plus, pour avoir de l’impact avec des données de user test, il est important de prendre en compte le contexte dans lequel se trouvent les designers, leur background et leur façon de réfléchir, et malheureusement ils ne sont pas toujours enclin à correctement rationaliser une expérience d’un point de vue émotionnelle qui permettrait à la biométrie d’apporter un regard intéressant sur les intentions de design.

    En tant que chercheur, il est essentiel de réfléchir à la manière de communiquer ces informations et de s'assurer qu'elles ne tombent pas dans l'oreille d'un sourd. Lorsque vous parlez d'émotions positives, il est possible que ce soit la première fois que l'équipe aborde la question des émotions dans son projet, ce qui peut susciter des réactions de surprise : 

    "Ah bon ? Des émotions ? Comment ça, des émotions ?"

    Cela soulève une fois de plus le défi de la recherche utilisateur. Le niveau de maturité de l'équipe de conception et de rationalisation conditionne jusqu'où votre recherche peut aller et à quel point elle peut être prise en compte dans le processus de conception. 

    Il est essentiel d'établir un dialogue ouvert et de sensibiliser les concepteurs à l'importance des émotions dans l'expérience utilisateur afin de permettre une intégration plus approfondie de ces éléments dans leurs projets.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment tester la monétisation d’un jeu / produit avant son lancement

    La monétisation est un aspect crucial, souvent négligé, qui nécessite de se poser la question fondamentale de la valeur ajoutée pour l'utilisateur. 

  • Est-ce que ce que vous prévoyez de vendre apportera une réelle plus-value à son expérience ? 
  • La valeur ajoutée peut revêtir différents aspects, tels que l'utilité, le social, l'émotionnel, etc. 

    Il est donc essentiel de prendre en compte ces différents aspects.

    Lorsque le design est défaillant et que l'expérience monétisée ne s'harmonise pas du tout avec l'expérience centrale existante, cela pose problème. 

    Comment tester cela ?

  • C'est un processus relativement simple. Vous mettez votre design entre les mains des utilisateurs et vous les faites tester votre produit, votre service, votre service client, en bref, tout ce que vous souhaitez proposer. 
  • Vous évaluez ensuite dans vos boucles de design si l'élément monétisé apporte une valeur en termes d'expérience utilisateur par rapport à votre offre de base.

    L'objectif de la recherche était de déterminer si les éléments monétisés s'intégraient dans le cadre suivant : 

  • étaient-ils attrayants
  • bien réalisés ?
  • adaptés au design ? 
  • En termes de valeur étaient-ils équitables par rapport au marché ? Il est très important de tenir compte des benchmarks du marché car c’est comme cela que les utilisateurs réfléchissent.

    Du côté méthodologique, nous avons d'abord pris en compte les attentes des utilisateurs et évalué la situation sur le marché. 

    Ensuite, nous avons procédé à des tests d'expérience utilisateur, une étape cruciale. Nous avons simulé, fait tester et recueilli les impressions des utilisateurs pour qu'ils puissent se projeter dans l'expérience principale. 

    Si les utilisateurs.trices n’arrivaient pas à utiliser la feature monétisée, cela signifiait que cela n'avait aucune valeur. Nous avons ensuite mené des entretiens plus précis sur certaines boucles d'expérience en fonction des éléments testés. Nous avons également organisé des groupes de discussion pour évaluer la perception sociale des joueurs.

    Les groupes de discussion étaient particulièrement utiles pour anticiper les réactions sociales potentielles ou les retours négatifs des joueurs (éviter un backclash). Ces groupes recréent des atmosphères sociales qui permettent de détecter les potentielles sources de problèmes ou, inversement, les éléments positifs qui pourraient se développer grâce à l'émulation sociale. Nous avons mené plusieurs entretiens en groupe, entre trois et cinq, pour observer les dynamiques et les réactions des participants.

    En conclusion, il est important de comprendre que les résultats que nous livrons mettent en liumière des risques-opportunités, et non sur des conversions ou des estimations de ventes. 

    Voici le framework , il s'agit d'identifier : 

  • les risques et les opportunités
  • De situer les éléments monétisés par rapport à l'expérience principale
  • De déterminer leur importance, leur valeur ajoutée et leur pertinence. 

    Nous pouvons ensuite hiérarchiser ces éléments pour aider les monetisation designers à fixer des prix. 

    Les entretiens sont essentiels pour comprendre le pourquoi, les intentions des concepteurs de monétisation. Ils permettent également de challenger ces intentions.

    Pour illustrer ce point, je me souviens d'un cas concret où une équipe envisageait de vendre des couteaux en jeu. 

    Cependant, après des tests approfondis, nous avons réalisé que le design du jeu ne favorisait pas les combats au corps à corps, qui étaient les seuls moments où les joueurs et joueuses pouvaient voir les couteaux. 

    Par conséquent, cette proposition de valeur ne fonctionnait pas, malgré la qualité des animations réalisées. Cette histoire met en évidence l'importance du rôle des chercheurs utilisateurs pour réaligner les idées avec l'expérience centrale du jeu.

    Pour conclure, il est primordial d'inclure des compétences marketing pour compléter le point de vue utilitaire souvent privilégié par les UX researchers. L'inclusion de ces compétences dans la recherche permet de compenser les biais propres aux chercheurs et d'identifier les opportunités de création de valeur pour l'utilisateur.

  • Nicolas MATHIEU · UX-R Manager · il y a 8 mois
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX de tests utilisateurs avec des personnes en conditions de handicaps.
    Quand recruter et dans quel objectif Le recrutement de personnes en situation de handicap peut souvent être plus long et complexe que celui effectué pour des tests d'utilisabilité, pour des raisons évidentes. C'est un projet à long terme. Il est essentiel de définir clairement les objectifs et le processus de sélection.  Avant de se lancer dans le recrutement, il est fortement recommandé de procéder à une série d'audits complets de la base de code, de l'application ou de l'interface. Créez une équipe dédiée au projet "Accessibilité" qui comprendra au moins un designer et un développeur web afin de couvrir les exigences techniques. Testez votre code : assurez-vous de l'avoir testé avec des outils d'audit librement accessibles tels que : Wave Web Accessibility Tool Accessibility Developer Tools Lighthouse Axe Contrast Checker pour tester l'accessibilité des couleurs et gérer les contraintes liées au contraste Colour Contrast Analyser Définissez des objectifs clairs et des directives d'accessibilité pour votre application ou produit. Identifiez vos utilisateurs et leurs besoins spécifiques en termes d'accessibilité. Établissez les directives qui doivent être mises en place à l'échelle du produit et déterminez quand elles doivent être appliquées (établissez un plan avec vos développeurs, Product Owners, Project Managers, Business Owners, etc.)
  • Dans notre cas, il s'agissait de tester un flow complet: onboarding (sign-up form) et product discovery avec des utilisateurs de screen readers. Notre hypothèse était que l'on découvrirait des problèmes mais en réalité, le scree-reader ne permettait carrément pas la navigation du formulaire d'onboarding. Les directives étaient: permettre aux utilisateurs de screen readers de créer un compte et de naviguer la page produit.
  • Je rajoute un point que je n'avais peut-être pas abordé: on oublie souvent qu'il n'y a pas qu'un seul type d'outils utilisé par les personnes handicapées: les screen readers ne sont qu'un infime partie de ces outils, la compagne de mon tester par exemple, utilisait les screen magnifiers. C'est ainsi que j'ai découvert une toute autre dimension. Mais ce serait peut-être un article pour une autre fois :) Réfléchissez à la manière d'intégrer et de respecter ces directives : cela peut nécessiter une révision de la base de code ou du design system. Effectuez un audit d'accessibilité interne (voire plusieurs). Adoptez une approche agile : implémentez, testez, révisez, re-testez… Établissez des priorités : élaborez un plan de recherche pour déterminer quels objectifs d'accessibilité doivent être atteints en priorité. Définissez des critères pour évaluer si ces objectifs sont atteints.
  • c'est très basique à ce stade, on s'attendait à des améliorations à faire, mais en fait le code n'était pas accessible. Donc success/failure rate, time on task, perceived difficulty, satisfaction Avant de commencer le recrutement : Assurez-vous d'avoir une équipe projet en place. Établissez des objectifs clairs. Effectuez un ou plusieurs audits internes (ou faites appel à des experts). Élaborez un plan de recherche (quels tests effectuer, quand, avec qui). Mettez en place un processus de sélection pour le recrutement. Dans le cadre d'un test d'accessibilité, l'objectif est de s'assurer que les personnes ayant recours à des supports ou aides (à l'écran ou externes, tels que des lecteurs d'écran, des outils de contraste, etc.) seront en mesure de naviguer sur votre site. Posez-vous les questions suivantes : Quelles actions doivent pouvoir être réalisées sur ce site ou cette interface (par exemple, les flux critiques tels que la connexion ou le processus de commande) ? Quels sont les différents types de handicaps et quels sont leurs impacts sur nos utilisateurs ? Consultez https://theaccidentalally.com/toolkit/ pour plus d'informations. Quels outils ou supports seront utilisés par quels types d'utilisateurs ? Il arrive souvent que, en voulant "inclure" certains groupes d'utilisateurs soumis à des mesures d'accessibilité, d'autres soient exclus. Par exemple, une vidéo peut être un outil formidable pour une personne dyslexique ou ayant une maîtrise limitée de la langue, mais elle sera totalement inaccessible pour une personne sourde. L'ajout d'une transcription ou de sous-titres peut résoudre ce problème facilement. Ne vous concentrez pas uniquement sur les handicaps les plus "visibles" : de nombreux handicaps ne sont pas visibles, tels que la dyslexie, les troubles anxieux, l'autisme ou les troubles cognitifs, etc. Dans mon entreprise par exemple, notre client base est plus âgée. Donc il coule de source de se référer aux déficiences cognitives de chacun à partir de 60 ans (visuelles, auditives) mais il est aussi intéressant de comprendre le background culturel de nos utilisateurs: si une personne dyslexique peut comprendre un texte complexe (un contrat par exemple), alors une personne dont la langue maternelle n'est pas celle du groupe cible local sera plus susceptible de consommer ce contenu avec aisance. Où recruter des personnes pour un test d'accessibilité : Faites appel à des agences spécialisées.(on en a listé certaines ici) Collaborez avec des associations de personnes en situation de handicap. Consultez des experts du design inclusif (une recherche sur LinkedIn peut être utile). Envisagez également un recrutement en mode guérilla, pourquoi pas ? Note : Les personnes en situation de handicap sont généralement ouvertes à s'exprimer sur leurs besoins, mais il est important de ne pas les réduire à leur handicap. De même, il faut éviter de se concentrer sur un handicap spécifique : une personne aveugle peut privilégier certains outils ou aides, tandis qu'une personne sourde aura besoin d'un autre type de support de navigation. La qualité de votre recherche réside dans la diversité de votre panel.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • La logistique et le matériel, le pain point de tout UX researcher.

    La logistique et le matériel sont souvent des éléments sous-estimés dans l’organisation d’une session de recherche, en particulier lorsque l’on débute. Et c’est d’ailleurs un des feedbacks que j’ai le plus de la part d’étudiants ou débutants, après l’organisation d’une première séance de tests.

    Le pré-test du matériel est essentiel, surtout si on utilise du matériel pour la séance (prototype, eye-tracking, caméras…). Il y a une fois où j'ai mené des tests utilisateurs et on n’avait pas vérifié le matériel en amont, la caméra ne fonctionnait pas et on n'a pas pu filmer la matinée de tests.

    Une situation comme ça fait perdre du temps de test, sans compter le stress que ça amène le jour J !

    Il y a aussi toutes ces fois où l’on n’a pas assez testé le prototype, ou alors on a rajouté des choses en dernière minute sans tester. Un prototype ou un bout de prototype cassé, et tu peux perdre 5 ou 10 minutes de ton test, ce qui est énorme sur une session d’1h au final.

    Une autre erreur réalisée était cette fois sur la partie logistique de la session de recherche. Pour cette étude, c’est mon client qui s’était occupé d’organiser les rendez-vous, par soucis de facilité car nos utilisateurs étaient des employés de l’entreprise. 

    Nous ne l’avions pas briefé sur le comment organiser des sessions de recherche, et notamment qu’il fallait prévoir un temps de pause entre chaque session. Et le quart d’heure minimum entre deux interviews ou deux sessions de tests, il est nécessaire !

    Nous nous sommes donc retrouvés avec 4h d’interviews programmées à la suite, sans coupure, et chaque rendez-vous était dans une salle et à un étage différent du bâtiment. Nous avons couru entre chaque séance, et ce n’est pas du tout confortable, ni pour nous, ni pour la personne interviewée. 

    Sans temps de battement entre deux rendez-vous, tu n’as pas de marge de manœuvre possible pour gérer les imprévus, les retards, t’installer pour accueillir la personne d’après, et switcher mentalement d’un participant à un autre pour commencer ta session de research “à neuf”. 

    Je pense qu'on ne se rend pas assez compte quand on n’est pas user researcher ou quand on n’a jamais fait de recherche, à quel point la logistique est importante et chronophage.

    C’est quelque chose également que je souligne beaucoup quand on parle à des débutants, de ne pas négliger cet aspect qui prend quand même assez de temps de préparation parce que mener des séances de recherche c’est un exercice qui prend beaucoup d’énergie, qui demande de la concentration et qui peut être stressant, surtout quand on démarre. 

    Si on peut éviter du stress logistique en plus du stress de mener la recherche, on gagne en sérénité. Donc vraiment préparer et anticiper au maximum, et faire des checklists c’est le secret de la logistique en user research.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Réaliser des test utilisateurs avec des non-voyants.

    Nous avons réalisé des tests ergonomiques avec des non-voyants dans le cadre d’une évaluation d’accessibilité pour le nouveau site des Nations-Unies à Genève.

    C’était la première fois que j’entreprenais des tests avec des non-voyants et c’était fascinant comme expérience. 

    Dans le passé j'avais regardé des clips où on voyait comment les gens utilisent des logiciels spécialisés, comme JARS, mais je n’avais jamais observé en “live” comment ça se présentait. 

    Voici quelques observations :

    1.Scanner les pages avec les Headers HTML

    Lors du test j’étais vraiment surprise de voir la rapidité à laquelle ils naviguaient. Ils utilisent l’HTML, en général les H2, pour scanner les pages à une vitesse hallucinante. 

    Cela nous apprend que c'est très important de bien coder les pages et de faire vraiment attention aux titres qui ont un vrai sens et sont assez parlants. 

    2.Attention aux ALT tags

    Un autre élément intéressant est l’idée reçue que les ALT tags doivent être renseignés à tout prix. C'est faux. 

    Cela dépend du contexte.

    Si c'est une image purement décorative, il ne faut pas mettre un ALT tag. Dans ce cas, c'est mieux de le cacher ou d'avoir les guillemets vides afin d’ignorer le tag. 

    Par contre, on risque de créer de la confusion si on l’affiche. Par exemple, s'il y a une petite icône décorative suivi d’un lien du même nom, la personne qui va écouter ne va rien comprendre. Au fait, les utilisateurs non-voyants sont très attentifs aux détails, car ils ne veulent pas louper des informations importantes.

    Par contre, si on utilise des images ou des icônes pour la navigation, il faut évidemment avoir un ALT tag car c'est essentiel, sinon ils ne peuvent pas naviguer. 

    C'est un des problèmes qu'on avait vus lors des tests car le footer contenait des liens vers les réseaux sociaux mais sans ALT tags sur les icônes. A corriger donc !

    Dans le monde du design et de la technologie, on a souvent des idées préconçues sur nos raisonnements pour bien faire. En voulant trop bien faire, on peut créer des problèmes.

    Il faut trouver le juste milieu et connaître les “best practices”.

    3 . Attention à l’utilisation des balises ARIA

    Il y a des balises spécifiquement conçues pour les lecteurs d’écrans, ARIA. Ils permettent par exemple de mettre en évidence des sections sur une page, comme le menu principal. 

    À l'occasion des tests, une personne ne comprenait pas ce que voulait dire “Breadcrumb” (le fil d’ariane) parce que finalement c'est un terme technique. 

    Il y a donc beaucoup de choses à prendre en considération.

    Pour finir, un petit bonus :  Est-ce que l’ouverture d’un nouvel onglet pour ouvrir un pdf nuit à l’accessibilité ? Suite à un débat que j’ai eu avec un développeur, j'ai voulu tester ce point en particulier et j’ai découvert qu’au contraire, cela permettait de naviguer plus facilement, pour autant que le PDF soit accessible !

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le protocole de recherche utilisateur sur des dispositifs médicaux.
    Dans le domaine de la santé, les tests jouent un rôle primordial dans la validation du dispositif.  En effet, avant la validation de quelconque produit médical, on a deux grands types d’évaluations : L’évaluation formative qui permet de savoir quoi faire pour améliorer le produit, et poser des évolutions sur un prototype. L’évaluation statistique: C’est la partie qui repose sur la validation. Étude de l'utilisation du produit vis -à -vis des risques d’usage. C’est cette deuxième partie que les clients ont tendance à être surpris quand on aborde le sujet.  Ils pensent savoir ce qu’un test utilisateur comprend alors que ce n'est pas si simple que ça, ils restent bloqués à l’évaluation marketing jusqu’à ce qu’ils viennent observer un test derrière la glace en tant qu’observateur.  Ils sont très étonnés qu’on mette les utilisateurs en situation, qu’on ne les aide pas et qu’on ait des critères de notations sur chaque consigne du test. (et les risques au niveau du protocole) Eux dans leur tête pensent qu’on va demander aux utilisateurs: “ Alors, vous en pensez quoi ? “ Il faut absolument s’assurer qu’on construit les protocoles et des consignes dans des situations réalistes de test d’une action ou d’une fonctionnalité qui est reliée à un risque et que tu vas pouvoir évaluer ce risque.  Au début de l’engagement, même si le client nous ramène une liste préliminaire des risques, nous gardons toujours 2 jours pour une relecture des risques en faisant notre propre analyse, car par expérience, je sais que cette dernière n’est pas complète.  L’avantage, c'est qu'après 7 ans d’activité, on a fait tous les types de produits, donc on a une nomenclature de risques assez complète, ça nous permet de voir rapidement s'il manque des risques ou pas. Nous sommes capables d’anticiper les manquements. Car si l’organisme de notation produit ne retrouve pas la liste en question, il dira au client: “ Ce n’est pas normal de ne pas avoir ces risques”  Puis mettra une non-conformité aux exigences requises. (donc produit bloqué) Souvent le client traine les pieds pour faire cette relecture critique de l'analyse des risques d'usage ou de la rédaction de cette analyse des risques. Mais souvent après nous remercie après car on met en valeur des choses qu’il n’avait pas mis en avant, ou on le prévient de problèmes, car il a oublié des risques importants à prendre en compte dans la conception ou des choses dans son cycle de vie produit. Tout ce travail en amont nous permet de baser notre protocole de test sur les risques, en définissant les scénarios que nous allons évaluer, et les autres que nous n’évaluons pas.  (tout est justifié)
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Travailler sur des projets de santé (normatifs)
    Quand on intervient sur un produit de santé, il ne faut pas oublier que c’est un dispositif médical, ou un médicament etc. Mais l'importance, c'est de savoir qu'il y a souvent une réglementation associée. J’ai vu plusieurs cas où les prestataires arrivent et oublient complètement l’objectif du produit.  Ils se concentrent sur l’aspect créatif du job, ce qui est tout à fait normal, mais dans le domaine médical, la créativité vient en second lieu, après la question de gestion des risques. En priorisant la créativité ça devient un travail de surface, et la norme n’existe pas pour rien.  Si ton interface est trop complexe ou pas optimale, les problèmes d’usages vont entraîner une perte de bénéfice du traitement ou des problèmes bien plus grave. Donc c’est embêtant, surtout lorsque tu imagines des cas comme la chimiothérapie. (dont les irradiés d’épinal) C’est l’erreur majeure que je vois en repassant derrière des prestataires qui ne sont pas dédiés à la santé.  Ce sont des situations compliquées à deux niveaux : Au niveau du produit, toute une partie a été oubliée et rend l’utilisation du produit dangereuse et pas finalement pas si user friendly car non adapté aux différentes catégories d’utilisateurs finaux (connaissance du monde de la santé). Puis pour le client, normativement ce n'est pas terrible. Même si le boulot a été fait d’un point de vue expérience utilisateur, le lien avec les risques d’usage n’a pas du tout été tracé, et pas fait selon les règles des auditeurs. Alors ça induit un risque business fort, car les auditeurs ne transigent pas. C’est du travail en plus pour le client qui se fera bloquer, et ils devront refaire des choses. Dans ce genre de cas le client arrive en disant: “Si on a fait appel à vous ce n’est pas pour tout refaire derrière”. La norme, ce sont des obligations légales (une dizaine, qu’il faut connaître) qui faut retrouver, puis des recommandations. En fait, il faut rendre un dossier technique concernant la maitrise des risques reliée au dispositif. Pour l'ergonomie et l'expérience utilisateur, c'est les risques d'usage mais il existe beaucoup de catégories de risques. Il faut les identifier et les évaluer lors de la conception du dispositif et continuer une fois sur le marché. Ce sont des exigences fortes pour lesquelles le fabricants est audité par des organismes notifiés et il risque le retrait de son dispositif du marché. Les tests utilisateurs en santé: ce sont des tests utilisateurs bien différents. Ce ne sont pas des tests utilisateurs où tu remontent ce qui marchent ou ne marche pas, mais des tests statistiques.  Tu as les tests formatifs au cours de la conception qui ressemblent à des tests utilisateurs classiques où l'on va identifier les irritants, les problèmes d'ergonomie, la satisfaction etc. et proposer des recommandations d'évolution.  Par contre, ce qui est nouveau dans le monde de la santé c'est l'étape de validation (évaluation sommative) qui est également sous forme de test utilisateur.  La différence c'est que les consignes de test permettent de mettre en situation le participants pour qu'il rencontre le risque (ou pas) de manière simulé.  Dans ce cas, on rend des résultats centrés risque sans recommandation. On dit juste que pour tel ou tel risque, on à 80%,90%,100% de réussite. C'est à dire autant de personne qui n'ont pas commis l'erreur et rencontré le risque. Tu mets les utilisateurs en situations de risques, et tu observes les situations d’échecs à différents niveaux. En fonction de ces échecs, tu fais des statistiques d’usages, tu expliques le comportement et tu conclus sur l’utilisation de ton produit vis-à-vis des risques d’usages que tu as identifié dans le cadrage.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Faire tester un produit de santé physique avec une actrice.
    En début de carrière et pendant mon doctorat, je travaillais au CICIT, où je participais à la certification européenne de dispositifs médicaux (DM), cad que les fabricants de produits de santé devaient nous présenter un dossier et un produit en prouvant qu’ils avaient bien suivi le processus de conception réglementaire de la norme ISO 9241-210. On testait également le produit / le service à travers une série de tests ; on parle d’évaluations formatives, puis sommatives.  Je me rappelle un projet en particulier où un industriel nous avait contacté pour le dossier de certification CE d’un stylo auto-injecteur. Concrètement, ce type de DM permet à une personne d’être autonome dans l’injection d’une substance (e.g. les personnes diabétiques, allergiques, etc.) ; dans ce cas, on testait un stylo avec de l’adrénaline pour la prise en charge de personnes allergiques (aux piqûres d’abeille par exemple), et éviter qu’ils fassent choc anaphylactique.  L’objectif du stylo est que la personne souffrante ou une personne tierce puisse injecter la solution dès qu’elle ressent les effets de l’allergie, et ainsi éviter des séquelles dangereuses voire la mort.  D’après l’industriel, le stylo est supposé être si simple à utiliser que toute personne puisse réagir si le patient n’est plus capable de s’auto-injecter. Pour autant, on ne peut pas s’arrêter à ce que nous disent et pensent savoir les industriels de leurs propres produits, on devait tester le produit quoi qu’il en soi. Nous avons décidé de partir s ur un cas proche de la réalité en embauchant une actrice qui devait faire semblant d’avoir un choc anaphylactique dans une salle d’attente après une allergie alimentaire, sans que les personnes du test ne soient au courant. Le stylo était devant eux et en s’effondrant au sol, l’actrice montrait son stylo et demandait aux gens de l’aide pour qu'ils le lui injectent.  Cette situation nous a permis d’observer des réactions réelles et fiables, et des résultats franchement intéressants (et alarmants pour l’industriel) : la plupart des testeurs mettait plus de trois minutes à déballer le produit, lire la notice et injecter le produit. Sachant que la piqûre doit être faite en moins d’une minute après la réaction, on en était loin…. On a aussi remarqué qu’un tiers des participants se trompaient de sens en tenant le stylo, et s ’injectaient (il n’y avait pas d’aiguille pour le test !) le produit dans le pouce, ce qui est extrêmement dangereux car ça peut créer une crise cardiaque ou une gangrène du doigt. On aurait eu potentiellement deux morts pour un tiers des tests ! Au final, ce produit “révolutionnaire” (selon le fabricant) aurait créé plus de mal que de bien. Heureusement que cette procédure de marquage CE existe ! Je tiens à préciser que naturellement il n’y avait pas réellement de produit, ni d’aiguille, mais ceci ne faussait pas nos observations.  Toutes ces observations et interprétations issues de ces tests nous ont permis d’améliorer la conception du produit final et de confronter la réalité à la perception client qui pensait que son produit était révolutionnaire.  Lors de test d’un produit pareil, une panoplie de choix s’offre à nous, on s’est vraiment posé pleins de questions pas faciles à répondre au premier abord :  S’il fallait simuler le choc ?  Le faire en labo vs pas en labo D’utiliser un mannequin versus une vraie personne (ça a un coût)  Faut il prévenir les testeurs ou non ? (certains étaient un peu secoués après le test) Pour information, on l’a testé sur 8 personnes qui est la norme recommandée.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Une erreur de débutante lors d'un test utilisateur.
    Une erreur de débutante !  J'ai fait tester un prototype avec beaucoup de contenus type textes, le fameux Lorem ipsum, et je n'ai pas remarqué qu'une partie de ce faux texte était issu d’un scénario de film, c'était du second degré, de l'argot anglais et l’interprétation de ce texte pouvait être perçue comme choquante.  On est tellement plongé dans l'action quand on fait ce genre de prototype qu'on ne regarde plus forcément les détails. Heureusement qu'une testeuse s'en est rendue compte !  Néanmoins, ça a biaisé le test du parcours utilisateur car la participante s’est focalisée uniquement sur ce point et non sur le reste. Pour moi c'était vraiment une erreur qui n’aurait pas dû se produire ! La confiance du client en l'équipe produit dont je faisais partie a aussi été remise en cause malheureusement. C'était une erreur humaine, qui peut arriver, mais c'était ma responsabilité de vérifier la qualité du prototype. Le fait de vouloir sortir un peu du ‘Lorem ipsum’, qui n'est pas assez réel et qui ne permet pas de projeter suffisamment bien certains éléments du produit a été finalement une mauvaise idée.  Les conséquences de cette erreur ne sont pas négligeables car un comité éthique du côté du client a dû s'organiser pour évaluer mon client.  Après cette affaire, le client n'a pas eu de problème avec ça et il est vite passé à autre chose. Par la suite, j'ai fait un contrôle de tous les outils avec lesquels je travaillais pour être sûre qu'ils étaient bien conformes, qu'il n'y avait pas de problème.  Les sources d’images, tous contenus en général, l'éthique des fournisseurs d’assets, etc. tout ce qu'on utilise au quotidien, comme outils définissent aussi nos valeurs de collaboration. Je fais beaucoup plus attention à ça à présent. Par exemple, si je travaille avec un outil comme Adobe, je vais faire des recherches sur leurs réglementations, leurs codes, leurs valeurs.  Je teste un peu le service client, je cherche à savoir qui sont les employés, le niveau de sécurité, etc. Une chose que je ne faisais pas avant. Je m'intéresse un peu plus à ce qu'on ne voit pas.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Site-Seeing: A Visual Approach to Web Usability
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Cost-Justifying Usability: An Update for the Internet Age
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Moderating Usability Tests: Principles and Practices for Interacting
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Usability Testing Essentials: Ready, Set...Test!
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Livre: Usability Testing of Medical Devices
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Usability Inspection Methods
    • merci! Utile
    • Pas utile
    • Pas sûr
  • A Practical Guide to Usability Testing
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Livre: Usability Engineering de Jakob Nielsen
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Usable Usability: Simple Steps for Making Stuff Better
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Don't make me think de Steve krug
    • merci! Utile
    • Pas utile
    • Pas sûr
  • L'onboarding continu de Mailchimp
    Un superbe cas qui est en plus extrêmement bien illustré et en plus qui parle d'un problème tellement courant pour n'importe quel autre produit. Le fait que les utilisateurs na savent pas qu'il existent d'autres features. https://sliu0915.github.io/continuous_onboarding
    • merci! Utile
    • Pas utile
    • Pas sûr
  • L'UX chez RadioFrance avec David Duhamel, Lead UX Designer
    Lien de l'épisode Hello Hello 👋   C'est reparti pour un nouvel avatar d'Expériences Digitales ! Le 24ème épisode que nous menons cette fois avec David Duhamel, Lead UX Designer chez Radio France pour parler de la place de l'UX chez Radio France Lead UX chez Radio France, David a pour mission de proposer la meilleure expérience aux auditeurs de France Inter, France Culture, France Bleu, France Musique, Mouv, Fip et franceinfo sur tous les usages / devices. 
    Dans ce podcast :  C'est une belle conversation qui vous attend autour du :  - Du rôle de l'UX chez Radio France - De la vision de l'UX de David, de ses sources d'inspirations - De l'analyse des parcours chez Radio France - Des manières de tester avant mise en prod : AB test / tests utilisateurs / étude quanti, quali - De l'éco-design, de l'accessibilité - Des KPIS, de le veille, des sources d'inspirations  - Des innovations chez Radio France : VR, Metavers, Chatbot
    Belle écoute et n'hésitez pas à partager l'épisode sur vos réseaux 😘 
    "Expériences Digitales" : c'est le podcast de Wexperience qui a pour but de partager avec vous des histoires, des bonnes pratiques et des insights autour de l’expérience client digitale. Pour découvrir nos épisodes vidéo c'est ici.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les tests utilisateurs via l'intelligence artificielle avec Maximilien Joannides, CEO chez Odaptos
    Lien de l'épisode Bonjour Bonjour !  Dans ce 18ème épisode d'Expériences Digitales, nous accueillons Maximilien Joannides, fondateur de Odaptos, une startup montpelliéraine qui a pour ambition de révolutionner, ou tout du moins, de mettre un coup de fouet, à la manière de mener les tests utilisateurs sur des sites webs ou sur des application mobiles. Titulaire d’une licence en Infographie ainsi que d’un Master en Design et communication visuelle de la Sorbonne, Maximilien est spécialiste des métiers du multimédia interactif ainsi que des processus de Data Driven et de Design Thinking. Désormais, président de la société Odaptos, Maximilien développe avec Felipe Restrepo une Web-App permettant d’aider les UX designer dans leur travail à l’aide de l’intelligence artificielle.
    Au programme de cet épisode, nous répondrons aux questions suivantes : 
    C'est quoi Odaptos ? Et comment est venue l’idée ? Pourquoi un tel logiciel ?  Qu’est-ce que ça apporte en plus aux tests utilisateurs ? Comment ça marche ? Est-ce que ça permet vraiment d’aller plus vite dans l’analyse d’une interface ? Est-ce que ça s’adresse uniquement à des experts UX ou d’autres types de profil peuvent-ils s’en servir et en retirer de précieux insights ? Est-ce qu'Odaptos pourra améliorer l’expérience utilisateur en France ? Réponse dans ce nouvel épisode !  "Expériences Digitales" : c'est le podcast de Wexperience qui a pour but de partager avec vous des histoires, des bonnes pratiques et des insights autour de l’expérience client digitale. Pour découvrir nos épisodes vidéo c'est ici.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les tests utilisateurs à l'international avec Damien Canac, business manager chez Saint-Gobain
    Lien de l'épisode ⚡️ Bonjour et bienvenu dans le 11ème épisode d'«Expériences digitales» ! « Expériences digitales » a pour but de partager avec vous des histoires, des bonnes pratiques et des insights autour de l’expérience client digitale. Dans ce nouvel épisode mené avec Damien Canac , business manager chez Omniseal Saint Gobain nous abordons le sujet des tests utilisateurs aux 4 coins du globe ainsi que la toute nouvelle refonte du site de la marque !
    Damien Canac rejoint le groupe Saint-Gobain en 2002 au sein de l’activité verrière dans laquelle il exerce des fonctions commerciales et marketing. Durant son expatriation aux Etats-Unis, il intègre une des business units de l’activité Saint-Gobain Performance Plastics puis rentre en France. En 2017, il rejoint Omniseal Solutions en tant que Business Manager, poste qu’il occupe actuellement. Au sein de l’équipe de management, il contribue au développement stratégique de cette activité qui compte 14 usines dans le monde. A ce titre, il est à l’initiative de la refonte de l’architecture de marque de l’activité et de son site internet. 
    Comment conduire une refonte quand vos prestataires sont dans plusieurs pays ? Comment collaborer avec vos utilisateurs lorsqu'ils sont aux 4 coins de la planète ? On en parle tout de suite dans Expériences Digitales épisode 11 ! 
    Belle écoute 😘 !
    En savoir plus sur "Expériences Digitales" :
    C'est le podcast de Wexperience qui a pour but de partager avec vous des histoires, des bonnes pratiques et des insights autour de l’expérience client digitale. Pour découvrir nos épisodes épisodes vidéo c'est par ici 👈
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Celia Hodent, Game UX Consultant - "L'UX est au service des créatifs"
    Lien de l'épisode:https://soundcloud.com/agence-lunaweb/sld-16-celia-hodent-game-ux-consultant Dans cet épisode N°16 nous avons eu la chance de recevoir Celia Hodent, Game UX consultant et autrice des livres "Dans le cerveau du gamer" et "The Psychology of Video Games". D’Ubisoft à Epic Games ou elle aura beaucoup contribué au succès d’un jeu vidéo devenu phénomène de société, j’ai nommé Fortnite, Celia explore depuis 2008 l’univers de la psychologie cognitive et des neurosciences pour permettre aux créateurs de jeu de transmettre au plus proche leurs intentions créatives. Vous découvrirez dans cet épisode le parcours de Celia, sa posture de Game UX consultante au service des joueurs, ses méthodes pour mener des tests utilisateurs sur un jeu vidéo et ses conseils pour mieux dompter son cerveau dans la réalisation de ses objectifs. Transcription : www.lunaweb.fr/blog/podcast-celi…ame-ux-consultant — Générique : Julien Bellanger · julienbellanger.com
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment convaincre mon boss d’investir dans les tests utilisateurs ? 5 arguments pour le convaincre
    Accès au PDF sans donner votre email sur les 5 arguments chiffrés pour convaincre vos managers d'investir dans les tests - peu importe l'industrie. Ces arguments sont: #1 Les tests utilisateurs permettent de gagner de l’argent #2 Écouter les utilisateurs permet de gagner du temps #3 Écouter les utilisateurs permet de prendre les bonnes décisions #4 Le projet ne sera pas ralenti, les tests sont rapides à mettre en place #5 Vos concurrents le font
    Vous me direz rien de nouveau comme arguments, et ca vend la solution mais certains sont décrits d'une manière différente et expliqué avec des métaphores intéressantes. Allez, c'est cadeau: https://f.hubspotusercontent40.net/hubfs/2271091/Prospects/Livre%20blanc/Livre%20Blanc%20-%20Comment%20convaincre%20mon%20boss%20dinvestir%20dans%20les%20tests%20utilisateurs.pdf
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les tests d'utilisablité ne permettent pas de prédire le succès d'un produit sur le marché.
    Je viens de voir passer dans mon feed linkedin ce post qui fait écho à ce que vis régulièrement auprès des équipes produit. Il est partagé par une directrice de recherche qui mentionne bien. Les tests d'utilisabilité répondent à la question: Nos utilisateurs sont-ils capables d'utiliser ce produit ? Non à : Utiliseront-ils ce produit ? ( en vrai !) Comme il est d'adage de répéter, vous pouvez avoir un super produit utilisable, ergonomique etc mais qui ne répond pas de manière supérieure aux besoins de vos utilisateurs. (comparé aux options existantes) Notons aussi que pour répondre à ces questions, vous pouvez faire toute la recherche du monde mais c'est en lançant vraiment que vous observerez ce qu'il se passe. (D'où l'utilité de soft launch, beta fermée etc..) Avant de se lancer dans la construction et le développement, la phase d'UX stratégie est primordiale et permettra de placer le produit dans la bonne configuration.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Évaluer la lisibilité d'un texte pour s'assurer de la compréhension de vos textes par vos lecteurs
    Un outil idéal pour évaluer le niveau de langage de vos textes lors d'audit, de la création de contenu UX writing ou pour vos tests U. Enfin un outil d'accessibilité et de design inclusif pour s'assurer qu'on parle à tout le monde = avoir un score entre 120 et 149 pour être d'un niveau collège. Découvrir Scolarius Scolarius est un outil gratuit d’analyse de la lisibilité. Il analyse le niveau de difficulté d’un texte en fonction de la longueur des mots, des phrases et des paragraphes. Il s’agit d’un outil qui permet à l’utilisateur de savoir si le niveau de difficulté de son texte correspond au niveau de compréhension de la clientèle visée. Scolarius a été développé par Influence Communication. Pour l'instant, Scolarius est offert uniquement pour des textes en français. Une version anglaise sera disponible dès que l'algorithme aura été complété. Après l’avoir rédigé, nous avons soumis ce texte sur Scolarius. Le texte que vous lisez présentement a été soumis à Scolarius et il a obtenu 127 (collégial).
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Rassurer les utilisateurs qui se trompent
    Lors des tests, il arrive fréquemment que les utilisateurs expriment « Excusez-moi mais je ne vois pas, je ne trouve pas, je n’y arrive pas, etc ». Il faut leur faire comprendre que le problème ne vient absolument pas d’eux ni de leur manque éventuel de compétence qu’ils peuvent ressentir. Au contraire : ce type retour de leur part est très enrichissant pour vous et pour le projet ! 😇
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Template de NDA pour des tests utilisateurs en Anglais
    Glané sur le site de Hellopingpong, il est tout de même écris par une avocate spécialisée dans le droit internet (UK) donc ça rassure. https://docs.google.com/document/d/1PCluUrmqQ8SuruiuAf0PVGuwA7mtx3wHW28x_-rbNHI/edit Néanmoins, une note est toujours nécessaire de faire revoir ce genre de template à votre contexte :) (surtout si vous êtes dans une grosse boite)
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les particularités de test utilisateurs sur l'accessibilité
    Super série d'articles de Régine Lambrecht sur le sujet. A retrouver sur Linkedin. https://www.linkedin.com/pulse/les-particularit%C3%A9s-dun-test-utilisateur-de-6-r%C3%A9gine-lambrecht/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Commentaires

    Groupes

    Hashtags