Niveau 17 – Interfaces utilisateur

L’article original « Level 17: User Interfaces » a été écrit par Ian Schreiber et fait partie d’un cours de game design en ligne, publié sur le blog Game Design Concepts.

L’article original et cette traduction sont publiés sous licence Creative Commons (Attribution).

N’hésitez pas à visiter le blog de Ian Schreiber et suivre son compte Twitter.

~ ~ ~ ~ ~ ~ ~

Si vous en êtes arrivés à ce stade, votre jeu je l’espère se présente bien et vous approchez des étapes finales du design. Vous pouvez encore être tentés d’expérimenter avec les mécaniques, en particulier vu la courte période de temps alloué pour le Projet de Design, mais à ce stade je veux que vous vous arrêtiez sur quelque chose qui soit au moins « assez bon » de manière à ce que vous puissiez faire l’expérience des dernières étapes du design.

Une fois que vos mécaniques sont complètes et le jeu est jouable, équilibré et atteint vos objectifs de design, la dernière chose à faire est de déterminer comment construire la version finale. Ce n’est pas simplement une question de dessiner quelques illustrations pour vos cartes et plateau et l’envoyer à l’imprimeur. Il y a certaines considérations à prendre concernant l’interface utilisateur de votre jeu, et ces considérations sont ce dont nous allons parler aujourd’hui.

Lectures / Visionnages

Lisez les articles suivants :

  • Challenges for Game Designers, Chapitre 16 (Creating a User Interface)
  • Cooperation and Engagement, un Google Tech Talk par le game designer Matt Leacock. Cette vidéo de fait relie ensemble beaucoup de concepts dont nous avons parlé dans ce cours, depuis les niveaux de difficulté et les états de flow jusqu’au processus itératif et au récit de jeu, et il devrait servir à solidifier ces concepts en utilisant l’exemple concret de Pandémie, un des jeux de société les plus vendu de l’année dernière. Mais ce dont je veux réellement vous amener à faire attention est comment Matt Leacock présente son travail itératif sur le design des composants du jeux eux-même, comment il a déterminé la forme, l’orientation et la couleur des cartes. La conférence actuelle dure seulement 30 minutes, bien qu’il y ait 20 minutes supplémentaires à la fin avec les questions du public.

Qu’est que l’interface utilisateur ?

Normalement, nous pensons au terme interface utilisateur (ou UI) lorsqu’il s’applique aux applications logicielles. Ce terme fait référence aux parties du logiciel qui interagissent directement avec une personne. Cela couvre les choses comme les options qui sont disponibles pour l’utilisateur à n’importe quel moment, comment ces options sont présentées sur l’écran de l’ordinateur, aussi bien que les interactions physiques (souris, clavier, gamepad, etc.). En général, avec les jeux vidéo, l’UI est divisée en deux parties : l’entrée (c’est-à-dire, comment le joueur donne des ordres au jeu) et la sortie (comment le jeu communique les résultats de ces actions et d’autres aspects de l’état du jeu au joueur).

Mais que se passe t’il si vous faites un jeu non-numérique ? Est-ce qu’il y a une UI ? Bien sûr qu’il y en a une – et si rien d’autre, il est plus important de la réussir, car vous n’avez pas un ordinateur qui impose automatiquement les règles du jeu. Si les joueurs ne comprennent pas les règles d’un jeu non-numérique, le seul recours est souvent d’arrêter de jouer. En tant que game designer, la dernière chose que vous voulez pour vos brillantes mécaniques et expérience de jeu construites avec précaution sont d’être ruinées à cause d’un problème d’interface.

Dans les jeux non-numériques, l’UI est les composants eux-mêmes, car ils représentent à la fois comment vous interagissez avec le jeu (à travers la manipulation des éléments du jeu) et recevez un feedback (en voyant l’état du jeu). Alors ce dont nous parlons réellement aujourd’hui est la conception des composants finaux.

Le design de l’interface utilisateur

