Comment nous avons introduit l’expérience utilisateur dans le pipeline de production d’Epic Games (GDC16)

How We Introduced UX to Epic Games' Production Pipeline (GDC16)

Voici les slides de la présentation de ma GDC 2016 avec Heather Chandler , Senior Producer sur Fortnite (Epic Games). Par conséquent, cette présentation concerne à la fois les perspectives UX (Celia) et Prod (Heather). Vous pouvez visionner la vidéo de cette présentation ici . De plus, si vous êtes intéressé par UX, allez voir notre Game UX Summit qui aura lieu le 12 mai 2016 (nous avons une programmation incroyable ! :)).

Prod02

UX Perpective (Celia) – L’influence de l’expérience utilisateur est croissante dans l’industrie du jeu. Les professionnels de l’UX – qui sont désormais bien établis dans le design industriel et de nombreuses entreprises technologiques – sont impatients de commencer à travailler avec l’industrie du jeu vidéo.

Prod Perspective (Heather) – Cependant, de nombreuses équipes voient l’expérience utilisateur comme une menace – des extraterrestres étranges envahissent et font des dégâts. Pourquoi en avions-nous encore besoin ? Nous nous débrouillions bien sans eux (ou du moins le pensions-nous). C’est un peu ce qui s’est passé chez Epic et le but de cette conférence est de fournir les deux perspectives, afin qu’il y ait une meilleure compréhension entre le développement et l’UX. Si nous nous comprenons, nous tirons le meilleur parti de la relation. La relation a connu un début difficile – l’équipe UX s’efforçait de faire beaucoup de tests au début du processus, afin de pouvoir acquérir des informations utiles ; mais l’équipe de production pensait qu’il y avait des défis plus importants à relever – ils savaient déjà qu’il y avait des problèmes UX, mais prévoyaient de les résoudre plus tard.

How Epic Games is structured

Avant de commencer, voici une explication rapide de la structure d’ Epic Games : nous avons plusieurs équipes de produits ainsi que des équipes de support/opération puisque Epic est auto-édité.

Il y a des concepteurs UX au sein des équipes de produits, mais l’équipe UX fournit une aide supplémentaire sur la conception UX si nécessaire et fournit les outils, la méthodologie et les connaissances nécessaires pour effectuer des analyses UX et des recherches UX. L’équipe UX soutient toutes ces équipes de produits.

Fortnite était l’équipe pionnière qui a commencé à travailler avec UX. Fortnite est actuellement en phase Alpha – c’est un jeu de construction d’action avec des mécanismes RPG.

Prod04

Commençons par discuter des idées fausses.

À bien des égards, UX est un hérisson qui veut embrasser l’équipe de développement et être aimé et utile. Du point de vue de l’équipe de développement, les pointes ne sont pas attrayantes et cette nouvelle créature est suspecte. Mais tout est une question de point de vue. Commençons par la perspective UX.

Definition of UX

Celia – Voici une définition rapide de l’expérience utilisateur : cela implique ce que c’est que pour l’utilisateur ciblé d’interagir avec un logiciel, y compris le degré d’engagement de l’expérience (cf. Isbister et Schaffer, 2008), par rapport aux intentions de conception. L’UX consiste principalement à s’assurer que la conception et les intentions commerciales sont celles qui sont finalement vécues par le public cible d’un produit, d’un système ou d’un service. Il utilise les connaissances en neurosciences et en psychologie et applique des méthodologies de recherche sur les utilisateurs de jeux (par exemple, des tests de jeu et des analyses) pour s’assurer que le jeu a une bonne convivialité et est immersif.

UX a ses racines dans les facteurs humains et l’interaction homme-machine (HCI). Il s’agit d’examiner comment un utilisateur comprend et interagit avec un système sans l’aide des humains qui l’ont conçu. Il s’agit donc d’aligner le modèle mental des développeurs sur celui du joueur (cf. Norman, 1988).

REMARQUE! Quand on dit UX ici, on parle de toute la démarche UX : UX design, UX testing (user research), stratégie UX, etc. Il y a beaucoup d’incompréhension sur ces différentes disciplines UX, mais c’est pour une autre discussion 😉

Groundhog Day of UX

Celia – Quand j’ai commencé dans l’industrie du divertissement il y a 10 ans, UX n’était pas encore vraiment une chose. Mon titre n’était pas « UX quelque chose ». La première fois que j’ai eu UX dans mon titre, c’était chez LucasArts, donc il y a seulement 4 ans environ. Et ce n’était même pas mon titre officiel. Chaque fois que je commence à travailler avec une nouvelle équipe, je suis confronté aux mêmes idées fausses sur l’UX que je dois d’abord démystifier. C’est comme mon jour de la marmotte de l’UX.

