Image for post
Image for post
Mon poste de travail : des marqueurs, des ardoises, du papier, des croquis, ma tasse et mon sablier

Étude de cas UX : du templating à la documentation technique

Factoriser l’interface pour définir l’API

TL;DR

Je propose au cours de cet article de parcourir étape par étape ma démarche design concernant la refonte UX d’une application pour tablette. Cette refonte passe par l’analyse de l’application existante et la considération des retours utilisateur, puis par itération par la refonte ergonomique de l’interface pour ensuite évoluer vers des gabarits (templates) et des modèles d’éléments. La particularité de cette démarche design se trouve dans l’élaboration parallèle d’une documentation technique paramétrant et rationalisant chaque élément de l’interface.

(Petit aparté vocabulaire)

Dans cet article, je vais utiliser des termes techniques qui ne sont pas systématiquement maîtrisés par tout le monde. Je vous propose ici quelques définitions et explications afin que vous puissiez apprécier l’article sans obstacle majeur.

Le projet Ludomuse, un moteur de jeux mobiles et collaboratifs

Les jeux mobiles et autres variantes de jeux de pistes se multiplient dans les musées et sont connus pour créer de la motivation auprès des plus jeunes. Toutefois, même si les jeunes publics utilisent ces dispositifs pendant de longues durées, ce n’est pas toujours au bénéfice de l’expérience de visite ou de l’acquisition de savoirs et de repères culturels.

Image for post
Image for post
Crédits : © Erasme

Analyse de l’interface existante

Ma démarche démarre par l’analyse de l’application actuelle. Cette application tourne sur plusieurs tablettes, de 5 à 7 pouces. Voici quelques interfaces utilisées dans l’application pour les expérimentations publiques d’un des jeux (le musée de la Biscuiterie LU) :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Dans l’ordre : écran de connexion (fig. 1), tableau de bord du jeu (fig. 2), écran de jeu récepteur (fig. 3), écran de jeu avec volet latéral ouvert (fig. 4), écran de jeu émetteur (fig. 5)
Image for post
Image for post
  • Recentrer l’application sur la narration unique : il s’agira de focaliser l’application sur la narration de chaque jeu, la production transversale comme logique directrice ;
  • Délimiter et rationaliser la personnalisation graphique du jeu : il s’agira de convertir l’application en un « outil » de mise en narration interactive de contenus : mises en page, cohérence visuelle, couleurs et images, structures et grilles, etc.

Distinguer les écrans pour les abstraire

Pour définir les typologies d’écran, j’ai mis à plat toutes les interfaces à disposition. Reprenons neuf écrans clés d’un jeu :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
  • L’écran d’interaction, qui intègre le spectateur dans la production transversale et qui est par conséquent un écran de saisie d’information aussi en amont du jeu (pseudonyme, rôle, partenaire) ;
  • Le tableau de bord, qui ancre chaque étape d’interaction (mini-jeu) dans une narration globale et qui permet à l’utilisateur de connaître sa progression dans la session de jeu.
Image for post
Image for post
Image for post
Image for post

L’écran d’information, moteur de la narration

Mon travail d’analyse des éléments individuels a commencé par l’écran d’information. Selon moi, cet écran a un véritable potentiel de déclinaison : position du texte, mise en valeur de l’image, variabilité du média. Voici une sélection de 9 écrans d’information extraits du storyboard du jeu de la biscuiterie LU :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Dans l’ordre : deux écrans d’information sans cache, écran affichant un média vidéo, écran avec cache blanc
  • Sa couleur de texte
  • Sa largeur, limitée à quatre valeurs : 100%, 2/3, 50% et 1/3 de l’écran
  • Sa hauteur, elle aussi limitée à quatre valeurs : 100%, 2/3, 50% et 1/3 de l’écran
  • Son ancrage, sa position dans l’écran
  • L’affichage ou non de son cartouche
  • Si le cartouche est affiché, sa couleur de fond
Image for post
Image for post