Qu’est-ce qui rend une UI meilleur qu’une autre ? Nous parlons en général de deux choses :

  • Facilité d’utilisation. Si vous savez déjà ce que vous voulez faire, à quel point est-ce rapide et facile de réaliser correctement la tâche que vous désirez ?
  • Facilité d’apprentissage. Si vous êtes nouveau venu au jeu, à quel point est-il facile de déterminer ce que vous pouvez faire et quelles informations sont disponibles pour vous ?

En pratique, il y a souvent un compromis entre les deux. Par exemple, sur les ordinateurs, la présence de « raccourcis » spéciaux (les touches de combinaisons Shift, Alt, Ctrl, Cmd et similaires) sauvent du temps en rendant rapide et facile la réalisation de tâches usuelles comme sauvegarder un fichier ou basculer entre les applications. Mais si elles étaient la seule façon de réaliser la tâche (comme c’est le cas dans certains vieux logiciels de traitement de texte qui n’avaient pas de menu), cela rend les applications difficiles à apprendre pour la première fois.

Dans les jeux de plateau, vous voyez souvent ce compromis avec la façon dont l’information est présentée. Des graphiques, tableaux, mots-clefs, symboles spéciaux et icônes – tous ceux-ci rendent plus facile pour un joueur expérimenté d’avoir un résumé rapide de l’état du jeu, mais elles peuvent prêter à confusion et intimider le joueur novice qui ne sait pas ce que ces choses veulent dire. L’alternative, écrire tout de façon extensive, rend plus facile pour un nouveau joueur de voir immédiatement ce que tout fait… mais rend aussi le jeu plus long pour les joueurs qui connaissent déjà les règles et n’ont pas besoin d’avoir tout répété en entier sur chaque carte.

Parfois vous pouvez inclure les deux. Les applications logicielles modernes incluent des raccourcis et des éléments de menu, et certains ont même un mode « débutant » qui masque les fonctionnalités avancées pour garder les menus simples, en rendant le logiciel plus facile à apprendre. Les jeux de cartes comme Magic : The Gathering incluent des mots-clefs, mais ensuite expliquent ces mots-clefs entre parenthèses pour les joueurs qui ne savent pas ce que ces mots-clefs signifient.

Regardez toutes les mécaniques dans votre jeu, et ce que les joueurs doivent faire de manière à les suivre. Est-ce qu’il y a des cas où votre rédaction pourrait être plus claire pour les joueurs qui débutent ? Est-ce qu’il y a des situations où les joueurs expérimentés se sentent comme s’ils faisaient de la comptabilité excessive ou de la prise de notes, ou réalisent des étapes multiples automatiques, où il serait possible de fluidifier l’expérience ?

Les deux modèles de l’utilisabilité

Dans l’utilisabilité pour les applications logicielles, il y a deux concepts reliés : le modèle de l’utilisateur et le modèle du programme. Le modèle de l’utilisateur représente comment l’utilisateur (i.e. le joueur) pense que les choses devraient marcher. Le modèle du programme représente comment le logiciel fonctionne de fait fonctionne. (Dans les jeux non-numériques, vous pouvez pensez au « modèle de programme » comme étant les règles actuelles du jeu telles que souhaitées par le designer, et le modèle de l’utilisateur ce que les joueurs pensent que les règles sont.)

Voici la chose importante. Le modèle du programme a toujours raison. Si le modèle de l’utilisateur et le modèle du programme se correspondent, il n’y a pas de problème. Si les deux sont différents, le joueur va vouloir faire quelque chose, il s’attend à ce qu’une chose arrive, mais une autre chose arrive à la place.

Avec les jeux informatiques, cela mène à la frustration, et les critiques diront que le jeu a des « contrôles pauvres » (souvent sans complètement comprendre pourquoi).

Dans les jeux de plateau, si le modèle du joueur le le modèle du « programme » sont différents, les joueurs joueront simplement au jeu de façon incorrecte. Parfois, cela signifie que les joueurs auront une expérience sous-optimale, parce que certains aspects du jeu paraîtront déséquilibrés. D’autres fois, les joueurs passeront un très bon moment, mais quand ils joueront plus tard au jeu avec d’autres joueurs qui jouent au jeu de la « bonne » façon il y aura des débats sur les règles.

Changer le modèle de l’utilisateur