Voici mon top 5 :

Prod07

Heather – UX va entraver la créativité du designer et rendre le jeu TROP FACILE pour les joueurs ! Vous allez tuer des jeux comme Dark Souls.

Célia – On n’oserait jamais faire une chose pareille ! En réalité, le but principal des pratiques UX est d’offrir l’expérience que les designers ont voulue à leur public cible. Par conséquent, si votre public est composé de joueurs inconditionnels et que l’expérience que vous souhaitez pour eux souffre, les directives UX vous aideront absolument à atteindre votre objectif sadique.

Prod08

Heather – Tout cela n’est que du bon sens – nous n’avons pas besoin de tester l’UX, le joueur comprendra certainement ce qu’il est censé faire !

Celia – Il y a certainement du bon sens, bien que les problèmes soient toujours plus faciles à repérer après les faits (effet rétrospectif). Cependant, toutes les recommandations UX ne relèvent pas du bon sens. Le cerveau humain est rempli de biais perceptifs, cognitifs et sociaux qui affectent à la fois les développeurs et les joueurs. C’est pour une raison que les chercheurs de tous les domaines utilisent des protocoles très standardisés pour tester leurs hypothèses ; et c’est parce qu’il est très facile de manquer ou de mal interpréter ce qui se passe.

La perception est une construction du cerveau. UX vous aidera à comprendre plus rapidement et plus précisément quels sont les vrais problèmes.

Prod09

Heather – UX n’est qu’une autre opinion sur notre jeu, les opinions que vous fournissez ne sont ni plus ni moins significatives que quelqu’un du marketing.

Celia – Les développeurs de jeux doivent certainement faire face à de nombreuses opinions ; de l’équipe du jeu, de l’équipe marketing, de l’équipe de publication, de l’équipe de direction, etc. Vous pouvez donc percevoir les retours UX comme une autre opinion à laquelle vous devez faire face. Comme c’est ennuyeux! Cependant, les processus UX sont destinés à tester des hypothèses grâce à des recherches rigoureuses et à anticiper les problèmes grâce à des analyses. Là, en réalité, les experts UX ne donnent pas d’avis , nous fournissons une analyse basée sur leur connaissance du cerveau, l’expérience passée, et les données quand elles sont disponibles.

Prod10

Heather – Nous n’avons pas assez de temps pour faire de l’UX – nous devons créer le jeu proprement dit ! Notre argent est mieux dépensé ailleurs, dans l’art et la programmation.

Celia – C’est drôle que vous ne disiez pas ça à propos des tests d’assurance qualité. De toute évidence, vous investissez du temps et de l’argent pour vous assurer que le jeu sera livré sans bogues. Alors, comment l’expédition d’un jeu avec des problèmes d’expérience utilisateur peut-elle être moins problématique ? Si votre jeu est livré avec des problèmes UX critiques, cela affectera vos ventes et tout le monde sera triste : l’équipe de développement parce que le jeu n’atteint pas ce qu’ils espéraient, les dirigeants parce qu’il ne rapporte pas d’argent, les joueurs parce qu’ils sont frustré par le jeu… Le processus UX est un investissement : Ne vous demandez pas si vous pouvez vous permettre de penser à l’UX, demandez-vous si vous pouvez vous permettre de ne pas le faire .

Misconceptions About UX

Heather – D’accord, c’est un bon point. Alors, « UX le jeu » plus tard, quand NOUS SERONS prêts.

Celia – Tu sais ce qui va se passer avec cet état d’esprit ? L’équipe va itérer dans un cercle fermé et nous allons vous regarder de loin en sachant que nous aurions pu vous aider plus tôt dans le processus itératif. À un moment donné, nous ne pourrons plus nous en empêcher : nous allons renoncer à vous demander de commencer à tester et à collaborer. Habituellement, la réponse que nous recevons est que vous n’êtes pas prêt, que le jeu a l’air moche, qu’il est cassé, etc.

Le danger est que le jeu finisse par être testé et évalué trop tard , alors que seuls des correctifs rapides peuvent être apportés avant la sortie du jeu. Donc, je suis terriblement désolé, mais nous ne pouvons pas « UX cela » à un moment donné après que l’architecture et les décisions importantes concernant le jeu ont déjà été prises. Au fait, « UX » n’est même pas un verbe…

Heather – D’accord, d’accord, j’ai compris. Mais considérez mon point de vue… c’est ce à quoi je dois faire face.

Misconceptions About UX

Celia – Les développeurs ne comprennent pas vraiment toutes les subtilités de l’UX.

