Un diagramme est censé faire gagner du temps au lecteur. La plupart de ceux que l’on me remet pour correction font exactement l’inverse : quelqu’un passe vingt minutes à fixer un « simple » organigramme pour essayer de comprendre si une flèche signifie « mène à », « fait rapport à » ou « arrive parfois après ». Le diagramme n’est pas laid. Il demande simplement au lecteur de faire le travail que le designer a négligé.

Cette lacune — entre ce qu’un diagramme paraît terminé et ce qu’il communique réellement — est là où résident la plupart de ces dix erreurs. Aucune d’elles n’est une question de goût. Elles sont structurelles, ce qui est une bonne nouvelle, car les problèmes structurels se corrigent en quelques minutes une fois qu’on sait où chercher.

1. Choisir un type de graphique pour son apparence, pas pour ce qu’il affirme

J’ai vu un calendrier de projet transformé en camembert parce que « le client aime les camemberts ». Un camembert fait une seule affirmation : ces parties forment un tout. Un calendrier fait une affirmation totalement différente : les choses se produisent dans un ordre chronologique, avec une durée. Forcer une forme à faire l’argument de l’autre et le cerveau du lecteur fait la traduction à votre place — mal.

La solution n’est pas « connaître les types de graphiques » comme un principe vague. Elle est plus précise : avant de choisir une forme, écrivez la phrase qui résume ce que le diagramme doit prouver. « X a augmenté tandis que Y a diminué » veut une courbe. « Ces cinq éléments font partie d’une seule chose » veut un camembert ou une barre empilée. « Cela s’est produit, puis cela » veut un calendrier ou un flux. Si vous ne pouvez pas formuler l’affirmation en une phrase, vous n’êtes pas prêt à choisir une forme — c’est là l’erreur réelle, pas le camembert lui-même.

2. Laisser un organigramme accumuler toutes les exceptions

Voici le schéma : un organigramme de processus commence proprement — cinq boîtes, une ligne chacune. Puis quelqu’un en revue dit « mais que faire si le paiement échoue ? », et une branche est ajoutée. Puis « et les commandes internationales ? ». Six mois plus tard, l’organigramme compte onze losanges de décision et personne ne peut retracer le chemin heureux à travers lui.

Chaque ajout était individuellement correct. C’est ce qui rend cette erreur sournoise : aucune modification unique ne l’a rendue pire, mais la somme l’a fait. La solution est de séparer le chemin des 80 % de la norme des exceptions par intention : montrer le flux principal comme la ligne visuelle dominante, et repousser les cas marginaux dans une branche secondaire « exceptions » ou dans un diagramme séparé. Un organigramme qui essaie d’être à la fois complet et lisible finit généralement par ne pas être ni l’un ni l’autre.

3. Utiliser la couleur comme décoration au lieu d’un code

La couleur est la chose que l’œil du lecteur traite le plus rapidement — plus vite que le texte, plus vite que la forme. C’est exactement pourquoi son utilisation aléatoire est une erreur si coûteuse : le cerveau du lecteur suppose que la couleur signifie quelque chose et commence à chercher le motif, même lorsqu’il n’y en a pas.

À mon expérience, le signe révélateur est quand quelqu’un choisit des couleurs à partir de « ce qui a l’air bien ensemble » plutôt que de ce qui doit être distingué. Si trois départements dans un organigramme sont en rouge, bleu et vert sans raison autre que la variété, un lecteur passera quelques secondes à chercher la logique avant d’abandonner. Réservez les changements de couleur pour les vrais changements de catégorie ou d’état — la même couleur signifie toujours la même chose dans tout le diagramme — et laissez le reste dans une palette neutre. Cela peut sembler moins « conçu », mais cela arrête de tromper l’instinct de reconnaissance de motifs du lecteur.

4. Des flèches qui ne s’accordent pas sur ce qu’une flèche signifie

C’est l’erreur derrière presque tous les hybrides organigramme-flux que j’ai corrigés : une flèche montre « fait rapport à », une autre montre « transmet le travail à », et une troisième montre « arrive après ». Elles sont dessinées de manière identique. Le lecteur n’a aucun moyen de les distinguer sauf en devinant à partir du contexte — et deviner est exactement ce qu’un diagramme existe pour éviter.

Une seule convention, une seule signification, pour l’ensemble du diagramme — ligne pleine pour une relation, pointillée pour une autre, et si un diagramme a vraiment besoin de trois types de connexion, il a généralement besoin d’une légende, ou il a besoin d’être deux diagrammes. C’est l’une de ces règles « moins de désordre » que l’on répète partout, mais la version utile n’a rien à voir avec le désordre — elle concerne la sémantique des flèches qui reste constante, ce que la plupart des conseils génériques ne mentionnent jamais explicitement.

5. Essayer de montrer les données et le processus dans la même forme

Un diagramme de processus répond à « qu’est-ce qui arrive, dans quel ordre ». Une visualisation de données répond à « combien, par rapport à quoi ». En entassant les deux dans un seul diagramme — par exemple, un organigramme où la taille des boîtes est proportionnelle au budget — on demande au lecteur de changer de mode mental en cours de lecture, et la plupart des gens ne remarquent même pas qu’ils le font, ce qui est pire qu’un diagramme clairement défectueux.