Le tableau de bord, cœur de la production transversale

Actuellement, le tableau de bord se structure en deux zones horizontales : la zone supérieure affiche les informations relatives à l’utilisateur de la tablette, donc son pseudonyme, une vignette de profil, le nombre de points accumulés durant la session de jeu et l’état de sa progression au sein d’une étape d’interaction. La zone inférieure affiche les informations du partenaire de jeu. Deux modes d’affichage sont disponibles : le premier n’affiche que les informations de l’utilisateur courant, le second permet une comparaison entre les deux joueurs. Les items de la chronologie sont composés de deux bulles : la première contient un aperçu de la récompense obtenue et la seconde permet d’afficher la consigne de l’étape d’interaction en la touchant sur la tablette :

Image for post
Image for post
Image for post
Image for post

Recentrer l’application autour d’une expérience unique et collaborative plutôt que sur un outil technique de médiation narrative

Chaque récompense est désormais représentée sous forme de « carte ». Cette carte peut afficher un terme clé, une description, un visuel et une image de fond : la personnalisation de chaque carte est donc ouverte.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Améliorer l’ergonomie de la navigation

La structure d’une activité est simple : après la configuration du jeu se déroule une boucle répétée d’étapes d’interaction comprenant des écrans d’information et des écrans d’interaction. Des éléments de navigation permettent d’accéder à l’écran suivant, de revenir à l’écran précédent, de mettre en pause une vidéo ou un son ou encore depuis le tableau de bord de lancer le mini-jeu suivant. Actuellement, ces éléments de navigation sont graphiquement incohérents et inconstants :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Éviter toute frustration de l’utilisateur en lui indiquant comment se comporter dans le musée et comment interagir avec l’interface

Sans indication ni légende, l’utilisateur peut être perdu, d’autant que le dispositif va aussi être utilisé par des profils peu ou pas habitués par le support numérique. De même, lorsque l’utilisateur répond faux ou doit effectuer une action indépendante de la tablette (échanger avec son partenaire, se rendre à un endroit du musée), une information doit figurer sur l’écran. Après avoir échangé avec Patrick, chef du projet Ludomuse, nous avons convenu de l’importance d’une information présente sur quasi tous les écrans indiquant à l’utilisateur quoi faire et comment, tel un assistant référant du comportement à adopter.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Scénario du choix du partenaire : quatre états successifs, avec pour chaque une posture attendue différente (attendre, choisir, valider, attendre)
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Intégrer la configuration du jeu dans l’expérience fluide de l’utilisateur

Les anciennes interfaces des écrans de configuration n’étaient pas optimisées pour une expérience agréable et fluide de l’utilisateur. En effet, les interactions étaient très techniques et peu adoucies par leur formalisation visuelle :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Moduler et abstraire : du design au code

En parallèle de cette démarche UX, j’ai pris en compte la phase de développement et de mise en œuvre technique de ces nouvelles maquettes. Tout au long des itérations, l’objectif était de simplifier mais aussi de faire émerger des similarités entre les éléments et entre les typologies d’écran pour simplifier leur intégration. En effet, le jeu est développé à l’aide d’un framework C++ (Cocos2D) : c’est pourquoi j’ai défini des entités, des objets structurés pour être déclinables et paramétrables.

Image for post
Image for post

TextItem

Le texte est considéré comme un objet TextItem qui prend comme paramètres son contenu, sa largeur, sa hauteur, son ancrage, l’affichage ou non de son cartouche, et la couleur de son cartouche.

Image for post
Image for post

NavItem

Chacun des boutons de navigation est considéré comme un objet NavItem, qui prend pour paramètres son contenu, son icône, son ancrage dans l’écran, la couleur de son texte quand l’élément est actif ou inactif, sa couleur de fond quand l’élément est actif ou inactif ainsi que son état ici encore actif ou inactif. Avec toutes ces combinaisons, il est possible de décliner tous les boutons de navigation nécessaires dans l’application pourtant hérités du même modèle.

Image for post
Image for post