Heather – Même s’il n’a pas de doctorat en UX, un concepteur comprend que fournir au joueur un moyen simple d’interagir avec le jeu fait partie d’une bonne conception de jeu. L’équipe de développement peut ne pas vouloir écouter les commentaires UX parce que, eh bien, vous n’êtes pas des concepteurs. Cependant, la plupart du temps, l’équipe de développement est simplement occupée à tout mettre en place, puis elle libère de l’espace mental pour écouter les commentaires UX.

Prod13

Celia – L’équipe de développement ne veut pas travailler avec nous – vous pensez que nous sommes une nuisance !

Heather – Je ne dirais pas une nuisance… La plupart des équipes de développement sont heureuses d’utiliser des ressources qui, en fin de compte, amélioreront le jeu pour les joueurs. Si un processus est en place qui fonctionne bien pour les deux, l’équipe de développement est heureuse de travailler avec UX en tant que partenaire. Le vrai problème est que vous pouvez offrir des commentaires trop détaillés et non applicables à l’état d’avancement du processus de développement. Nous devons nous aligner sur les commentaires qui sont utiles à un moment donné du cycle de développement. De plus, si l’UX n’est pas quelque chose avec lequel l’équipe de développement a l’habitude de travailler, il faut du temps pour établir une relation de travail.

Prod14

Celia – L’équipe de développement donne toujours l’excuse qu’elle n’a pas le temps de faire des tests UX. Cela ne demande pas beaucoup de temps de votre part – nous pouvons gérer tous les tests et rapports !

Heather – J’admets qu’au final, un bon processus UX fait gagner du temps à l’équipe de développement. Mais au départ, l’ajout d’UX dans le processus nécessite plus de temps. Vous devez allouer des tests, examiner et suivre les commentaires, éduquer l’équipe sur les pratiques UX, etc. Il doit être intégré à l’horaire, sinon il sera ignoré. Il est important de noter que l’intégration de l’expérience utilisateur dans le processus de développement ne peut se faire du jour au lendemain et se contente de raccourcir le processus. Vous devez préparer l’équipe, obtenir l’adhésion et trouver des moyens de l’introduire progressivement. Le simple fait d’avoir des tests et de générer des rapports n’intègre pas réellement l’UX dans notre processus.

Prod15

Celia – La mise en œuvre des commentaires UX n’est pas si difficile ! C’est juste une question de priorité, non ?

Heather – Votre équipe peut fournir d’excellentes suggestions sur la façon d’apporter des améliorations au jeu. Ces conclusions et suggestions peuvent sembler simples à mettre en œuvre, mais en réalité, je dois traiter cela comme une autre forme de rétroaction dans le processus de développement et les comparer à toutes les autres priorités. Réécrire du texte ou changer les couleurs peut sembler facile, mais ils doivent encore être exécutés, complétés et testés. Des changements plus importants nécessitent l’implication de plus de personnes, plus de tests, plus d’itérations, etc. Les changements UX peuvent être un gros problème à mettre en œuvre, surtout si la planification est déjà terminée.

Prod16

Heather – En fin de compte, l’équipe UX est un autre intrant dont la production doit tenir compte. La clé est de déterminer quelles entrées auront le plus de valeur pour l’équipe de jeu à n’importe quel moment du processus. L’équipe de développement doit également comprendre comment hiérarchiser les commentaires UX par rapport aux éléments souhaités par les dirigeants et le marketing.

Étant donné que l’UX est basée sur des données, il est plus facile de déterminer quand un retour d’information est utile à mettre en œuvre. Et une fois qu’il est mis en œuvre, il peut être retesté pour voir s’il a eu l’impact souhaité. Il est donc logique que nous travaillions ensemble tout au long du processus de développement pour tirer le meilleur parti de la relation.

La chose la plus importante que votre équipe puisse faire est de gagner notre confiance, et vice versa.

Prod17

Heather – Maintenant que j’ai dit mon article et que j’ai représenté l’équipe de développement, Celia va discuter du changement qui s’est produit lorsqu’elle a commencé à construire des ponts avec eux. Elle a dû y faire face seule la première année, puisqu’elle ne m’avait pas comme partenaire dans le crime. Elle a beaucoup travaillé pour construire cette relation.

Celia – Eh bien, je dirais que vous devez d’abord surmonter ces idées fausses, et je dirais que la première étape doit être faite par les potes UX, parce que * nous * sommes les nouveaux partenaires, les extraterrestres. J’ai dû arrêter de diriger l’équipe sur les directives d’utilisabilité et arrêter de harceler chaque fois que des règles UX évidentes étaient violées pendant le développement.

