Architecture de l'information, architecture de contenu et systèmes d'interface

La plupart des échecs d’utilisabilité sur les sites de documentation technique ne sont pas des bugs d’interface utilisateur. Ce sont des échecs structurels.

Les utilisateurs arrivent avec un problème spécifique, recherchent un terme, atterrissent sur une page et perdent immédiatement leurs repères. Ils ne peuvent pas dire si le document qu’ils lisent est une vue d’ensemble de haut niveau, un tutoriel approfondi ou une référence d’API. Ils ne peuvent pas prédire où se trouvent les informations connexes. Le site est magnifique, mais les connaissances sont structurellement incohérentes.

Cela se produit lorsqu’une équipe conçoit une interface avant de concevoir l’Architecture de l’information (IA) et l’architecture de contenu.

Les systèmes qui lient les connaissances

Pour construire une publication qui enseigne réellement, vous devez séparer la structure de vos connaissances de la présentation de vos connaissances.

Architecture de l’information : Comment le contenu est catégorisé, étiqueté et cartographié afin que les utilisateurs puissent le trouver. C’est le modèle mental de l’espace.
Architecture de contenu : Comment le contenu est modélisé dans le système (schémas, champs, relations) afin de pouvoir être géré et récupéré de manière prévisible.
Systèmes d’interface : La mise en page, la typographie et les composants interactifs qui rendent le contenu structuré pour l’utilisateur.

Lorsque ces trois couches sont confondues, les publications dégénèrent en blobs non navigables.

Le mode d’échec le plus courant dans l’édition technique consiste à confondre Taxonomie avec Navigation.

La Taxonomie est la catégorisation en coulisses de toutes vos connaissances. Elle est exhaustive. Elle définit comment les concepts se lient les uns aux autres (ex : « React » est un sous-thème de « Frameworks Frontend »).

La Navigation est l’interface destinée à l’utilisateur pour se déplacer sur le site. Elle est organisée. Elle expose des chemins spécifiques à travers la taxonomie en fonction de ce que les utilisateurs ont réellement besoin de faire.

Si vous faites de votre navigation une réplique exacte 1:1 de votre taxonomie, vous forcez l’utilisateur à comprendre l’ensemble de votre modèle organisationnel juste pour cliquer sur un lien.

graph LR
    subgraph Structure Faible : Navigation = Taxonomie
        N1[Menu: Frontend] --> N2[Menu: Frameworks]
        N2 --> N3[Menu: React]
        N3 --> N4[Menu: Hooks]
    end

    subgraph Structure Solide : Découplée
        T1[Base de Taxonomie] -->|Requêtes| H1(Hub: React)
        T1 -->|Requêtes| S1(Index de Recherche)
        
        Nav[Nav Globale] -->|Lien Choisi| H1
        Nav -->|Lien Choisi| G1(Guides)
    end

Le modèle directeur : le graphe de contenu

Une publication technique moderne n’est pas une hiérarchie de dossiers. C’est un graphe de relations.

Dans Interface Atlas, nous modélisons les connaissances à travers quatre primitives distinctes. En les séparant, nous leur permettons de se lier en un réseau sémantique.

Guides : La couche d’enseignement longue. Ils portent une thèse et expliquent comment et pourquoi.
Hubs de sujets : La couche de synthèse. Ce ne sont pas de simples listes de liens ; ils organisent les guides et fournissent le paysage d’un vaste sujet.
Glossaire : La couche de définition. Explications courtes et précises de termes spécifiques, permettant aux guides de créer des liens externes au lieu d’alourdir leur propre nombre de mots.
Blog : La couche chronologique. Mises à jour, actualités et pensées opportunes qui n’appartiennent pas au canon durable.

Un exemple travaillé

Imaginez un lecteur essayant de comprendre « l’hydratation ».

Dans une structure faible (plate) : Il trouve une page massive de 5 000 mots intitulée « Performances React ». La moitié de la page est une référence d’API, un quart est un tutoriel, et la définition de l’hydratation est enfouie dans le paragraphe 14. S’il recherche « hydratation », il est simplement déposé en haut de cette page massive.

Dans une structure solide (graphe) :

Il recherche « Hydratation » et atterrit directement sur l’entrée Glossaire : Hydratation.
L’entrée du glossaire lui donne une définition de 100 mots et, sous « Guides connexes », un lien vers le Guide : Les performances Web en tant qu'architecture.
Il lit le guide. Le guide renvoie au Hub de sujet : Performances pour en savoir plus.
Il explore le hub thématique pour découvrir des concepts liés comme la résumabilité.

Le modèle de contenu impose le chemin d’apprentissage.

Modes d’échec à éviter

L’IA de l’organigramme : Structurer la documentation en fonction de l’équipe interne qui l’a écrite, plutôt que de ce que l’utilisateur essaie d’accomplir.
Contenu plat, pas de modèle : Tout jeter dans un type de CMS générique « Page » avec un seul champ de corps WYSIWYG. Cela vous empêche de relier par programmation les guides aux termes du glossaire.
L’interface d’abord : Concevoir une belle barre latérale avant de décider quels types de contenu ont réellement besoin d’être navigués.

Appliquer cela à Interface Atlas

Nous imposons cette architecture à travers la structure de notre référentiel :

Schémas explicites : Nos collections de contenu dictent qu’un guide doit avoir des topicKeys et glossaryKeys.
Hubs éditoriaux : Nous ne générons pas automatiquement les pages de sujets comme de simples listes de balises. Les sujets sont des fichiers créés par des auteurs qui synthétisent les guides qui s’y rattachent.
Liens omniprésents : Un guide sans liens vers le glossaire ou les hubs de sujets est un nœud orphelin. Le réseau ne fonctionne que lorsque les auteurs relient explicitement les bords.

Guides et termes associés

Poursuivez votre exploration :

MDX, collections de contenu et le contenu en tant qu’architecture — Comment nous implémentons cette structure.
Ce qu’est vraiment l’architecture frontend — Comment l’IA s’intègre.
L’anatomie d’un excellent guide technique — Comment la structure du guide reflète l’architecture de contenu.