Algeria AgencyBranding & design
UI/UX : une interface se juge sur une tâche accomplie
Pas sur son aspect. Nommez les cinq choses que les gens viennent faire, regardez cinq personnes les faire, et corrigez ce qui bloque.
Le design d’interface est classé avec le graphisme et il s’en distingue par son critère de réussite : une identité se juge sur ce qu’elle exprime, une interface se juge sur le fait qu’une personne a terminé ce qu’elle était venue faire.
Ce critère a une conséquence désagréable pour les deux parties. Une interface ne peut pas être validée en réunion, sur un grand écran, par des gens qui savent déjà où se trouve chaque bouton. Elle se valide en regardant quelqu’un qui ne sait rien s’en servir sur son propre téléphone.
Cet article traite ce qui décide vraiment ici : la zone que le pouce atteint, la taille des cibles, et deux sujets que les manuels étrangers ne traitent pas parce qu’ils ne les rencontrent pas — une interface qui doit fonctionner en arabe, et le changement de langue comme fonction de premier plan.
Il traite aussi la partie qui casse les projets : les états que personne ne dessine. Un développeur qui reçoit uniquement l’écran où tout se passe bien invente les quatre autres, et c’est là que se logent la moitié des reprises.
Le critère est une tâche accomplie
Une interface ne se juge pas sur ce qu’elle donne à voir mais sur ce qu’elle laisse faire. Le test est binaire et il ne se discute pas : la personne a-t-elle terminé, seule, sans qu’on lui explique ?
Cela disqualifie la validation en réunion. Autour d’une table, tout le monde connaît la structure, sait ce que fait chaque bouton, et regarde un écran de vingt-sept pouces. Aucune de ces trois conditions n’est celle du client.
Cela disqualifie aussi le vocabulaire du goût. « Je n’aime pas ce bleu » n’est pas un retour exploitable ; « je n’ai pas trouvé comment revenir en arrière » en est un. La première phrase ouvre une négociation, la seconde ferme un défaut.
La conséquence de méthode est que le travail commence et finit par une observation. On regarde des gens faire avant de dessiner, puis on regarde des gens faire avec ce qu’on a dessiné. La section 7 décrit comment, parce que la manière de regarder change complètement le résultat.
Et cela fixe ce qu’est un livrable réussi : pas une maquette qui plaît, mais une série de tâches que cinq personnes ont accomplies sans aide. C’est un critère que l’on peut inscrire dans un devis, et nous le faisons.
Les cinq choses que les gens viennent faire
Avant de dessiner quoi que ce soit, il faut écrire la liste des tâches. Pas les rubriques du site — les tâches, formulées comme la personne les dirait : « savoir si vous avez ma taille », « connaître le prix avec la livraison », « retrouver ma commande », « savoir si vous êtes ouverts maintenant », « joindre quelqu’un ».
La liste réelle tient presque toujours en cinq entrées. Au-delà, ce sont des variantes ou des tâches rares, et les traiter au même niveau que les cinq premières est ce qui produit une navigation à onze entrées où plus rien ne ressort.
Ces cinq tâches ne s’inventent pas : elles se relèvent dans les messages entrants, comme le décrit l’article sur le marketing de contenu. C’est le même relevé qui sert à écrire les pages, et c’est normal — les gens demandent ce qu’ils n’ont pas trouvé.
Une fois la liste écrite, elle sert de règle d’arbitrage pour tout le reste. Chaque élément ajouté à un écran doit servir l’une des cinq ; s’il n’en sert aucune, il occupe une place et il en retire à celles qui comptent.
C’est aussi ce qui permet de refuser proprement une demande d’ajout. « Cela ne sert aucune des cinq tâches » est un argument vérifiable, là où « cela alourdit la page » est une opinion contre une autre.
Le pouce, et la main qui tient autre chose
Une interface locale est utilisée d’une main, souvent debout, souvent avec l’autre main occupée par un sac, un enfant ou une clé de voiture. Ce n’est pas une image : c’est la contrainte principale de mise en page.
Une main tenant un téléphone atteint confortablement la moitié basse de l’écran et le bord opposé au pouce très mal. Les actions fréquentes se placent donc en bas, et le haut de l’écran est réservé à ce qui s’affiche plutôt qu’à ce qui se touche.
La conséquence la plus fréquemment violée : le bouton principal d’une page longue ne doit pas être en haut. Il doit être là où le pouce est quand la personne a fini de lire, c’est-à-dire en bas, et se répéter si la page est longue — l’article sur les pages d’atterrissage dit la même chose pour son propre cas.
Deuxième conséquence, propre aux téléphones que nous voyons réellement : les appareils sont grands et beaucoup portent une coque épaisse. Cela réduit la zone atteignable et augmente les touchers imprécis, ce qui se paie sur les cibles trop petites ou trop proches.
Et une contrainte que les maquettes cachent systématiquement : l’écran réel est amputé par le clavier dès qu’un champ est actif. La moitié basse disparaît, et c’est exactement la moitié où l’on avait mis le bouton. Ce cas se dessine, il ne se découvre pas.
La taille d’une cible
La taille des zones touchables est le seul point de cette page pour lequel il existe un seuil publié et vérifiable, et il vaut la peine d’être connu parce qu’il est très souvent manqué.
Les recommandations d’accessibilité du consortium web fixent deux repères. Un minimum, introduit dans la version la plus récente : vingt-quatre pixels de côté. Et un seuil renforcé, plus ancien : quarante-quatre pixels de côté.
La lecture utile n’est pas réglementaire mais pratique. Vingt-quatre pixels correspondent à peu près à ce qu’un doigt touche sans effort de visée ; quarante-quatre correspondent à ce qu’un doigt touche en marchant, avec une coque, sans regarder attentivement.
Ce qui échoue dans les interfaces que nous auditons n’est presque jamais le bouton principal : ce sont les petites cibles. La croix qui ferme une fenêtre, la case à cocher des conditions, les flèches d’un carrousel, le sélecteur de quantité, le lien de désabonnement.
Un point qui compte autant que la taille et qui n’a pas de seuil : l’espacement. Deux cibles correctes collées l’une à l’autre produisent des erreurs de sélection, et l’erreur la plus coûteuse que nous ayons vue était un bouton « supprimer » à trois pixels d’un bouton « valider ».
Recommandations W3C sur l’accessibilité des contenus web, versions 2.2 (2023) et 2.1 (2018)
L’arabe n’est pas le français retourné
Une interface qui doit fonctionner en arabe n’est pas la version française passée dans un miroir. C’est le sujet que les manuels importés ne traitent pas, et c’est celui où nous voyons le plus d’erreurs coûteuses.
Ce qui s’inverse : le sens de lecture, donc l’alignement des textes, la position des libellés par rapport aux champs, l’ordre des colonnes d’un tableau, le sens d’une progression et la place du bouton de retour. Tout cela suit la direction et doit suivre automatiquement.
Ce qui ne s’inverse pas : les chiffres, les montants, les numéros de téléphone, les heures, les références de produits. Ils se lisent de gauche à droite à l’intérieur d’une phrase qui va de droite à gauche, et les traiter comme du texte ordinaire produit des montants illisibles et des références fausses. Le piège se déplace quand le texte arabe est produit par une machine plutôt que rédigé, et huit endroits de l’interface cassent alors sans que le texte soit fautif.
Les icônes demandent une décision plutôt qu’une transformation. Une flèche de progression se retourne ; une horloge, un logo, une icône de téléphone ne se retournent pas. Retourner l’ensemble par réflexe produit des symboles absurdes que personne ne relève avant la mise en ligne.
Enfin, la longueur change. Le même message est souvent plus court en arabe qu’en français, parfois nettement, et une mise en page calée au pixel sur la version française laisse des blocs vides ou des boutons déséquilibrés. La maquette doit être vérifiée dans les deux directions, pas traduite après coup.
Le changement de langue n’est pas un drapeau en bas de page
Sur un site trilingue, choisir sa langue est l’une des cinq tâches de la section 1, et elle est presque toujours traitée comme un détail de pied de page. C’est une erreur de hiérarchie plutôt qu’une erreur de goût.
Le sélecteur doit être visible sans défiler, sur toutes les pages, et il doit conserver la page où l’on se trouve. Renvoyer vers l’accueil au changement de langue est le comportement le plus fréquent et le plus irritant : la personne perd ce qu’elle lisait et recommence.
Les drapeaux sont à éviter, pour une raison simple et rarement dite : un drapeau désigne un pays et non une langue. Écrivez les langues dans leur propre écriture, ce qui règle aussi le problème de la personne qui ne lit pas celle actuellement affichée.
La langue choisie doit être mémorisée, et le choix doit rester modifiable. Une détection automatique qui impose une langue sans laisser en changer est le pire des deux mondes, et elle se trompe souvent sur les appareils configurés dans une langue que la personne ne lit pas confortablement.
Un dernier point qui relève de la marque autant que de l’interface : les trois versions doivent contenir la même information. Une version arabe amputée de la moitié des pages est une décision commerciale déguisée en contrainte technique, et les clients la lisent comme telle.
Les états que personne ne dessine
Une maquette classique montre un écran plein, avec de belles données, dans le cas où tout fonctionne. C’est un cinquième du travail, et les quatre autres cinquièmes sont ceux qui décident de la qualité perçue.
L’état vide : la première fois, il n’y a rien. Pas de commande, pas de favori, pas d’historique. Un écran vide non dessiné devient un écran blanc, et l’utilisateur croit que cela ne marche pas alors qu’il n’a simplement rien encore.
L’état de chargement : sur une connexion mobile, il dure. Il doit montrer que quelque chose se passe et, mieux, à quel endroit. Un écran figé pendant quatre secondes produit un deuxième appui, donc parfois une deuxième commande.
L’état d’erreur : il doit dire ce qui s’est passé et quoi faire, dans la langue de la personne. « Une erreur est survenue » ne remplit aucune des deux conditions. « Le numéro doit commencer par 0 » les remplit toutes les deux.
Et l’état partiel, que presque personne ne prévoit : la liste qui charge à moitié, la photo qui manque, le prix indisponible. C’est le cas le plus fréquent sur une connexion moyenne, et une interface qui ne l’a pas prévu affiche des trous là où le développeur avait supposé des données.
Regarder cinq personnes : la méthode
L’article sur les tests comparatifs renvoie ici : quand le trafic ne permet pas de mesurer, on regarde. Cinq personnes suffisent à trouver la majorité des défauts majeurs, et la manière de regarder décide de ce que l’on trouve.
Le protocole tient en quatre règles. On donne une tâche, pas une explication : « trouvez le prix de ce modèle livré à Blida ». On ne dit rien pendant. On note ce que la personne fait, pas ce qu’elle dit. Et on ne défend jamais l’interface, même quand on a envie.
Le silence est la partie difficile. Dès qu’on aide, on obtient une conversation agréable et aucune information : la personne finit la tâche grâce à vous, et le défaut reste. Comptez jusqu’à dix avant d’intervenir, et n’intervenez que si elle veut arrêter.
Ce qu’il faut noter est court : à quel écran elle hésite, ce qu’elle touche qui n’est pas cliquable, ce qu’elle cherche et ne trouve pas, et si elle termine. Quatre colonnes, cinq lignes, une feuille.
Le choix des personnes compte moins qu’on ne le croit — il faut qu’elles ressemblent à vos clients et qu’elles ne connaissent pas le produit. Vos employés ne conviennent pas : ils savent où sont les choses, et c’est précisément ce qui est testé.
L’interface que personne ne conçoit : celle de vos employés
Le budget de conception va au site public, et l’écran que quelqu’un utilise deux cents fois par jour n’en reçoit rien. C’est un mauvais partage arithmétique, et il coûte des heures tous les jours.
Les interfaces internes ont une propriété qui change tout : l’utilisateur est expert et répétitif. Il ne cherche pas, il connaît. Ce qui compte n’est donc pas la découvrabilité mais le nombre de gestes, la position stable des éléments, et les raccourcis.
Les gains les plus fréquents que nous constatons sont grossiers. Un champ qui n’est pas au bon endroit dans l’ordre de saisie, une confirmation inutile à chaque enregistrement, un formulaire qui perd le contexte à chaque validation, une recherche qui ne cherche pas sur la référence.
La méthode est la même que pour le public, avec un avantage : les personnes sont disponibles et elles connaissent déjà les défauts. Une matinée passée à côté de deux employés produit une liste de corrections dont chacune fait gagner quelques secondes multipliées par des centaines.
C’est aussi le seul endroit de cet article où le calcul de retour est simple à faire : trois secondes gagnées sur une opération répétée cent fois par jour font une heure par semaine et par personne. Aucun écran public ne se justifie aussi facilement.
Ce qui existe déjà dans le téléphone de vos clients
La meilleure interface est celle que l’utilisateur connaît déjà. C’est une phrase de manuel, et elle a une portée concrète : les gestes, les icônes et les positions installés par le système d’exploitation et par les grandes applications sont des acquis gratuits.
Le retour se fait par un geste ou par une flèche en haut à gauche — en haut à droite en arabe. La croix ferme, la loupe cherche, les trois points ouvrent un menu secondaire. Réinventer l’un de ces signes ne produit pas de l’originalité, cela produit un apprentissage à la charge du client.
La règle qui en découle : on invente là où le métier est particulier, et nulle part ailleurs. Une clinique, un atelier ou un transporteur ont des besoins propres qui méritent des écrans propres ; ils n’ont pas besoin d’un bouton de fermeture original.
Il y a une exception locale utile : les habitudes installées par les applications de messagerie, qui sont ce que la plupart des gens utilisent le plus. Un fil, une pièce jointe, un bouton d’envoi à droite — ces conventions-là sont plus familières à vos clients que celles d’un logiciel de gestion.
Et une conséquence de conception : quand vous hésitez entre deux façons de présenter une chose, regardez comment elle est présentée dans l’application que vos clients ouvrent vingt fois par jour. Ce n’est pas de la copie, c’est de l’économie d’apprentissage.
Ce qu’un développeur doit recevoir
La qualité d’une interface se perd le plus souvent à la remise, pas à la conception. Un développeur qui reçoit trois images et une palette prend des dizaines de décisions à votre place, et il les prend seul et vite.
Ce qui doit être remis, au minimum : les cinq écrans principaux dans les trois langues, avec les quatre états de la section 6 pour chacun. C’est la partie qui triple le volume du livrable et qui divise par deux le nombre de reprises.
Ensuite les règles plutôt que les pixels : quelle taille de texte, quel espacement entre les blocs, quelle largeur de contenu maximale, quels comportements aux ruptures de largeur. Un développeur applique une règle à cinquante écrans ; il ne peut pas déduire une règle de trois images.
Ensuite les cas limites, écrits : le nom très long, le prix à six chiffres, la liste à un seul élément, le texte arabe plus court que prévu, l’image manquante. Ces cinq cas révèlent la moitié des défauts de mise en page avant qu’ils soient construits.
Et enfin la liste des tâches de la section 1, remise telle quelle. C’est ce qui permet à un développeur de trancher quand la maquette ne prévoit pas un cas : il choisit la solution qui sert la tâche, ce qui est presque toujours la bonne.
Ce que nous faisons, et ce que nous refuserons de faire
Ce que nous refuserons : livrer des écrans sans leurs états vide, chargement, erreur et partiel. C’est la moitié du travail réel, elle est invisible dans une présentation, et son absence est ce qui produit les reprises que le client paie ensuite.
Nous refuserons de valider une interface en réunion sans qu’une seule personne extérieure l’ait essayée. Une validation collective autour d’un grand écran mesure le consensus, pas l’usage, et les deux sont sans rapport.
Nous refuserons de livrer une version arabe obtenue en retournant la version française, et de retourner les icônes par réflexe. Les chiffres, les montants et les références restent dans leur sens ; une horloge ne se retourne pas.
Ce que nous faisons : la liste des cinq tâches écrite depuis vos messages entrants ; les zones atteignables et les tailles de cibles vérifiées sur un téléphone réel avec une coque ; les trois langues dessinées et non traduites ; les quatre états pour chaque écran ; la séance d’observation à cinq personnes avant et après ; et la remise des règles plutôt que des images.
Et ce que vous pouvez faire cette semaine sans nous : demandez à deux personnes qui ne connaissent pas votre site de trouver le prix d’un produit livré chez elles, sur leur téléphone, sans rien dire pendant qu’elles cherchent. Notez à quel écran elles hésitent. Une demi-heure, deux personnes, et vous aurez plus d’informations que dans n’importe quelle réunion de validation.
Questions fréquentes
Comment savoir si notre interface est bonne ?
Écrivez les cinq choses que les gens viennent faire, puis regardez cinq personnes les faire sur leur propre téléphone sans les aider. Le critère est binaire : la tâche est terminée sans explication, ou elle ne l’est pas.
Quelle taille doivent faire les boutons ?
Vingt-quatre pixels de côté au minimum et quarante-quatre pour un usage confortable, selon les recommandations d’accessibilité du consortium web. Ce qui échoue n’est presque jamais le bouton principal, ce sont les croix de fermeture, les cases à cocher et les flèches.
Peut-on obtenir la version arabe en retournant la version française ?
Non. Le sens de lecture s’inverse, mais pas les chiffres, les montants ni les références, et les icônes demandent une décision : une flèche se retourne, une horloge non. La longueur du texte change aussi, souvent nettement.
Où mettre le sélecteur de langue ?
Visible sans défiler, sur toutes les pages, en conservant la page où l’on se trouve. Écrivez les langues dans leur propre écriture plutôt que des drapeaux — un drapeau désigne un pays, pas une langue.
Que doit contenir une maquette remise à un développeur ?
Les écrans dans les trois langues avec leurs états vide, chargement, erreur et partiel ; les règles d’espacement et de taille plutôt que des pixels ; cinq cas limites écrits ; et la liste des cinq tâches, qui permet de trancher ce que la maquette n’a pas prévu.
Faut-il aussi concevoir les écrans internes ?
C’est souvent le meilleur retour disponible. Trois secondes gagnées sur une opération répétée cent fois par jour font une heure par semaine et par personne, et une matinée passée à côté de deux employés suffit à établir la liste.
Où nous intervenons
Deux personnes qui hésitent vous montrent un écran. Elles ne vous disent pas si c’est la structure, la lenteur ou une version arabe retournée qui les a arrêtées.
- Nous rejouons le parcours sur un téléphone d’entrée de gamme, en réseau mobile.
- Nous mesurons au pouce ce qui est réellement atteignable, écran par écran.
- Nous rendons les blocages classés par ce qu’ils coûtent à corriger.
Si vos deux témoins ont trouvé le prix sans hésiter, l’interface n’est pas votre sujet : le problème est plus haut, dans ce qui les amène.
À lire ensuite
Une IA qui écrit en arabe : ce qui casse dans votre interface
Le texte arabe produit par un modèle est correct et votre écran ne l’est plus. Voici les huit endroits où il casse, et le contrôle qui les trouve en une heure.Réparer une interface sans la refaire : par où commencer
La refonte est la réponse la plus chère et rarement la bonne. Comment trouver la couche où se trouve réellement le défaut, et corriger là.L’identité visuelle d’une PME : ce qui sert et ce qui décore
Un logo n’est pas une identité. Ce qui manque presque toujours, c’est ce qu’on fait le lendemain de sa livraison.
Parlons de votre projet
Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.