Au lieu de cela, j’ai essayé « UX the UX »: j’ai écouté l’équipe (mon public), j’ai essayé de comprendre ce dont ils avaient besoin (l’expérience prévue pour mon public) et j’ai utilisé leur point de vue pour accomplir ce qui devait être fait. Cette partie décrit ce voyage.

Prod18

Celia – Les premiers tests d’utilisabilité et critiques que j’ai faits pour Fortnite (oui, j’étais en quelque sorte une équipe UX d’un seul) étaient considérés comme autoritaires alors que l’équipe savait déjà que les choses n’étaient pas prêtes et ne fonctionnaient pas bien. Lorsque je voulais juste lancer le bal et démarrer un pipeline, le processus pouvait être considéré comme une simple déclaration d’évidence et certains développeurs pensaient qu’ils devaient traiter avec moi en tant qu ‘ »autorité » qui rapporterait aux dirigeants ce qui n’allait pas. UX s’efforçait trop de mettre en place un processus avant de prouver sa valeur pour l’équipe de développement. Parce que j’étais trop zélé au départ, je voulais tout tester à tout moment pour prouver la valeur de l’UX. J’ai commencé à être ressenti comme la « police de l’utilisabilité ». Croyez-moi, vous ne voulez pas devenir trop ennuyeux…

Prod19

Celia – A cette époque, avec l’aide de quelques défenseurs de l’UX, j’ai regardé où en était le projet, posé des questions aux designers pour comprendre leurs intentions, et aux dirigeants pour comprendre le business plan. Ensuite, un test UX a été effectué ou une évaluation UX a été effectuée. UX a fourni un énorme rapport de tous les problèmes, juste pour avoir un battement de cœur, dans l’espoir de démarrer une conversation et d’obtenir les commentaires des concepteurs pour comprendre ce qui était par conception, ce qui était déjà en cours de résolution, quel était le nouveau problème UX pour eux, etc. Cependant, le rapport était ÉNORME.

Le problème est que le rapport a été envoyé par une équipe qu’ils ne connaissaient pas bien, et je n’ai jamais vraiment eu l’occasion de discuter avec les développeurs, à l’exception de quelques designers intéressés par l’UX. Donc, au final, l’équipe de développement n’était pas particulièrement excitée par tout cela, la connexion n’a pas été établie et je n’avais pas une image complète du plan de l’équipe de développement.

Prod20

Celia – J’ai donc fait équipe avec les designers qui s’intéressaient à l’UX, et au lieu de faire une grande revue de toute l’expérience, nous avons discuté de leurs principaux problèmes et défis. Ce fut le point de départ d’une relation UX-Dev plus adaptée. À cette époque, il n’y avait pas de concepteur UX dans l’équipe, je les ai donc aidés à relever certains défis de conception UX (comme faire des simulations sales pour les aider à communiquer leur vision aux dirigeants). Nous avons également commencé à tester des éléments plus petits (icônes, HUD, boucle centrale, etc.) avec des questions de conception très spécifiques afin que les concepteurs participent au processus UX.

L’image de gauche est mon illustration rapide et sale de la vision des concepteurs du metagame d’il y a 3 ans (mon art :p) à ce qu’est la HomeBase de Fortnite aujourd’hui. Je ne suis évidemment pas un concepteur UX, mais j’ai simplement utilisé les fonctionnalités de base de Powerpoint et rassemblé des éléments pour aider tout le monde à visualiser la direction du design.

Prod21

Celia – Quand Epic était prêt à construire un laboratoire UX (assez rapide, ce qui était génial), beaucoup de gens voulaient que nous diffusions les tests en streaming afin que les développeurs puissent les regarder depuis leur bureau.

J’ai refusé. Je voulais que la salle secrète UX devienne un endroit où non seulement nous pourrions être physiquement derrière les joueurs, mais aussi un endroit où nous pourrions plaisanter et échanger des idées. Regarder un test de jeu est alors devenu un engagement (pas quelque chose que les développeurs pouvaient faire en multitâche) et une expérience sociale (avec d’autres membres de l’équipe de développement et des membres de l’équipe UX).

Du coup, la chambre secrète est totalement insonorisée et dégage une ambiance cool : c’est devenu un endroit où l’on pouvait se côtoyer et même faire la fête (une fois par mois j’organise une fête dans l’ux lab – car pourquoi pas). C’est ainsi que les tests ux sont devenus un aspect amusant du processus. Sorte de. Oui, il est difficile de voir les joueurs ne pas obtenir le design souhaité, mais le faire dans un environnement décontracté et convivial le rend bien meilleur.