Il est usuel de voir un décalage entre les modèles d’utilisateur et de programme pendant le playtest. Voici ce à quoi cela ressemble : avec chaque chaque groupe de playtest, les joueurs font mal une chose en particulier la première fois. Cela suggère un problème de facilité d’apprentissage.

Un cas plus sérieux de problème de facilité d’utilisation avec l’UI de votre jeu. Cela ressemble à cela : un ou plusieurs joueurs fait accidentellement quelque chose de mal dans les règles. Vous le leur pointez, et ils corrigent leur comportement. Mais ensuite ils oublient et ils le font mal à nouveau au tour suivant. Et le suivant. Et vos joueurs s’excusent de continuer à le faire mal, et ils se sentent idiots.

Dans les cas comme cela, il serait idéal de changer le modèle d’utilisateur. C’est à dire, vous voudriez changer les attentes ou actions des joueurs de manière à correspondre au modèle « correct » du jeu lui-même. Malheureusement, en pratique, c’est effectivement impossible à faire. Les gens aiment leurs habitudes. Nous construisons des modèles mentaux élaborés dans un processus lent qui requiert un grand effort de la part d’une personne, et la plupart des gens ne feront pas ce type d’effort pour votre jeu.

Pour illustrer cela dans mes cours en classe, je raconter l’histoire du design d’un avion de chasse. Une fois, l’armée avait noté qu’un type particulier d’avion avait un nombre plus grand que la moyenne d’éjection accidentelle du pilote (c’est à dire, le siège éjectable du pilote était activé quand le pilote n’avait pas l’intention que cela arrive). Compte tenu du coût des avions militaires, cela devient très cher quand quelque chose comme ça arrive, alors ils ont fait étudier le problème à beaucoup ingénieurs pour déterminer pourquoi le siège s’éjectait, mais aucun problème mécanique ou électrique ne pouvait être identifié. Éventuellement, quelqu’un a une la bonne idée de regarder l’avion qui avait accidentellement éjecté les pilotes sur lesquels ils s’étaient entraînés. Il est apparu que dans tous les cas, ils s’étaient entraînés sur le même avion où les positions d’accélération et les contrôles du siège éjectable étaient inversés. Ainsi, quand les pilotes entraient dans ce nouvel avion, ils avaient déjà formé un modèle mental de là où étaient les contrôles, et aucun entraînement sur le nouveau avion ne pouvait le changer.

Identifier le modèle de l’utilisateur

Bon, alors nous ne pouvons pas changer le modèle de l’utilisateur. Cela signifie que si vous trouvez un décalage entre le modèle de l’utilisateur et celui du jeu, vous devriez changer l’interface du jeu de manière à ce que soit il se conforme au modèle de l’utilisateur, ou changer l’interface de manière à ce qu’elle soit suffisamment différente qu’elle déclenche un modèle d’utilisateur différent. Mais comment savez-vous quel est le modèle utilisateur en premier lieu ?

Par chance, c’est plutôt facile à faire. La façon la plus facile est de demander. Trouvez des gens qui jouent à des jeux similaires à celui qui vous faites. Mettez en place la situation pour eux, et demandez-leur comment ils pensent que le jeu devrait marcher (ou comment ils pourraient accomplir certaines tâches, ou quoi que ce soit que vous essayez de déterminer) s’ils ont a deviner. Une fois que vous demandez à plusieurs personnes, un consensus clair émergera plutôt rapidement.

Une autre façon plutôt facile d’identifier le modèle de l’utilisateur est de playtester. Regardez quand les gens jouent au jeu, et prenez des notes quand ils font quelque chose mal.

Pour finir, si le modèle de votre jeu n’est pas trivial, il est probablement mauvais. Toutes choses étant égales, les gens vont assumer la simplicité.

C’est la responsabilité de qui, de toute façon ?

Vous pourriez vous demander, dans certains cas, si les problèmes d’utilisabilité sont réellement votre problème en tant que game designer. Après tout, si vous créez un bon jeu et donnez des règles complètes et correctes, n’est-ce pas la responsabilité des joueurs de réellement, vous savez, lire les règles et les suivre ? S’ils jouent mal à votre jeu, en quoi est-ce votre faute ? Certaines personnes sont justes stupides ou ne font pas attention, et certainement le brillant designer ne devrait pas être tenu responsable de ces gens, n’est-ce pas ?

