bbulman/navigation

Que fait navigation ?

La navigation décide quelles parties de la structure obtiennent une place permanente à l'écran et lesquelles sont accessibles par un autre moyen. Les emplacements sont rares, et chaque surface a sa propre règle pour déterminer ce qui mérite d'en obtenir un.

Ce dont vous avez besoin d'abord

Entrée	D'où ça vient	Si c'est manquant
Chaque surface telle qu'elle est	Dans une base de code, lisez d'abord les routes et les composants de navigation (en-tête, pied de page, sélecteur d'applications, rails latéraux, barres d'onglets). Ne reconcevez jamais à partir de la seule page d'accueil.	Demandez des captures d'écran ou une liste tapée des éléments par surface.
L'arborescence derrière	Un plan de site, ou les routes	Cartographiez l'arborescence actuelle vous-même, et dites-le. Si la structure elle-même est erronée, arrêtez-vous et utilisez sitemaps.
Les tâches principales, celles sur lesquelles les gens échouent, et l'utilisation	L'utilisateur, les analyses, les journaux de recherche, les questions répétées du support	Demandez, ou formulez votre hypothèse en haut. N'estimez jamais l'utilisation ; dites quelles décisions changeraient si vous l'aviez.

Si vous ne pouvez rien obtenir de cela, dites ce dont vous auriez besoin et produisez le modèle vide à partir de references/spec-template.md avec les règles d'entrée remplies.

Méthode

1. Cartographiez chaque surface. Surface, élément, destination, nombre. Signalez la même destination sous deux noms, les éléments qui ne mènent nulle part, et tout ce qui n'existe que dans une surface par accident.

2. Séparez le global du local.

   	Global	Local
   Rôle	Ce que tout ce lieu offre	Ce qui est autour de cette page
   Affiche	La même chose sur chaque page	Uniquement à l'intérieur de sa section
   Surfaces	Primaire, utilitaire, pied de page	Rail latéral, contenu de la page, fils d'Ariane, liens connexes
   Problème quand	Elle liste les enfants d'une section	Elle répète les éléments globaux

   Une section qui a besoin de plus de deux niveaux de navigation a généralement besoin de son propre rail latéral ou de sa propre page d'accueil.

3. Donnez à chaque surface une règle d'entrée, et appliquez-la à chaque élément.

   Surface	Ce qui appartient	Ce qui n'appartient pas	Règle d'entrée
   Primaire	Les 3 à 6 destinations les plus importantes pour les utilisateurs et l'entreprise	Tout ce qui n'a pas gagné sa place	Sert une tâche principale ou un objectif métier énoncé, a du sens pour un nouveau venu, et bat l'élément le plus faible déjà présent
   Utilitaire	Connexion, compte, recherche, langue, paramètres	Éléments classés par marketing	Concerne la session de la personne ou l'outil, pas le contenu
   Pied de page	Le plan de site plus complet, mentions légales, contact, appels à l'action secondaires	Un tiroir à bazar (les personnes et les robots le lisent encore)	Quelqu'un en a besoin depuis n'importe quelle page, ou la loi l'exige ; il s'intègre dans un groupe nommé
   Contextuelle	Rails latéraux, contenu de la page, fils d'Ariane, liens connexes	Tout ce qui est global	N'a de sens qu'ici, et est placé par une règle écrite
   Barre d'onglets de l'application	Au plus 5 onglets ; un 6e devient « Plus » ou est supprimé	Destinations rarement utilisées	Une tâche répétée et de premier niveau dans le produit

4. Allouez. Considérez plus de sept éléments principaux comme un signe que certains ne méritent pas leur place : consolidez-les ou déplacez-les dans le pied de page. Fusionnez les quasi-jumeaux en un seul élément. Donnez à chaque tâche sur laquelle les gens échouent un emplacement canonique unique, et dites que tout autre point d'entrée y mène.

5. Proposez deux ou trois arrangements (par tâche, par objet, par public), chacun avec son coût et ses points de tension. Recommandez-en un et expliquez pourquoi.

6. Choisissez le motif.

   Situation	Utilisez	Remarque
   Un élément a trois sous-groupes ou plus avec leurs propres enfants	Méga-menu	Concevez son focus clavier et sa version mobile comme un travail séparé
   Une liste plate et courte d'enfants	Un menu déroulant simple, ou un lien vers une page hub	Souvent, la page hub est meilleure
   Profondeur de trois niveaux ou plus	Fils d'Ariane	Chaque fil est une vraie page. Un seul fil par page, suivant le chemin canonique, pas le chemin emprunté par la personne.
   Longues pages de référence	Contenu de la page	Local uniquement
   Différents rôles ont besoin de points de départ différents	Raccourcis personnalisés	Personnalisez les raccourcis, pas la carte. Si tout le monde voit un menu différent, les gens ne peuvent pas donner d'indications, le support ne peut pas décrire où se trouvent les choses, et les analyses n'ont plus de sens.