Bien sûr, vous ne pourrez peut-être pas construire un laboratoire aussi sophistiqué, mais il existe des moyens de le faire à moindre coût : juste une pièce où vous placez les participants aux tests de jeu et diffusez la capture dans une autre pièce. Le plus important est que les développeurs ne soient pas ceux qui effectuent les tests. Si vous ne pouvez pas embaucher un chercheur UX, essayez un stagiaire en psychologie expérimentale ou en facteurs humains pour mener vos études, car il est assez difficile d’éliminer les préjugés si vous le faites vous-même. Si vous ne pouvez pas demander à quelqu’un d’autre de le faire, assurez-vous de demander à une personne chargée de la recherche sur les utilisateurs de jeux des conseils sur la façon d’exécuter les tests. Ils sont là, sur LinkedIn et Twitter , désireux d’aider.

Prod22

Heather – J’ai commencé à travailler chez Epic pendant le quart de travail. J’ai compris la valeur de l’UX sur la base des jeux précédents sur lesquels j’avais travaillé et j’étais ravi qu’Epic ait un département UX complet ! Je voulais comprendre pourquoi l’équipe de développement n’était pas à l’aise avec UX et comprendre comment nous pourrions améliorer le processus. Lorsque le jeu était au début du développement, les développeurs ne voyaient pas la valeur des commentaires UX. L’équipe savait que le jeu était très difficile et ils expérimentaient diverses fonctionnalités. L’expérience utilisateur était considérée comme quelque chose à faire uniquement lorsque le concepteur avait quelque chose qu’il jugeait prêt à être testé, et cela était traité comme une autre forme de rétroaction.

Celia – Ils n’ont pas entièrement reconnu que les commentaires UX sont plus neutres et scientifiques (lorsqu’ils sont faits correctement). Les commentaires UX sont différents car les professionnels UX sont formés à la psychologie cognitive / expérimentale et aux facteurs humains pour comprendre les problèmes HCI et les résoudre.

Heather – L’équipe a également été submergée par la quantité d’informations fournies. Il y avait des pages de rapports et tous les commentaires étaient également suivis dans une feuille de calcul gigantesque. L’équipe de développement a estimé qu’il n’y avait pas assez de temps pour bien digérer les commentaires et déterminer ce qui devrait être appliqué au jeu (et à quel moment il devrait être appliqué).

Celia – Oui, les rapports UX ont tendance à être écrasants à coup sûr. Mais nous voulons être minutieux ! Peut-être trop. Moins c’est plus, même dans le monde UX, donc les tests ciblés sont certainement plus exploitables et moins accablants.

Heather – Parce que l’équipe de développement travaillait rapidement pour terminer les jalons, les commentaires UX n’étaient pas une priorité à examiner. Les rapports seraient générés, mais pourraient ne pas être examinés en profondeur avant un certain temps. Au moment où les commentaires ont été examinés, l’équipe ne les a pas trouvés aussi utiles car tant de choses avaient changé dans le jeu depuis le test UX.

Celia – Les commentaires UX devraient avoir la priorité sur tous les autres commentaires car (s’ils sont bien faits) c’est le plus neutre et « scientifique ». Cela aidera l’équipe à prendre du recul et à voir son jeu sous un angle différent – moins biaisé.

Heather – Au lieu d’aborder l’UX comme un nouveau processus/système à intégrer dans le pipeline de développement, nous avons commencé à penser à l’UX en tant que membre de l’équipe. Nous avions besoin qu’ils se sentent intégrés à l’équipe afin qu’ils connaissent les intentions de conception et puissent ajuster leurs commentaires en fonction des défis actuels du jeu.

Celia – Idéalement, vous voulez que l’UX soit proche de l’équipe tout en essayant de garder une certaine distance avec le jeu lui-même, sinon nous aussi nous deviendrons trop proches du jeu et nous commencerons à être biaisés.

Prod23

Heather – Pour habituer l’équipe à l’idée de l’UX, nous avons dû apprendre à nous connaître. Étant donné que l’équipe de développement était moins intéressée par le renforcement de cette relation, l’équipe UX a trouvé des moyens de travailler avec l’équipe de développement selon leurs conditions. UX s’est rendu facilement disponible en tant que ressource pour l’équipe. Il y avait peu de friction pour que quelqu’un parle avec l’équipe de Celia et obtienne des commentaires. N’importe qui de l’équipe est libre de les utiliser – pas besoin de passer par des cerceaux. La salle UX est située au centre pour tout le monde et la porte est toujours ouverte. La production a évangélisé l’UX et rendu son travail plus visible pour l’équipe (des choses simples – comme rappeler aux gens lors des réunions de consulter le laboratoire, inviter les gens à voir les tests UX et inviter Celia aux réunions d’équipe). Il était important de s’appuyer sur ce que Celia avait établi et de montrer aux développeurs comment l’UX pouvait faire partie de l’équipe, sans devenir une autre « porte » que le jeu devait traverser.