Si une diapositive a vraiment besoin des deux, c’est généralement un signe qu’elle devrait en être deux : un flux montrant la séquence, et un graphique à côté montrant l’échelle. Diviser les éléments prend plus d’espace sur la diapositive, ce qui est le vrai compromis — ce n’est pas gratuit, et il vaut mieux le nommer plutôt que de prétendre que combiner est toujours la meilleure solution.

6. Oublier le test des huit secondes

Les chercheurs en présentation ont rarement des chiffres vérifiables sur ce comportement spécifique, mais le problème sous-jacent apparaît aussi dans les recherches sur l’alphabétisation visuelle : dans une étude basée sur des sondages sur la façon dont les gens lisent réellement les graphiques, une part notable de répondants ont déclaré ne pas connaître les types de graphiques de base comme les graphiques en courbe et en barre, même s’ils pouvaient techniquement « lire » ceux-ci lorsqu’on les y poussait — ce qui signifie que la familiarité et la compréhension ne sont pas la même chose, et un diagramme qui suppose les deux suppose trop.

C’est là l’argument réel pour tester un diagramme à froid : donnez-le à quelqu’un sans aucun contexte et mesurez le temps qu’il lui faut pour déclarer, sans être guidé, ce qu’il montre. S’il lui faut plus de huit secondes, le diagramme n’est pas terminé — peu importe à quel point il semble poli. Cela peut être inconfortable à faire réellement, ce qui explique probablement pourquoi il est plus souvent ignoré que toute autre correction sur cette liste.

7. Négliger la façon dont l’œil entre réellement dans le diagramme

Les lecteurs ne parcourent pas un diagramme de manière uniforme. Dans la plupart des cultures de lecture de gauche à droite, l’œil se pose d’abord en haut à gauche et dérive selon un motif approximatif en Z ou en F. Un diagramme qui place son élément le plus important en bas à droite, ou qui disperse le point de départ « commencez ici » au milieu, combat le chemin de balayage par défaut du lecteur au lieu de l’utiliser.

Je ne recommanderais pas de redessiner autour des études de suivi oculaire pour chaque diapositive interne — c’est trop pour une mise à jour d’équipe rapide. Mais pour tout ce qui va devant un client ou un conseil d’administration, placez le point d’entrée là où l’œil va déjà, et laissez le reste suivre ce flux. C’est un exercice de repositionnement de cinq minutes, pas une refonte.

8. Recourir aux effets 3D ou à la perspective marquée

Les camemberts 3D et les barres penchées sont encore partout, et la raison d’éviter ceux-ci n’est pas un snobisme esthétique — c’est que la perspective déforme réellement la taille d’une part ou d’une barre. Un camembert 3D rend les segments plus proches du spectateur plus grands qu’ils ne le sont, purement à cause de l’angle, indépendamment des données réelles. Ce n’est pas un choix de style ; c’est une erreur de mesure intégrée à la visualisation.

L’exception à mentionner : le 3D est acceptable, voire utile, quand le diagramme représente réellement quelque chose d’espace ou architectural — une disposition de bâtiment, une vue éclatée d’un produit. L’erreur est d’appliquer spécifiquement le 3D aux données abstraites qui n’ont aucune profondeur physique.

9. Construire un diagramme qui ne fonctionne qu’avec une narration

C’est celui que je vois le plus souvent chez les gens qui présentent souvent en direct : le diagramme comporte trois boîtes non étiquetées et une flèche, et cela a tout à fait du sens — tant que le présentateur se tient là pour l’expliquer à voix haute. Envoyez la même diapositive dans un email de suivi, et elle ne signifie presque rien.

Le test est simple et légèrement ennuyeux à appliquer honnêtement : quelqu’un qui n’était pas dans la pièce pourrait-il comprendre cela à partir du fichier seul ? Si la réponse dépend de votre narration, le diagramme est un accessoire, pas un document — et la plupart des diagrammes finissent par être envoyés, capturés à l’écran ou réutilisés longtemps après que la réunion où vous les avez expliqués se soit terminée.

10. Reconstruire le même diagramme à partir d’une feuille blanche à chaque fois

La dernière erreur n’est pas visuelle du tout — c’est un problème de flux de travail qui cause la plupart des neuf autres. Construire un organigramme, un organigramme hiérarchique ou un diagramme de processus à partir de zéro sous pression de délai est exactement le moment où les conventions de flèches dérapent, où la logique des couleurs est abandonnée en cours de route, et où les effets 3D s’infiltrent parce que le menu d’insertion de graphique par défaut les proposait.

Partir d’un modèle de diagramme structuré pour PowerPoint — ou d’un modèle de diagramme pour Keynote si c’est l’outil que vous utilisez — ne corrige pas une mauvaise réflexion sur ce que le diagramme doit dire, mais il élimine les décisions ad hoc concernant la couleur, le style des flèches et la mise en page qui ont tendance à mal tourner sous pression de temps. Il vaut la peine de comprendre ce qu’un bon modèle inclut réellement avant de supposer qu’une feuille blanche est le choix plus « personnalisé » — souvent, cela signifie simplement refaire les neuf mêmes erreurs, à partir de zéro.

Aucune de ces erreurs n’est difficile à corriger individuellement. Ce qui est difficile, c’est de les remarquer dans son propre travail, car un diagramme que vous avez construit a toujours du sens pour vous — vous savez déjà ce que signifient les flèches. Le vrai test n’a jamais été de savoir si vous le comprenez. Il s’agit de savoir si la onzième personne qui ouvre le fichier, sans réunion ni narration, le comprend en huit secondes aussi.