Le contrôle de version : comment un rédacteur UX pèse chacun des mots qu'il emploie
En design UX, un seul verbe mal placé peut égarer les utilisateurs, les frustrer et créer de la confusion. C’est pourquoi le rédacteur UX Henry Freedland choisit ses mots avec le plus grand soin lorsqu’il est amené à travailler sur une nouvelle fonctionnalité.
Partager Le contrôle de version : comment un rédacteur UX pèse chacun des mots qu'il emploie
Illustration principale par Antonio Carrau
Concevoir un produit, c'est un peu comme inventer de nouvelles lois de la physique. Vous inscrivez un univers d'activités prêt à être mis en mouvement, à la fois par des personnes, des produits, des machines et du code. Pour comprendre comment naviguer dans cet univers, les gens doivent savoir comment les autres agents se comportent. En d'autres termes, ils doivent savoir ce qu'est la chute même s'ils ne peuvent pas calculer la force de gravité. En tant que discipline, l'écriture UX essaie de trouver cet équilibre.
C'était ma tâche lorsque nous avons répondu à la demande de nos utilisateurs de créer (pour l'amour de tous les points d'accès défectueux) une sorte de prototype de "mode hors ligne". Georgia Rust, chef de produit chez Figma, avait réuni des ingénieurs pour créer un brouillon, avant d'affiner de modèle de travail avec des designers produits. Il semblait prêt si certaines complications d'interface utilisateur et de performance pouvaient être résolues, mais ils avaient d'abord besoin de quelques mots pour expliquer la nouvelle fonctionnalité et comment l'utiliser.
En tant que rédacteur UX qui a travaillé sur le prototypage, j'ai été sollicité pour consulter un menu. J'ai lu les discussions de l'équipe et j'ai pensé, « Ah, une fois de plus ». Les éléments de langage révélaient des questions profondes sur ce qui se passait réellement.
Version 1 : Qu’y a-t-il sous le capot ?
Ce que nous considérons aujourd'hui comme un « chargement » est un sous-ensemble de chargements survenus tout au long de l'histoire de l'informatique. Le terme de « booting », par exemple, est une forme abrégée de « bootstrap loading », c'est-à-dire l'idée qu'un ordinateur doit, d'une certaine manière, se charger pour démarrer. Cette expression est une référence à une expression anglaise du XVIIIe siècle « to pull oneself up by one’s bootstrap » (que l'on pourrait traduire par « se relever par ses propres moyens »).
Au départ, la phrase de substitution était « prototype de préchargement » (une proposition très précise sur la fonction de programmation).
Les prototypes chargent généralement écran par écran, et non tous à la fois, lorsque vous interagissez avec eux. Cette nouvelle option vous permettrait de tout charger à l'avance et de le conserver suffisamment longtemps pour l'utiliser. En code, améliorer les performances web tout en rassemblant les ressources importantes au début du chargement est appelé « préchargement », donc si vous avez un esprit technique, ce verbe exprime assez bien cette expérience.
Mais pour les autres, « précharger » n'est pas clair. Ce terme est précis, mais il inclut une dimension temporelle. « Pré- » indique un phénomène qui se produit avant un autre comme « préchauffer » un four. Dans cet exemple, vous vous attendez à ce qu'un four éteint soit allumé. En voyant cette option pour « précharger », en revanche, vous seriez déjà passé par un écran de chargement pour que le prototype soit affiché. Ce que nous voulons dire, c’est que vous pouvez charger le reste avant de faire autre chose (par exemple, effectuer une présentation hors ligne). Mais pour ce faire, vous devriez en savoir plus.
Une action informatique mieux comprise est le « chargement ». Est-ce qu'elle pourrait s'appliquer ici ?
Nous avons essayé différents termes : « Load full prototype », « Load all screens », « Load all assets ». Mais chacun d'eux semblait briser la confiance entre la personne et le programme. En effet, si vous venez de charger ce prototype, pourquoi ne serait-il pas entièrement prêt ? Charger est une action merveilleusement évocatrice qu'un ordinateur peut indiquer qu'il fait pour vous. Mais une fois qu'il a terminé, vous devez être sûr que c’est terminé.
Version 2 : Quel est l'objectif ?
En écrivant pour des logiciels, il est important de se demander pourquoi l'utilisateur fait quelque chose. Quel est son but ? Dans ce cas, c'était clair : les gens devaient pouvoir effectuer des présentations de manière fiable sans accès à Internet. « Présenter un prototype hors ligne » ou « Se préparer à une présentation hors ligne » répondent directement au désir des utilisateurs. Mais est-ce que ces phrases utilisent les bons verbes dans les bonnes phrases ?
Le pionnier de l'informatique Terry Winograd écrivait, en 1987: « Les gens agissent à travers le langage. » Quand nous mettons une phrase devant une personne dans un menu, nous établissons leur point de vue. La plupart de ces phrases sont soit des impératifs qu'ils adresseront à un programme, soit des inclinations qui peuvent terminer la phrase « Je veux... » Les mots doivent connecter l'état d'esprit d'une personne aux actions informatiques qui amèneront un résultat. S'il y a un trop grand écart entre la réflexion, les mots, et ce qui va se passer, la rencontre s'effondre.
L'écart entre les deux itérations semblait assez grand. Cliquer sur « Présenter... » sans présenter crée un décalage sévère. Et cliquer sur « Préparer... » sans savoir en quoi consiste cette préparation ou s'il est déjà temps de parler de préparation est trop ambigu. Chacune de ces actions pourrait fonctionner si l'expérience prévue était assez et suivie d'actions granulaires de la part de l'utilisateur. Mais ce n'était pas le cas de notre interface utilisateur : ces deux options avaient des sens trop larges pour une option de menu à activer.
Version trois : Que pouvez-vous contrôler ?
Il y a un moment dans tout texte d'interface où les mots commencent à sembler presque interchangeables. Quelqu'un finit toujours par dire : « Qui va vraiment s'en apercevoir à part nous ? » Mais je crois sincèrement qu'un seul verbe a le pouvoir de créer. Il peut modeler la matière entre vous et l'objet de votre attention. Il met en lumière l'objet d'une rencontre, comme s'il éclairait la lampe qui va vous permettre de travailler.
Alors, quelle phrase guiderait une personne à utiliser Figma comme un assistant ? Nous pourrions essayer un verbe dans le genre de faciliter, pour inviter l'utilisateur à collaborer avec l'ordinateur.
« Faire » est un impératif qui n'est pas trop fort qui offre néanmoins un sentiment d'autorité. Mais, à moins que d'être un capitaine de navire, nous ne passons pas notre temps à dire aux gens de « faire comme ci ou comme ça ». Il s'agit cependant d'un verbe qui influence notre quotidien : nous faisons à manger, nous faisons du bricolage, nous faisons du ménage, bref, nous faisons beaucoup de choses. Peut-être qu'ici le rôle de l'utilisateur est vraiment de demander maintenant à Figma, à l'instant, quelque chose dont il aura besoin plus tard, lors de sa présentation : « Rendre disponible hors ligne. »
Nous étions proches du but, mais ce n'était pas encore suffisant. « Rendre disponible hors ligne » pourrait vous faire penser que quelque chose sera téléchargé sur votre ordinateur pour toujours. Et il y avait quelques membres de l'équipe qui étaient préoccupés que cela soit ambigu pour les gens qui voulaient juste de meilleures performances de prototype, même tout en restant en ligne. Nous avions besoin d'un peu plus de précision.
La version finale : Que se passe-t-il ensuite ?
Les ethnographes de PARC ont placé une photocopieuse Xerox à grande vitesse dans une pièce et ont observé les gens utiliser la machine.
En 1983, une étudiante en anthropologie nommée Lucy Suchman a installé une caméra pour observer des personnes luttant pour utiliser un nouveau photocopieur rapide. Dans une vidéo, deux chercheurs essaient de comprendre ce que la machine sait de ce qu'ils sont en train de faire et pourquoi des événements inattendus se produisent.
Lucy a pris écrit dans ses notes : Il était non seulement essentiel pour les utilisateurs de savoir quoi faire, mais aussi pour la machine informatique de rendre clair ce qu'elle faisait, et pourquoi.
Nous devions nous souvenir qu'il ne suffisait pas d'inciter quelqu'un à cliquer. Nous devions nous assurer qu'ils connaissaient les conséquences de leurs actions. Ainsi, pour la version finale, nous avons ajouté des états d'icône en haut d'un fichier, accompagnés de terme plus explicatifs, reliant la situation technique aux objectifs globaux.
Nous avons utilisé l'idée communément comprise de « téléchargement » pour décrire ce qui se passait lorsque les fichiers étaient transférés du cloud à votre session de navigateur, mais pas sur le stockage de votre appareil. Et une fois tout prêt, nous avons donné un rappel sur ce que vous pouviez enfin faire—présenter hors ligne—avec des marqueurs clairs sur les actions que vous devriez et ne devriez pas prendre si vous souhaitez faire cela à l'avenir—gardez l'onglet ouvert car le fermer effacera le téléchargement.
Simple, vraiment — juste quelques mots, après tout : faire, garder, présenter, fermer, clair. Un ensemble d'actions minuscules tournant les unes autour des autres dans un grand univers Figma.
Merci à tous ceux qui y ont travaillé, notamment Georgia Rust, Connor Skees, Tim Van Damme, Niko Klein, Jackie Chui, Jediah Katz, Stephanie Cheuk, et John Lai.