Prod24

Celia – Au lieu d’essayer d’imposer le processus UX à toute l’entreprise ou à l’équipe de jeu, j’ai d’abord écouté l’équipe de développement et me suis associée à ceux qui s’intéressaient à l’UX. J’ai choisi des petits projets qui étaient moins sous le feu des projecteurs. Cela nous a permis de passer par la conception – tester – itérer – retester très rapidement afin que nous puissions faire des gains rapides. Ces victoires ont ensuite pu être reconnues par d’autres équipes et l’amour UX a commencé à se répandre. Soit dit en passant, cela illustre comment un processus UX peut facilement bénéficier à des équipes et des studios plus petits, car commencer petit est en fait un avantage. Peu à peu, après avoir fait quelques tests UX et vu de bons résultats, l’équipe en est venue à apprécier comment UX peut les aider et UX est devenu une préoccupation pour tout le monde, pas seulement pour l’équipe UX. L’équipe UX est devenue une ressource que tout le monde pouvait utiliser et un concepteur UX a été embauché dans l’équipe Fortnite (Derek Diaz). Nous avons commencé à planifier UX dans le cadre de notre pipeline de développement.

Prod25

Heather – Lorsque j’ai commencé à travailler avec Celia, elle a suivi tous les commentaires UX dans cette feuille de calcul. A l’époque, c’était le moyen le plus efficace. Comme vous pouvez le voir, il est assez dense. Il suit les commentaires UX donnés à l’équipe, la priorité, quand il a été mis en œuvre et s’il a été retesté. La feuille était utilisée comme principal transfert d’informations entre l’UX et l’équipe de jeu, mais était principalement un outil pour l’UX puisque les développeurs n’étaient pas impliqués dans la conduite ou la maintenance de ce processus.

Cela a bien fonctionné au début. Il y avait quelques corrections faciles à faire dans le jeu. Mais après quelques mois, il suivait plus de 200 éléments, et très peu d’entre eux avaient été traités – ou avaient été marqués comme quelque chose à faire pour l’avenir.

Prod26

Heather – Donc, quand j’ai commencé à travailler chez Epic, j’ai vu cela comme une conversation à sens unique avec UX faisant tout le travail. Le processus n’était pas bien défini ou cohérent, il donnait donc l’impression que l’UX était quelque chose qui se passait au hasard. L’équipe de développement était disposée à revoir périodiquement cette feuille avec UX, mais cela ne faisait pas partie intégrante du processus de développement. Il n’y avait pas de propriétaire clair du côté de l’équipe de développement et il était donc difficile d’apporter des modifications au jeu et de les communiquer à UX pour un nouveau test.

Et c’était écrasant ! Il était très difficile pour un membre de l’équipe d’examiner cela de manière indépendante et d’analyser les informations et de déterminer ce qui était important ou utile à prendre en compte pour la prochaine ronde de planification. Ils avaient donc tendance à l’ignorer.

Prod27

Heather – Lorsque Celia et moi avons commencé à travailler ensemble, elle n’était pas seule à définir et à piloter le processus. Nous avons discuté des moyens de travailler ensemble pour améliorer ce que nous avions et pour faire de l’UX une partie plus intégrée du processus de développement. Afin que la relation fonctionne au mieux, nous voulions que notre processus fonctionne en synchronisation avec nos versions. Sur Fortnite, nous avons commencé par publier des tests en ligne toutes les 6 à 8 semaines et nous avons réduit le temps entre les versions. Nous travaillons en étroite collaboration avec UX pour déterminer ce qui va apporter des avantages au nouveau contenu publié dans nos tests en ligne.

Prod28

Heather – Nous avons commencé à avoir des réunions individuelles hebdomadaires pour réorganiser le processus et le rendre plus précieux pour l’équipe. Nous avons identifié les domaines où le processus devait changer. L’une des premières choses que nous avons faites a été de convertir toutes les informations UX existantes de la feuille de calcul en JIRA. Cela l’a immédiatement rendu plus accessible à l’équipe et a donné UX plus de visibilité au sein de la pile prioritaire. Ceci est une capture d’écran du tableau de bord UX, que nous utilisons pour voir ce qui doit être implémenté, trié et re-testé.

Prod29