InfoItem

Les espaces d’information ancrés en haut ou en bas de l’écran recouvrent les mêmes paramètres d’affichage, à savoir leur contenu, leur position et leur icône si présente, et peuvent donc se regrouper sous l’objet InfoItem.

Image for post
Image for post
Image for post
Image for post

FieldItem

Les écrans d’interaction intègrent aussi des NavItem et des InfoItem. Il faut définir des modèles pour les éléments interactifs. On pourrait avoir un objet pour chaque typologie de champ : bouton, champ texte, élément draggable, élément droppable, multichoix… Pour factoriser au mieux, j’ai déclaré un objet FieldItem qui est parent de tous les types de champ. Il sera possible pour les développeurs de créer des objets enfant pour chaque type héritant de FieldItem.

Image for post
Image for post

FieldSet

Pour définir la grille d’affichage des FieldItem sur chaque écran, un objet invisible parent nommé FieldSet les englobe. Sa structure est donc très simple :

Image for post
Image for post
Image for post
Image for post

RewardItem

Le tableau de bord synthétise les récompenses obtenues et à obtenir pour poursuivre l’activité. Puisque ces éléments sont récurrents, nous les interprétons en tant qu’objets par des RewardItem. Ces objets définissent leur contenu, leur couleur de fond, leur image de fond, leur description et leur état (obtenu ou à obtenir).

Image for post
Image for post

MediaItem

Un autre objet est proposé pour ajouter des images, des vidéos, des intégrations (embed) de cartes géographiques ou des sons. L’objet MediaItem permet donc d’intégrer des ressources audiovisuelles, prenant notamment pour paramètres son type de média, sa source et sa position dans l’écran.

Image for post
Image for post
Image for post
Image for post

De la v1… à la v1.0.1

Une démarche de documentation amène inévitablement aux requestionnements des conventions d’écriture, des constantes à utiliser et des améliorations des structures. Après avoir appliqué mon modèle à quelques écrans, j’ai remarqué plusieurs optimisations allant dans le sens d’un système de template JSON (voir la partie suivante de cet article). C’est pourquoi les suffixes Item de tous les objets (TextItem, InfoItem, RewardItem) sont retirés. Cela permet d’une part de simplifier les nomenclatures, et surtout d’être strictement plus rigoureux : en effet, un RewardItem n’est pas qu’un item visible sur l’écran mais est un objet contenant des données. Un Reward est donc plus générique.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Ancien modèle de structure JSON de l’application
Image for post
Image for post
  • Les éléments d’information qui guident l’utilisateur dans les actions à effectuer pour interagir et naviguer ;
  • Les éléments de contenu qui sont manipulables ou non par l’utilisateur et qui formalisent l’écran.
Image for post
Image for post

Générer des templates pour décliner des écrans

On a déjà identifié trois typologies d’écran (information, interaction, tableau de bord) mais on peut constater des compositions d’écran similaires. Ces similarités se justifient par la récurrence de briques d’interaction (puzzle, transfert d’images au partenaire, quiz) ou de nombre de contenus.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Développer des outils pour faciliter la prise en main de la nouvelle charte

Au terme de la démarche, j’ai pris conscience de l’ampleur des modifications sur le projet. En effet, le cœur du système doit être quasi entièrement repensé pour comprendre des objets, pour intégrer les templates et pour adapter les scénarios existants. Avant de briefer les développeurs, j’ai développé en plus de la documentation deux outils leur permettant de prendre en main le plus efficacement possible la nouvelle architecture de données.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Conclusion

Après la présentation de cette nouvelle architecture, les développeurs se sont montrés satisfaits et se lancent dans le développement dans quelques semaines. En parallèle, les acteurs des musées qui créent les scénarios et donc les écrans de jeu sont aussi enthousiastes et se réjouissent de la rationalisation des éléments méta (la consigne en haut, l’ordre/indication en bas, les éléments latéraux de navigation).

Written by

Design technologist & UX interactive designer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store