Comment abordez-vous l'architecture de l'information pour un produit avec beaucoup de fonctionnalités ?

Fondez la structure sur la façon dont les utilisateurs regroupent les choses, pas sur l'organigramme de l'entreprise. Inventoriez l'existant, puis faites du tri de cartes ou du tree testing pour trouver le modèle mental des utilisateurs, et validez avec du test de premier clic sur de vrais libellés. Préférez des libellés clairs aux libellés astucieux, gardez la navigation peu profonde quand vous le pouvez, et prévoyez une transition quand vous changez une structure que les gens connaissent déjà.

Je commence par un inventaire, qui est fastidieux et révèle toujours quelque chose. Sur un produit B2B, on a trouvé quarante et une destinations dans une navigation qui se présentait comme en ayant neuf, parce que des fonctionnalités avaient été rangées dans les réglages pendant des années. Ensuite je vais chercher le modèle des utilisateurs plutôt que d'affirmer le mien. Un tri de cartes ouvert avec quinze personnes me dit ce qui va ensemble et, plus utile encore, quels mots ils emploient. Les équipes adorent leur vocabulaire interne et les utilisateurs ne l'ont pas. Ensuite je construis une arborescence et je la teste avant de dessiner le moindre écran. Le tree testing est la recherche à plus fort rendement pour le moins cher : pas de visuel, juste sauriez-vous trouver où aller pour faire ceci. Si une tâche est trouvable à moins de 60%, la structure est mauvaise et aucun design visuel ne la sauvera. La partie qu'on sous-estime, c'est la transition. Si vous réorganisez un produit utilisé quotidiennement, vous avez cassé la mémoire musculaire des gens, donc je prévois des redirections, une courte explication dans le produit, et une recherche qui comprend encore les anciens noms.