Heather – Nous avons également mis en place quelques autres choses pour augmenter les points de contact entre les deux équipes afin que nous soyons plus étroitement alignés sur les objectifs et les priorités. Nous avons examiné les principales étapes que nous allions publier dans les 6 prochains mois et défini les priorités des fonctionnalités à tester. Nous voulions aligner étroitement les priorités UX avec les priorités du jeu, afin qu’il y ait de la valeur dans ce qui était testé. Nous avons également défini les objectifs de test UX pour les étapes clés. Nous avons formalisé à quel moment les tests se produisaient dans le développement et quel type de test se produirait (test UX de 3 jours contre test UX de 1 jour).

Les tests UX faisaient partie du calendrier de développement et ont été communiqués à l’équipe. Les équipes étaient désormais conscientes qu’elles devaient prévoir des tests UX à ces points, un pas dans la bonne direction ! Nous avons déployé des efforts concertés pour inviter l’équipe aux tests UX (il est vraiment utile de regarder d’autres personnes jouer à votre jeu) et nous nous sommes assurés qu’ils utilisaient l’UX comme ressource tôt et souvent.

Prod30

Heather – C’est le processus actuel que nous utilisons pour le pipeline UX/Dev sur Fortnite. Étant donné que nous sommes un jeu en direct, ce processus couvre un cycle de publication complet qui comprend la planification, la création de fonctionnalités, les tests, la mise en œuvre des commentaires et les nouveaux tests. Nous sommes étroitement alignés et le support UX fait plus partie intégrante de notre processus de développement.

Voici les détails:

Prod31

Célia – Ça commence quand l’équipe précise ses hypothèses pour le prochain test en ligne. Les questions proviennent des développeurs, de l’équipe d’analyse, du marketing ou des cadres. Nous déterminons les questions auxquelles il faut répondre (il est important de toujours avoir un objectif lors de la planification d’un test). Une fois les questions définies, l’équipe UX prépare en conséquence un protocole expérimental. Nous ajustons également le test avec la portée. Parfois on teste le live build qui vient d’être poussé dans de longues sessions, mais on fait aussi des tests plus courts et rapides avec des prototypes (sur papier, des prototypes interactifs, et même parfois directement dans l’éditeur).

Prod32

Celia – Compte tenu de l’objectif du test et de son protocole, nous planifions quand/comment/avec qui le faire et nous décidons quelle version utiliser.

Prod33

Heather – Une fois que nous avons défini les exigences de test, je travaille avec l’équipe pour planifier la version à utiliser. Nous devons nous assurer que les fonctionnalités que nous voulons tester fonctionnent. Si le build a des bloqueurs, le test est annulé. Nous examinons donc la construction deux jours avant pour déterminer si elle est prête ou non. Si ce n’est pas le cas, le test est annulé ou, plus probablement, reconsidéré. Si l’équipe est informée quelques semaines à l’avance du test, il lui est beaucoup plus facile de hiérarchiser ses tâches et ses bogues afin d’obtenir une version stable.

Prod34

Celia – Des tests UX sont menés et l’équipe observe les participants en temps réel. Nous invitons l’équipe à venir regarder.

Heather – Et j’essaie de ne pas planifier de réunions les jours où nous avons des tests afin que l’équipe soit libre de les regarder.

Prod35

Celia – Une fois le test terminé, nous analysons les données et un rapport UX détaillé est généré. Mais plus concentré cette fois.

Prod36

Celia – Après avoir envoyé le rapport, nous planifions une réunion rapide pour parcourir le rapport ensemble, afin de nous assurer que nous sommes alignés et que l’équipe puisse nous donner directement son avis sur les problèmes soulevés.

Pour chaque problème, nous décidons ensemble si c’est par conception donc nous le laissons faire, s’il a besoin d’un appel pour que l’équipe UX entre dans un JIRA, s’il est déjà en train d’être corrigé afin que nous fassions un suivi pour retester la fonctionnalité plus tard, etc. Lorsque UX-lab entre dans les JIRA, nous entrons des informations détaillées : description de ce que nous avons observé dans le test et/ou description d’une heuristique d’utilisabilité violée (par exemple, violation de cohérence, ou la forme de cet élément transmet une perception différente de sa fonctionnalité, etc. ). Nous ajoutons des captures d’écran et des vidéos du test UX. Nous l’étiquetons « UXLabFeedback » afin que tous les problèmes saisis avec une préoccupation UX apparaissent dans un tableau de bord. Avant chaque nouveau test UX, nous consultons le tableau de bord et regardons quels problèmes ont été marqués comme résolus afin de pouvoir vérifier si le problème UX est effectivement résolu.

Prod37