Bien, tout d’abord, cela n’est peut-être pas la faute des joueurs. Ils pourraient avoir appris les règles par quelqu’un d’autre. Il pourraient être dans un environnement distrayant, alors ils ne peuvent pas donner aux règles leur attention complète. Ils pourraient ne pas avoir les règles ; peut-être qu’ils ont acheté le jeu en seconde main et les règles manquaient. Le langage dans lequel les règles ont été écrites pourrait ne pas être leur langue natale. Il y a nombre de raisons pour lesquelles une personne parfaitement intelligente et rationnelle pourrait avoir des difficultés. Alors, n’écartez pas ces personnes comme n’étant pas digne de votre temps.

En second, la plupart des erreurs d’utilisabilité semblent être une erreur de la part de l’utilisateur (joueur), mais elles sont réellement un problème d’UI qui pourrait être corrigé. Prenez en considération : si votre jeu était facile à utiliser, il ne laisserait pas les joueurs faire des erreurs. En tant que designer, prenez la responsabilité de l’utilisabilité de votre jeu, et vous trouverez que les joueurs l’apprennent plus vite, font moins d’erreur, et en général passent un meilleur moment.

Construire une bonne UI

Maintenant que nous savons comment identifier une mauvaise UI, comment en concevez-vous une bonne ? En général, une bonne UI fait ces deux choses :

  • Elle fait ce que l’utilisateur pense qu’elle fera ; et
  • Elle donne à l’utilisateur un feedback de manière à ce qu’il sache ce qui s’est passé.

Si le jeu ne fait pas ce que le joueur pense qu’il fera, c’est un problème avec le modèle de l’utilisateur qui ne correspond pas au modèle du jeu, comme nous l’avons déjà discuté. Mais il y a un autre aspect dans le design de l’UI : donner au joueur un feedback immédiat de manière à ce qu’il sache que ce qu’il a fait est correct (et, dans le cas peu éventuel qu’il ait fait quelque chose d’incorrect, qu’il voit immédiatement ce qui est mauvais et comprenne pourquoi).

Voici une nouvelle façon de regarder ce qui fait une bonne UI :

  • Elle rend facile le fait de faire correctement les choses ; et
  • Elle rend difficile le fait de faire incorrectement les choses.

Voici un exemple : supposons que vous ayez un jeu de plateau avec différents types de jetons. Peut-être que vous avez une série de marqueurs qui suivent la trace du score des joueurs, en utilisant une piste de score autour du bord du plateau. Peut-être que le plateau du jeu a une carte divisée en provinces et les joueurs ont des unités militaires qui sont placées dans les provinces. Peut-être qu’il y a aussi un marché global avec des biens à acheter et à vendre, et une piste séparée pour chaque bien qui liste son prix actuel.

Il serait facile de confondre toutes ces pièces de jeux. Mais que dire si chaque jeton avait une taille et forme différente, et chaque espace sur le plateau correspondait à la forme du jeton qui était utilisé à cet endroit ? Soudainement, cela devient bien plus facile de déterminer que les petits jetons doivent aller sur les petites cases de la piste de score, les biens en forme d’étoile sur la case des prix en forme d’étoile, et ainsi de suite.

Comment les joueurs se souviendront comment ajuster les valeurs des biens du marché sur chaque piste ? Un résumé des règles imprimé sur le plateau à côté des pistes rend plus facile le fait de s’en souvenir. Et comment le combat est-il résolu ? La force des unités, les statistiques et capacités peuvent être imprimées sur les unités militaire elles-mêmes, et les règles restantes peuvent être soit résumées sur le plateau ou sur une carte de référence rapide ou une autre aide de jeu donné à chaque joueur au début de la partie.