7. Concevez le mobile et le clavier maintenant. Sur mobile, dites comment le menu principal se replie, ce qui reste visible et ce qui arrive à chaque méga-menu. Au clavier, chaque élément est accessible dans l'ordre visuel, le focus est visible, Échap ferme ce qu'Entrée a ouvert, et rien ne fonctionne uniquement par survol. Les détails sont dans references/mobile-and-keyboard.md ; lisez-le pour tout menu qui s'ouvre.

8. Mettez des indices là où la décision se prend. Un bon indice répond à une question que la personne a déjà, au moment où elle choisit, là où elle regarde déjà, discrètement et à moindre coût. La flèche à côté de la jauge de carburant d'une voiture montrant de quel côté se trouve le bouchon est le modèle. Affichez l'emplacement actuel avec un état actif.

9. Planifiez comment les éléments partent. Supprimer un lien n'est pas supprimer une page.

   Étape	Ce qu'il faut faire
   Décidez de son sort	Fusionné, déplacé vers le pied de page ou les utilitaires, accessible uniquement par recherche, ou supprimé
   Si la page disparaît	Ajoutez-la à la carte de redirection
   Si elle reste	Confirmez qu'un autre chemin y mène toujours
   Dites-le aux gens	Dans un produit connecté, laissez un pointeur à l'ancien endroit pendant une ou deux versions, et corrigez les articles d'aide, les visites guidées et les e-mails qui nomment l'ancien chemin
   Gardez le mot	L'ancienne étiquette reste comme synonyme de recherche, puis surveillez la recherche et le support pour celle-ci

10. Confiez la validation à tree-tests. Elle rédige le plan et les tâches. Donnez-lui chaque problème qui a motivé le travail, chaque placement dont vous n'étiez pas sûr et les réponses proposées. Objectifs : au moins 70 % de réussite, 80 % pour les tâches principales, rapport de chemin d'au plus 1,5.

Livrable

navigation-spec.md, dans cet ordre :

1. Recommandation : deux ou trois phrases et la raison principale.
2. État actuel : chaque surface, son nombre, ses problèmes.
3. Options : une ligne par arrangement, avec son coût.
4. Le cahier des charges : par surface, étiquette et destination, et pourquoi chaque élément principal mérite sa place. Puis motif de fil d'Ariane, mobile, clavier et état actif.
5. Emplacements canoniques : chaque tâche problématique, son emplacement unique, et les points d'entrée qui y mènent.
6. Avant et après : chaque élément actuel et où il va, y compris ce qui est retiré et comment.
7. Règle d'entrée : le test qu'un nouvel élément de premier niveau doit réussir.
8. Hypothèses et questions ouvertes.
9. Remise à tree-tests : les tâches problématiques, les placements incertains et les réponses proposées.

Réduisez son échelle. Une refonte de menu a besoin du diagnostic, de la nouvelle arborescence, d'un emplacement pour chaque tâche problématique et de la remise à tree-tests ; elle n'a pas besoin d'un modèle de contenu ni d'une politique d'URL. Un document plus long n'est pas un document plus approfondi. Une demande de placer chaque élément signifie que chaque élément reçoit un emplacement.

Vérifiez-le

Il n'y a pas de script. Ces vérifications sont courtes et nécessitent la lecture du cahier des charges, alors faites-les manuellement et corrigez ce qui échoue :

• Comptez les éléments principaux (7 au maximum, 3 à 6 de préférence) et les onglets (5 au maximum).
• Chaque élément actuel apparaît dans le tableau avant et après avec un nouvel emplacement ou une mise à la retraite déclarée.
• Chaque destination existe dans l'arborescence ou les routes, chaque parent de fil d'Ariane est une vraie page, et le rail latéral, le fil d'Ariane et l'URL racontent la même histoire.
• Chaque tâche problématique a exactement un emplacement et figure dans la remise à tree-tests avec sa réponse proposée.
• Aucune affirmation d'utilisation qui ne vous a pas été donnée. Les mots de fréquence sont marqués comme hypothèses.

Ce que Claude ne peut pas faire ici

• Connaître la stratégie ou la politique de l'organisation sauf si on les lui dit. Quel élément mérite une place est en partie une décision commerciale, alors présentez un projet et dites à qui revient la décision.
• Inventer le trafic, l'utilisation ou la recherche, ou réaliser un test d'arborescence avec de vraies personnes.
• Dire ce que fait le composant de menu d'un framework. Dites ce à quoi vous vous attendez et demandez à l'utilisateur de le confirmer, car ce qu'une plateforme prend en charge varie.

Où cela se transmet

• information-architecture : la porte d'entrée, lorsque le travail couvre plusieurs de ces domaines.
• sitemaps : lorsque l'arborescence sous-jacente doit être modifiée.
• labeling : pour formuler les éléments. taxonomies : lorsque les filtres ou les facettes sont le vrai besoin.
• url-structure et redirect-maps : lorsque les destinations changent d'adresse. content-models : lorsqu'une règle contextuelle a besoin de champs derrière elle.
• tree-tests : pour réaliser l'étude. findability : lorsque le problème est la recherche ou l'odeur. content-inventory et card-sort : lorsque personne ne sait ce qui existe ou comment les gens le regroupent.