Heather – Une fois que l’UX entre dans les JIRA, le processus de triage est un moyen pour l’équipe de développement de les examiner et de déterminer si les problèmes seront résolus dans la prochaine version, une future version, ou pas du tout. Si l’équipe n’est pas d’accord avec l’un des commentaires UX ou souhaite modifier la priorité, elle rencontrera le laboratoire UX pour discuter des options. Une fois que les deux groupes sont parvenus à un consensus, la tâche est hiérarchisée de manière appropriée dans le calendrier de développement.

Comme vous pouvez l’imaginer, quelque chose que l’équipe UX marque comme Pri-1 peut être considéré comme une priorité moindre pour l’équipe. Certains des commentaires peuvent nécessiter d’importants remaniements qui ne peuvent pas être traités immédiatement et devront donc faire partie de la planification future. Certains des commentaires peuvent être en opposition avec l’intention de conception et nécessiter une conversation plus longue avec UX sur la façon de résoudre le problème. Les chefs d’équipe de grève sont chargés d’examiner les commentaires et d’engager d’autres conversations avec UX au sujet de toute question ou désaccord.

Prod38

Heather – Une fois qu’une tâche UX est terminée, nous marquons fermée dans JIRA et pour que l’équipe de Celia sache la revérifier lors du prochain test.

Prod39

Celia – Les données sont recoupées avec des informations provenant d’autres sources (analyses, support client, marketing, enquêtes UX envoyées aux participants alpha, etc.) et communiquées à l’équipe afin qu’elle puisse élaborer un plan d’amélioration de l’UX.

Ensuite, nous communiquons aux dirigeants et à l’équipe de publication les informations pertinentes et l’équipe de développement peut déjà exposer leur plan pour résoudre les problèmes soulevés. C’est un processus collaboratif; nous ne donnons jamais de commentaires directement à l’équipe de publication/de direction sans d’abord nous synchroniser avec l’équipe de développement. Il n’y a pas de surprises et certainement pas de coups de couteau dans le dos. Nous sommes ici pour aider l’équipe de développement à atteindre ses objectifs, pas pour agir comme des malins égocentriques.

De plus, comme l’équipe UX est neutre, elle ne sert aucun objectif autre que de se battre pour l’utilisateur. Cela aide donc tout le monde dans la salle à réajuster son point de vue personnel et son opinion sur le jeu (ok, ce n’est pas toujours réussi, je dois l’admettre).

Enfin, il est très important que l’équipe UX mette l’accent non seulement sur les problèmes du jeu, mais également sur tous les progrès réalisés par l’équipe de développement jusqu’à présent et sur les problèmes UX résolus. Les cadres adorent voir les choses progresser (et adorent quand des problèmes sont signalés pour être rassurés qu’on s’en occupe). L’équipe de développement adore quand nous reconnaissons les progrès réalisés (soutenus par la science, même !), donc tout le monde est content. La plupart du temps -ish … (développer des jeux est après tout une entreprise difficile et émotionnelle pour tout le monde).

Prod40

Heather – Bien que nous ayons un processus unifié et défini, il reste encore du travail ! La première partie fonctionne bien, maintenant nous devons nous concentrer sur l’amélioration des phases de triage et de vérification. Les producteurs doivent s’assurer que JIRA est mis à jour et que l’équipe s’attaque activement aux problèmes UX (et ne se contente pas de les marquer pour les étapes futures). Si les éléments ne sont pas filtrés et attribués de manière appropriée, ils perdent leur visibilité. Les deux équipes doivent avoir une meilleure compréhension du moment où les commentaires UX sont mis en œuvre afin qu’ils puissent être retestés. Il n’est pas vraiment résolu tant qu’il n’est pas retesté et montre que le problème a été résolu. Afin d’obtenir et de maintenir une haute visibilité de l’UX, les membres de l’équipe de développement doivent observer les tests UX. Et nous devons toujours être ouverts pour ajuster notre flux de travail et nos processus afin d’améliorer les choses !

Prod41

Comme vous pouvez l’imaginer, il reste encore du travail à faire, mais nous avons parcouru un long chemin ! Nous avons beaucoup appris l’un sur l’autre et avons moins peur. Tout est une question de point de vue.

Prod42

Et maintenant, l’UX fait vraiment partie du processus…

Prod43

Heather – Démystifions les idées fausses. N’ayez pas peur les uns des autres !

Celia – Commencez petit avec les développeurs intéressés par UX pour démontrer les gains rapides UX

Celia – Ne soyez pas la police UX, travaillez plutôt ensemble pour réussir et mesurez/communiquez les progrès

Heather – Établissez une boucle de rétroaction et de mise en œuvre solide et assurez-vous que les deux équipes comprennent le fonctionnement du processus. Ajustez si nécessaire.

Les deux – Célébrez ensemble !

Prod44