Au fur et à mesure où vous concevez l’UI, voici un processus que vous pouvez suivre :

  • En premier, faites une liste des tâches que les joueurs ont besoin de faire pour finir le jeu. Rendez facile le fait de réaliser ces tâches.
  • En deuxième, faites attention aux tâches les plus communes, celles que les joueurs font de manière récurrente. La difficulté et la complexité d’une tâche devrait être en proportion de la rareté avec laquelle elle est utilisée.
  • Itérez à travers le playtesting.

Usage de la couleur

La couleur est un bon moyen de transmettre de l’information aux joueurs si fait correctement. C’est efficace : la couleur ne prend pas de place supplémentaire sur un composant de jeu, parce que le composant est déjà présent ; tout ce que vous faites est de le colorier. Voici quelques astuces vite fait bien fait pour réfléchir à la couleur dans votre jeu :

  • Les couleurs qu’un œil humain normal détecte le plus facilement sont le rouge et le vert, suivi du bleu. Ces couleurs tendent à ressortir le plus… ce qui peut être pratique pour attirer l’attention, mais mauvais pour la fatigue de l’œil si vous utilisez des couleurs vives très saturées.
  • Ne vous reposez pas uniquement sur la couleur ; une portion non triviale de votre public a un certain degré de daltonisme. Variez l’intensité des couleurs aussi (de manière à ce que, par exemple, photographié avec un appareil photo noir et blanc, vous pourriez toujours voir la différence), et utilisez différentes formes en complément des différentes couleurs. En ayant des choses différenciées de multiples façons (différentes formes, différentes couleurs, etc.) cela rend réellement plus évident que ces choses sont distinctes les unes des autres.
  • Utilisez la couleur de manière consistante. Si vous utilisez une couleur pour différentes choses dans un jeu, ces choses devraient être reliées. Certains jeux de plateau auxquels j’ai joué, par exemple, ont (disons), cinq ressources différentes, et chacune a une couleur, mais chaque joueur a aussi une couleur, et certaines couleurs des joueurs et couleurs des ressources sont les mêmes, même s’il n’y a pas de relation entre le joueur vert et les ressources vertes. Ce type de chose peut embrouiller les joueurs qui pourraient penser qu’une ressource particulière est détenue par leur adversaire quand cela ne l’est pas.

Plus d’astuces sur le design de l’UI

Sans aucun ordre particulier :

  • Automatisez ou éliminez les tâches qui n’impliquent pas de décisions intéressantes, si possible. Chaque clic ou appui sur une touche de clavier dans jeu vidéo, ou lancer de dé ou retournement de carte dans un jeu de plateau, devrait impliquer que le joueur fasse quelque chose d’intéressant pour lui. Si le joueur doit faire en premier un paquet de tâches d’entretien simplement pour avoir le privilège de prendre des décisions intéressantes plus tard, voyez ce que vous pouvez faire pour fluidifier les choses ennuyeuses.
  • Utilisez des métaphores visuelles. Elles rendent plus évident ce qu’une chose représente. Si vos joueurs contrôlent un paquet de pièces qui représentent des gens, utiliser des pions en forme de personnes est plus clair que d’utiliser des cubes en bois. Comparez les images de pion ci-dessous. Chacun a un effet différent quand le joueur le voit.

  • De la même manière, si vous utilisez des icônes dans le jeu pour représenter certaines aptitudes, choisissez des icônes qui ressemblent au concept qu’elle représentent (si vous pouvez).
  • Soyez consistant avec les jeux similaires. Dans un RPG, des cœurs rouges signifient probablement la vie ou des points de vie, alors qu’une goutte bleue représente probablement la mana ou des pouvoirs magiques. Pourquoi ? Parce que c’est comme cela que tout le monde le fait, et vos joueurs assumerons par défaut que vous le faites aussi de cette façon.
  • Ne dites pas simplement « et bien, c’est déroutant, alors je l’expliquerai dans le manuel ». Souvenez-vous, vos joueurs peuvent ne pas avoir le manuel et ils ne l’ont peut-être pas lu. Essayez de rendre votre UI suffisamment intuitive pour que votre jeu n’ait même pas besoin d’un manuel.

Leçons apprises

