L’architecture de l’information d’abord

L’architecture de l’information est le travail le moins photogénique du design produit. Elle ne produit aucun écran, se présente mal en démonstration, et il est presque impossible de la montrer à un décideur d’une façon qui suscite des applaudissements. Alors on la saute, et le travail d’interface commence — c’est-à-dire le moment où le projet devient discrètement plus coûteux.

L’AI consiste à décider ce que sont les choses, comment elles s’appellent et comment elles se relient. L’interface consiste à décider comment ces choses sont montrées. Faire la seconde avant la première revient à dessiner des écrans pour une structure qui n’a pas été arrêtée, et chaque désaccord ultérieur sur la structure invalide des écrans.

À quoi ressemble une dette d’AI vue de l’extérieur

On entend rarement « l’architecture de l’information est mauvaise ». On entend ceci à la place :

• La navigation comporte un « Plus ». Le signal le plus clair qui soit : le modèle a cessé de convenir et, plutôt que d’y revenir, quelqu’un a ajouté un tiroir.
• Deux noms pour une même chose. Le produit dit « projet », la facture dit « dossier », le support dit « compte ». Chacun avait raison localement ; ensemble, ils disent que le concept n’a jamais été fixé.
• Les réglages sont devenus un fourre-tout. Les choses y atterrissent quand personne ne sait à quoi elles appartiennent — une question d’AI sans réponse, déguisée en page.
• La recherche sert de navigation. Quand les gens cherchent des choses qu’ils pourraient en principe atteindre en naviguant, la navigation a échoué.
• Le même objet est accessible par trois chemins sans rapport apparent, si bien que personne ne sait dire où il « se trouve ».
• Les nouvelles fonctionnalités n’ont pas de place évidente. Chaque ajout déclenche une discussion de mise en page, parce qu’aucune règle ne dit ce qui est frère et ce qui est enfant.

En quoi consiste réellement ce travail

Quatre décisions, dont aucune n’exige un outil visuel :

1. 01Nommer. Un mot par concept, pris dans la langue que parlent déjà les personnes concernées plutôt que dans le schéma de la base de données. C’est l’essentiel du travail, et on le traite d’ordinaire comme de la rédaction à faire plus tard.
2. 02Regrouper. Ce qui va avec quoi — selon la façon dont le travail se fait, pas selon l’organisation de l’entreprise. Les produits qui reproduisent l’organigramme sont l’échec classique ici, puisque le client n’a pas votre organigramme.
3. 03Hiérarchiser. Ce qui contient quoi. Savoir si une chose est frère ou enfant est la décision qui détermine toute la navigation, et elle se prend d’ordinaire par accident, dans l’urgence, une seule fois.
4. 04Relier. Ce qui renvoie à quoi sans le contenir. Se tromper là force la duplication : le même objet listé à trois endroits parce que personne n’a su décider où il vit.

Le test qui tranche les discussions

Une question règle la plupart des désaccords d’AI sans en appeler au goût : quelqu’un peut-il prédire où se trouve une chose avant de la chercher ?

Pas la trouver — la prédire. La trouvabilité s’achète avec une recherche et de bons libellés posés sur une mauvaise structure. La prévisibilité ne vient que de l’accord entre la structure et le modèle mental de l’utilisateur ; et quand il existe, l’interface se simplifie presque d’elle-même : moins d’onglets, moins d’infobulles explicatives, moins d’états vides s’excusant de l’endroit où l’on a atterri.

Si les gens trouvent les choses sans pouvoir prédire où elles sont, vous avez un problème de recherche qui en cache un de structure.

Le test est facile à mal mener et précieux mené honnêtement : décrivez une chose en mots simples et demandez où quelqu’un s’attendrait à la trouver, sans lui montrer le produit. Le désaccord entre les réponses est le constat.

Où la décision se voit

L’AI est invisible quand elle est juste, ce qui la rend difficile à montrer. Elle se repère le mieux dans les produits dont le contenu est réellement varié, car c’est là qu’une structure faible ne peut pas se cacher.

Gavroche est un projet client — design UX et UI pour une boutique en ligne — et une boutique est un problème d’AI avant d’être un problème visuel : ce qu’est une catégorie, ce qu’est une déclinaison de produit, et ce que le client est censé avoir décidé avant de pouvoir choisir.

Pluto est un projet concept, mené en interne et non publié. Ses pages montrent des parcours et des décisions d’interface plutôt que des résultats mesurés, ce qui est exactement la limite de ce qu’un concept peut démontrer — le raisonnement sur cette distinction est dans Concept, publié et projet client.

Pourquoi on la saute, et quoi y faire

Parce qu’elle ne produit rien à regarder. Une semaine d’AI se termine par un document et quelques concepts renommés ; une semaine d’interface se termine par des écrans auxquels quelqu’un peut réagir. Sous pression de montrer des avancées, la seconde l’emporte toujours.

La réponse pratique n’est pas de réclamer plus de temps en amont, mais de rendre la structure visible tôt, sous la forme la moins coûteuse disponible : une liste des objets, de leurs noms, et de ce qui contient quoi. Une page. Si l’équipe ne peut pas s’accorder sur cette page, elle n’est pas prête à relire des écrans — et le découvrir coûte un après-midi plutôt qu’un sprint.

Si votre navigation a vu apparaître un « Plus » et que vous vous demandez quoi en faire, dites-nous ce que vous construisez.