Donner à votre jeu une bonne UI est une compétence qui est distincte du design des systèmes cœur, mais elle est une compétence importante à apprendre. Garder à l’esprit que, avec la plupart des choses dans ce cours, le design d’UI est un large domaine et nous allons uniquement couvrir les bases. Il y a des cours entiers (et même des diplômes universitaires dédiés spécifiquement à l’UI, sans oublier de mentionner des centaines de livres, et je vous encourage à chercher ces ressources après que ce cours soit terminé.

Lectures supplémentaires

Il y a de nombreux grands livres sur le design d’UI. Si le sujet vous intéresse, je vous recommanderai Design of Everyday Things de Donald Norman, qui va dans les détails de comment la conception de quelque chose d’aussi simple qu’une porte pour une cuisinière peut tourner horriblement mal… avec des leçons qui peuvent être appliquées directement aux jeux, qu’ils soient numériques ou non. Aussi, pour les manières de présenter les données du jeu aux joueurs de façon efficace et innovante, je recommanderai n’importe lequel des livres d’Edward Tufte : The Visual Display of Quantitative InformationEnvisioning Information, et Visual Explanations.

If you are primarily interested in video games, there are so many great sources on computer UI that it would be hard to list them all here. If you have any personal favorites, leave as a comment on this blog post, or post on Twitter using #GDCU.

Jeu à la maison

Le jeu à la maison démarré il y a une semaine consistait à préparer une session de test en aveugle, qui devrait être terminé ce jeudi (ou avant). Continuez à travailler sur cela si vous ne l’avez pas déjà terminé.

Votre autre tâche, aussi avant ce jeudi, est d’analyser de façon critique votre jeu en relation avec l’interface utilisateur. Pensez à vos playtests déjà réalisés, et avec quelles règles vos joueurs ont du souci. Quels types de composants ou aides de jeux rendraient plus facile pour eux de se souvenir ?

Venez avec un plan d’interface utilisateur pour la version finale de votre jeu. Ce plan devrait impliquer les éléments suivants :

  • Une liste complète des éléments du jeu qui seront inclus dans le jeu final.
  • Pour chaque composant, une description détaillée de ce que vous prévoyez de faire. Si vous avez, disons, « un pion pour représenter chaque joueur », combien de pions seront inclus ? De quelles couleurs seront-ils ? Avec quelles formes ? Seront-ils faits en métal, en plastique, en bois, ou autre chose ?
  • S’il y a des cartes, décrivez une carte échantillon. Quelle information sera présentée sur chaque carte ? Est-ce que les cartes seront orientées en « portrait » ou en « paysage » ? Comment l’information sera-t-elle présentée – où sur les cartes ira chaque élément ? Comment est-ce que cela sera affiché – quelles couleurs, formes, et mots-clefs avez vous prévu d’utiliser (si c’est le cas) ? S’il y a différents types de cartes, faites cela pour chacune.
  • S’il y a un plateau, décrivez la composition du plateau. Comme pour les cartes, prenez en considération quelle information sera affichée sur le plateau, comment il est organisé, et comment il est présenté.
  • S’il y a d’autres composants, donnez la même information que listée ici.

Cette liste est principalement pour votre propre référence, et son objet est de rendre aussi facile que possible pour vous d’assembler votre jeu final (que vous ferez ce week-end). La liste sert aussi comme vérification de conformité : avez-vous accès à tous les composants dont vous avez besoin ? Si vous ne possédez pas certains d’entre eux, pensez à comment vous planifiez de les créer ou les acheter.

Post your UI plan to the forums no later than this Thursday (August 27), noon GMT.

By next Monday (August 31), read and respond to at least three other posts at the same level as you, giving preference to those that have not had any responses. By reading, it may give you some ideas to use on your own project. You may also be able to share some ideas you already have with others, helping them to improve their projects.

Article précédent : Niveau 16 – L’équilibrage du jeu

Article suivant : Niveau 18 – L’itération finale

2 réflexions sur « Niveau 17 – Interfaces utilisateur »

    • Avec plaisir !
      C’est vrai que Ian c’est un peu un modèle d’enseignement du game design (ses conférences GDC sont toujours un régal)
      Note que j’espère un jour pouvoir traduire ses cours sur l’équilibrage, qui sont particulièrement denses.

Les commentaires sont fermés.