#28 L’architecture d’informations, pour une interface utilisable | Gladys Diandoki

⇒ Écouter l’épisode

Échanges avec Gladys Diandoki autour de l'architecture d'informations

Pour ce nouvel épisode de podcast, j’ai le plaisir d’échanger de nouveau avec Gladys Diandoki. 

Gladys, vous l’aviez entendue en décembre 2020 lors de l’épisode 14 sur le design inclusif. Si vous ne l’avez pas encore écouté, c’est le moment de rattraper votre retard ! 🙂

Gladys est un peu comme une mentore pour moi.
Elle m’apprend énormément de choses sur le Content design, et elle m’oriente vers de très bonnes ressources. D’ailleurs, ma liste de livres à lire devient longue comme le bras ! 

Mais surtout, elle me fait prendre du recul et remettre en perspective mon métier d’UX writer et mes méthodologies.

Depuis le dernier épisode, Gladys s’est lancée à son compte, en tant que Content designer & Conversation designer freelance.
Et, en 2021, elle s’est lancé le défi d’écrire un livre – LE premier livre français – sur le content design et l’UX writing. La sortie est prévue en fin d’année. Bien sûr, comptez sur moi pour vous en parler.

En attendant, revenons à l’épisode du jour : avec Gladys, on parle d’architecture d’informations. C’est un sujet dont on ne parle finalement que très peu, alors qu’il s’agit pourtant de la base pour concevoir une interface et initier une expérience utilisateur. 

L’architecture d’informations, c’est prendre le temps à la fois de :

  • Réfléchir au parcours sur un site ou une application
  • Construire une navigation fluide et performante
  • Imaginer la place des contenus dans les pages ou écrans d’une interface.

Tout part – et doit partir – de l’architecture d’informations.

Bonne écoute / lecture ! 

 

 

Quelques mots expliqués pour éclairer votre lanterne

  • Conversation designer : ce type de designer conçoit des interfaces vocales. Parfois ce terme est utilisé par les designers pour préciser qu’ils ou elles conçoivent des interfaces conversationnelles, qui s’inspirent des interactions humaines de la « vraie » vie.
  • Business Unit : une entité de l’entreprise qui est autonome pour définir sa stratégie, ses objectifs et les ressources pour les atteindre.
  • Design Thinkingméthodologie transversale pour transformer une idée en action et en prototype, pour répondre à un besoin ou une problématique identifée.
  • Stress cases : les cas de stress causés par l’utilisation d’une interface web ou mobile ; il est nécessaire de les identifier pour les solutionner et concevoir avec compassion.
  • Tri de cartes : une méthode concrète et ludique pour définir une architecture d’information avec les utilisateurs et utilisatrices, à base de cartes à nommer et classer en catégories.

 

Les ressources de l’épisode de podcast

Échanges avec Gladys Diandoki : l’architecture d’informations

Salut Gladys, je suis ravie de t’accueillir de nouveau sur le podcast. La première fois, nous avions échangé sur le design inclusif. C’était en décembre 2020. Cela va bientôt faire un an. D’ailleurs, tout le monde nous rappelle que les fêtes de fin d’année approchent. Je ne sais pas pourquoi, mais j’ai l’impression que c’est toujours de plus en plus tôt ! (Rires)
Alors, j’invite toutes celles et ceux qui nous écoutent aujourd’hui, à aller écouter l’épisode de l’an dernier sur le design inclusif, qui est très instructif.

Depuis le précédent épisode, ton activité professionnelle a beaucoup évolué. Tu étais salariée et maintenant, tu es indépendante, en tant que Content designer et Conversation designer. Tu es aussi l’auteure d’un livre, qui va bientôt sortir, autour du Content design et de l’UX writing. J’ai hâte de le découvrir ! Mais, si tu le veux bien, on va en reparler à la fin de nos échanges.

Est-ce que l’on peut commencer par ce que tu fais, à l’heure actuelle ? Peux-tu nous en dire plus sur ton métier ?

Effectivement, depuis quelques mois, je suis revenue à mon compte, puisque j’avais envie d’explorer d’autres sujets, d’avoir différents clients et de me challenger. J’avais besoin d’un peu moins de routine et de tester d’autres choses.
En ce moment, je suis encore en mission pour
beta.gouv, c’est plutôt cool. Je fais partie d’une équipe transverse de designers et j’ai la chance de travailler sur différentes problématiques. Parfois, je travaille sur des projets de A à Z. Parfois, je fais du conseil sur des sujets plus spécifiques.
Je travaille aussi pour des startups, comme Ornikar ou d’autres. Ça me plaît : j’ai pu, en quelques mois, voir différentes choses, et ce, grâce au freelancing.

Top !
Aujourd’hui, on va échanger sur l’architecture d’information. C’est un sujet dont on parle très peu et qui est pourtant primordial quand on veut créer une interface. Pour toi, ça veut dire quoi, justement, « architecture d’information » ? J’ai l’impression qu’on peut mettre tout et rien à la fois derrière ce terme… Qu’est-ce qu’on y regroupe ?

Pour l’expliquer, décomposons le terme : architecture et information. D’une part, on a des informations, et d’ailleurs il y en a de plus en plus. Certains sites ou applications doivent en gérer énormément. Donc la question, ça va être : comment on les organise ?
Ça a l’air très simple comme question, mais en fait, c’est un peu plus subtil que ça…  Et puis, il y a différents niveaux.

En effet, une architecture d’information se situe à différents niveaux. Il y a, d’une part, la structure du site et la navigation, la partie à laquelle on pense le plus souvent. D’autre part, on travaille aussi la hiérarchie de l’information pour séquencer le parcours et définir la narration du parcours… J’aime beaucoup parler de narration et de storytelling, car c’est mon domaine, ma zone de confort.

Par exemple, je séquence mon parcours en me demandant : qu’est-ce qui arrive au début ? Qu’est-ce qui est au milieu ? Qu’est-ce qui arrive à la fin ? Etc.
Au fil du parcours, on va aussi voir comment organiser les informations sur chaque page. Il va y avoir de la sémantique, énormément d’informations et énormément de choses auxquelles on doit penser pour essayer de créer la structure la plus simple possible.

Quand on travaille sur l’amélioration d’un service complet ou que l’on va complètement designer un service qui n’existe pas encore, les enjeux sont stratégiques et beaucoup plus complexes. Il y a alors beaucoup de choses à prendre en compte.

Ok. Et finalement, l’architecture d’information, dans quels cas l’applique-t-on ? On parlait à l’instant d’interfaces de sites web ou d’appli mobiles. Y a-t-il d’autres produits auxquels je n’ai pas pensé ?

Oui ! Prenons un exemple simple : la manière dont tu organises tes livres dans ta bibliothèque. Elle peut être très personnelle. Certains vont classer par couleur, d’autres par genre, par auteur, etc.

Ce que je veux dire, c’est que les informations sont partout, et toutes ces informations, elles disent quelque chose de nous, d’une certaine façon. On va retrouver des informations au niveau du site, d’une app, d’un chatbot, d’une bibliothèque…

Quand tu arrives dans une entreprise, tu peux voir que la manière dont les choses sont organisées en dit beaucoup sur cette structure.

Prenons un autre exemple. Quand tu vas au supermarché, tout est organisé depuis ton entrée jusqu’à la sortie. C’est de la hiérarchie d’information aussi. L’entrée, c’est l’équivalent de l’introduction, en tout cas, c’est pensé comme un élément narratif. Pourquoi, quand tu arrives près de la caisse, on te met des bonbons et plein de trucs pour essayer encore te faire craquer ? Ça fait partie de la narration, comme si le parcours du client était une histoire.

Et c’est justement des expériences et des parcours qui sont créés par des gens dont c’est le métier.

C’est hyper intéressant, ce parallèle. Pourquoi est-ce si important de se consacrer à l’architecture d’information, en amont de la création ?

Prenons un parcours pour exemple. Parfois, les écrans sont déjà faits, mais je trouve que ce n’est pas la meilleure manière de bosser. Il faut re-challenger beaucoup de choses, c’est compliqué…
Parfois, on a la chance d’arriver au début du projet et on va pouvoir co-concevoir les écrans avec les designers. On va pouvoir se poser la question, qui je pense est la plus importante : le sens. On va se mettre à la place de l’utilisateur, se demander ce qu’il veut. C’est le B.A-BA. Une fois que l’on a la réponse, qu’est-ce qu’on veut lui dire ? 

Pour moi, il faut remettre avant tout du sens, plutôt que de se précipiter sur les écrans, où mettre les boutons, etc. On va commencer par se demander « pourquoi, quel est l’objectif ? ». Puis « quel est le début de l’histoire ? Le milieu de l’histoire ? La fin de l’histoire ? Quels sont les temps forts de ce parcours ? ».
Partant de là, on peut écrire l’histoire. Il existe des techniques, comme une qui s’appelle « la conversation ». En gros, on fait comme un jeu de rôle, comme un échange de SMS. Ainsi, on raconte les choses de la manière la plus logique possible. Puis, on construit le parcours autour de cette conversation. 

Si tu ne te demandes pas quel est le but, tu peux te retrouver avec des parcours où on dit tout de suite « Qu’est-ce que tu veux ? », alors même qu’on n’a pas dit ce qu’on pouvait proposer ! Là, il y a un problème dans la hiérarchie de l’information.

La hiérarchie de l’information, que j’appelle aussi la narration de ton parcours, c’est une manière de remettre de la logique dans ton parcours et de le structurer. Ça va aussi te permettre, quand tu vas travailler d’autres parcours, de reprendre ce qui peut être repris et aussi de le modifier à des moments où tu ne peux pas faire exactement le même parcours, pour x raisons. Tu sais exactement pourquoi et où tu le modifies. Tu sauras pourquoi tu mets telle ou telle information, à tel moment du parcours. 

Ensuite, il y a la logique sémantique. Qu’est-ce que je dis, comment je le dis, pourquoi je le dis comme cela. Ça doit répondre à la logique de ton site.

En effet, cela m’a fait penser à la conversation. Je trouve ça hyper intéressant. J’avais lu ça dans un livre, je ne me rappelle plus lequel. On est dans une espèce de jeu de rôle. On va poser une question et on va imaginer comment l’interface répond à la question. En partant de vrais dialogues, cela permet clairement de construire l’architecture.

C’est un outil que l’on peut utiliser assez facilement, car on rentre dans des flows assez naturels, on peut reprendre des éléments qui ont toute leur logique dans le parcours.
Il y a une analogie que j’aime bien : j’avais assisté à une masterclass de Shonda Rhimes (celle qui a fait Grey’s Anatomy) dans laquelle elle expliquait comment elle faisait des séries. Et j’ai dit « wow ! » En fait, c’est comme un parcours. Quand elle explique comment elle a écrit le pilote de Grey’s Anatomy, elle a tout rédigé. Il fallait comprendre les personnages, comprendre la structure, etc. C’est comme quand tu travailles la navigation ou la hiérarchie de ton service, c’est le moment où tu vas de poser toutes ces questions. Ensuite, tous les épisodes suivants doivent suivre la logique de ton pilote, bien que chacun soit indépendant des autres. Il y a une logique d’ensemble, qui doit durer, car c’est quelque chose de rassurant pour l’auditeur. En fait, chaque parcours, même si chaque narration, chaque histoire, chaque produit, va être différent, doit quand même avoir une logique similaire. 

C’est pour cela que j’aime bien la série ! Parce que tu as l’histoire de base et les épisodes. Pour nous, c’est le produit (la vision du produit) et chaque parcours. Et si tu regardes d’autres séries, si on garde la même analogie, chaque série est structurée. Si tu fais bien attention, tu vas toujours retrouver une structure similaire. Parfois, cette structure est cassée, mais c’est fait exprès, il y a une raison à cela. Ce n’est pas cassé parce que je suis nouveau et que je fais ce que je veux… Normalement, on est censé avoir posé la structure narrative. Mais du coup, si je le fais, je sais pourquoi je le fais. Il y a une raison pour laquelle là, c’était nécessaire, et on avance tout en gardant un peu la trame de l’histoire, ou la trame du parcours.

Du coup, je me disais que j’aurais pu aussi interviewer un scénariste (rires) ! 

Oui, clairement (rires) ! Il y a plein de trucs que j’ai appris il y a quelques mois, lorsque j’ai interviewé sur Clubhouse une Narrative designer, dans le domaine du gaming. J’ai découvert qu’il y a plein de points communs avec ce que l’on fait. Mais en fait, on a plein de points communs avec plein de métiers de la narration.

Et justement, en parlant de métiers, quels métiers participent à la construction de l’architecture de l’information ? Avec qui travailles-tu sur ces sujets-là ?

La plupart du temps, je travaille en binôme avec l’UX designer ou le Product designer. Mais il y a eu des occasions où j’ai travaillé toute seule et j’ai fait la hiérarchie toute seule, puis on l’a validé ensemble. Sur certaines missions de conseil, j’aide les startups à le faire elles-mêmes. Je les accompagne pour qu’elles arrivent à l’initier, à minima mapper leurs contenus. Je leur apporte de la méthodologie, sinon, il y a plein de gens qui vont commencer à créer leurs pages, mettre des choses dedans, mais sans avoir travaillé la logique. Sauf que, quand on a des services riches de contenu, il faut se poser en amont les bonnes questions.

Par exemple, tu vas avoir deux marques qui vont avoir des visions du monde complètement différentes.
Je pense à un service qui était lié à la Covid-19. On s’est posé. On a identifié tous les sujets, toutes les questions qui viennent aux utilisateurs, toutes les informations qu’on avait déjà. Je lui ai demandé de lister et de regrouper par thème, pour se faire une vision globale. Cette visibilité nous permet ensuite de réorganiser les choses, pour adresser les enjeux, qu’ils soient utilisateurs ou business.
En plus, si on prend en compte la saisonnalité, tu ne te poses pas les mêmes questions en septembre, quand c’est la rentrée des classes, qu’aux mois de juin – juillet. Tout le monde parlait des vacances et du pass sanitaire. Par conséquent, tu peux avoir des informations que tu vas pousser à des moments, d’autres à faire reculer, d’autres encore qui doivent toujours être présentes. Il faut identifier tout cela. On fait des hypothèses, que l’on va chercher à confirmer, à valider avec les utilisateurs. On détermine ce qui doit apparaître, disparaître, comment classer les informations, comment l’utilisateur va pouvoir trouver l’information si elle disparaît de la home page, par quel parcours il va y accéder…  

Le problème, c’est que quand on nous appelle, nous experts du contenu, on nous demande de réécrire des contenus. Mais, d’abord, posons la structure. Parce que je ne peux rien écrire si elle n’est pas logique ! C’est comme les Lego, on assemble les éléments pour construire la base, et ensuite, la rédaction, ce sont les finitions. 

Alors, pour toi, une architecture d’information efficace, ça veut dire quoi ?

Une architecture d’information efficace prend en compte à la fois les besoins des utilisateurs et les besoins du business. Il ne faut pas oublier qu’une entreprise a ses biais et que quand mes clients voient leurs produits, ils les voient depuis leur angle. Mon travail va être de les écouter, et de re-raconter les choses de manière à ce que cela « parle » à l’utilisateur final. Peut-être que certaines choses sont en réalité moins importantes pour l’utilisateur final. Pour le savoir, il faut faire de la recherche utilisateurs. 

Tu peux avoir deux marques qui vendent exactement le même produit et qui n’ont pas du tout la même vision, donc les histoires seront différentes.
Par exemple, entre HP et Apple, ce ne sont pas les mêmes expériences. En fait, il n’y a pas une règle qui va fonctionner pour tout le monde. On va faire du sur-mesure en fonction de l’entreprise, qui elle est, qui sont ses utilisateurs et qu’est-ce qu’ils veulent. Finalement, on ne va pas construire le même produit. 

Quand on pense hiérarchie de l’information, on pense à la hiérarchie globale d’un service. Et là, je n’ai pas envie dire que ce n’est pas le même métier, mais ça va demander beaucoup plus de compétences. C’est important quand même de ne pas tout mélanger. 

La hiérarchie de l’information d’un site, c’est une autre sphère. Ce n’est pas juste comment je construis mon parcours. Là, en fait, on rentre dans une partie vraiment stratégique. Et c’est pour ça, en tout cas aux États-Unis, que tu as des gens qui ne vont faire que ça. 

C’est-à-dire que si tu regardes un service, tu vas voir plein de départements différents. Le point de départ ça va être d’aller parler à tous ces gens. Aller dans chaque département, rencontrer les personnes, essayer de comprendre leurs besoins, comment ils voient le service, comprendre où va leur produit.
À la fin de tous tes entretiens, tu peux déjà avoir un certain nombre d’hypothèses, à partir desquelles tu pourrais construire un produit, mais seulement du point de vue de la vision de la marque. 

Ce que tu veux créer, c’est un système qui va prendre en compte là où en est l’entreprise, mais aussi là où elle veut aller. C’est donc très stratégique. Il va falloir que tu penses à un système qui est suffisamment flexible pour que cet élément rentre ensuite dans le parcours, et ne pas avoir à tout refaire à chaque fois.
On est sur la stratégie d’entreprise, la vision et là où la marque veut aller. Et comme je le disais tout à l’heure, deux marques, qui font la même chose, n’auront pas forcément la même vision. 

Ensuite, si tu veux que ton produit marche, tu ne peux pas te contenter d’écouter seulement la marque, sinon tu vas partir avec un méga biais. Tu vas aussi aller faire un travail de recherche pour comprendre les utilisateurs et utilisatrices. Quelles sont leurs habitudes ? Comment ils réfléchissent ? Qu’est-ce qu’ils pensent ? Quels sont les arguments importants ? Comment ils cherchent des informations de manière générale, ou en tout cas sur ce type de produits ? Comment ils font leurs courses en ligne ?
Et là, tu vas pouvoir tirer de nouvelles hypothèses et ensuite, tu vas devoir faire converger les deux systèmes. Ce n’est que le point de départ, c’est déterminant et ça prend du temps !  

Je me rappelle une marque où chaque Business Unit exigeait d’être présente sur la home page. Alors, que sincèrement, être sur la home, ce n’est pas toujours le plus stratégique… On sentait tous les jeux de pouvoir qui se cachaient derrière ces demandes.

Donc après, si tu as tous les éléments, tu peux commencer à rentrer dans la construction. 

J’ai travaillé en binôme avec un UX designer sur la reconstruction de tout un service. Il y avait plusieurs produits. On a tout réorganisé, regroupé, pour aboutir finalement à un seul produit, qui répondait à 75 % des problèmes, auquel pouvaient s’ajouter des options. C’est aussi beaucoup plus simple pour la navigation, pour construire les pages et le parcours.

Tu peux aussi utiliser des méthodes comme le tri de cartes. On l’a fait, avec différents types d’utilisateurs, pour construire la home du service que j’évoquais juste avant. On a demandé aux gens d’organiser les éléments à leur manière. C’était intéressant de voir qu’il y avait plein de solutions possibles, auxquelles moi-même, je n’aurais pas pensé. Cela nous a permis de prendre des décisions communes sur comment on allait organiser les contenus. 

Autre exercice, il s’agissait de classer par ordre de priorité les champs d’une page. J’ai demandé à chaque personne de faire son classement du plus important au moins important et d’expliquer pourquoi. 

Le tri de cartes, c’est une méthode, mais il y en a plein d’autres. On peut aussi les adapter, imaginer ses propres méthodes. 

Il y a un autre point dont je n’ai pas parlé, c’est la fonctionnalité de recherche. Il est important de comprendre les mécanismes de recherche. Cela ne suffit pas d’avoir un module de recherche, il faut a minima imaginer les pages de requêtes, comment elles fonctionnent… En fait, cela demande d’avoir plein d’informations sur plein de petites choses, qui vont permettre ensuite de prendre les bonnes décisions. On va tester aussi, pour vérifier si, effectivement, elles fonctionnent.

Ok. Ça, c’est dans l’idéal. Mais on sait très bien qu’en tant qu’UX writer, on arrive quand même souvent à la fin du process… Du coup, comment on fait pour remettre l’architecture à plat ? 

C’est la problématique de l’UX writer qui arrive à la fin du projet. Il y a un effort d’éducation à faire, pour expliquer notre travail, ou tu vas perdre beaucoup de temps. Je dois parfois passer mes soirées sur le produit. Des fois, mes week-ends, parce que je n’ai pas le temps. Si tu disposes d’une semaine à la fin, alors que le designer y a passé 3 mois, ce n’est pas équilibré. Sur cette problématique-là, j’ai réussi à faire passer le message que ça ne fonctionnait pas et qu’il fallait que j’arrive en début de projet. J’ai donc travaillé sur beaucoup moins de projets, mais au moins, j’arrivais au début. Ça m’a permis de comprendre aussi qu’il fallait recruter des gens, qu’une personne ne peut pas tout faire.

En arrivant à la fin, je me retrouvais à travailler sur beaucoup de choses qui n’étaient pas forcément logiques. En fait, tu ne le vois pas quand tu as a la tête dans le guidon. Je vais voir que là, sur un parcours, ce n’est pas logique, ça ne marche pas. Si en face la personne est hyper ouverte, c’est cool. Si t’as quelqu’un qui a un instinct de propriété sur ses écrans et qui ne supporte pas trop les commentaires, ça va être beaucoup plus difficile. De toute façon, ce n’est pas du tout la manière dont on doit travailler. Soyons clairs là-dessus, ça, c’est l’attitude d’entreprises qui ne sont pas matures sur le sujet. On est encore en phase de démocratisation de la pratique, alors il faut encore éduquer, expliquer.

Mais à un moment donné, il faut savoir le dire aux marques. Dans ces conditions, moi, je ne peux pas prendre votre projet. Et tant pis. Il y a des moments où il faudra dire non. Si j’arrive à la fin pour faire de la réécriture, c’est du copywriting, ce n’est pas de l’UX writing.

En tout cas, de cette façon, tu ne peux pas avoir de l’impact sur la hiérarchie de l’information de ton parcours. Ou alors, ça va être limité. Ça me rappelle d’ailleurs un projet sur lequel j’ai travaillé, où j’ai dit « oui, mais là, ce n’est pas logique ». On m’a répondu « oui, mais ça, c’est déjà développé ». Qu’est-ce que tu veux faire (rires) ?

Je me souviens d’une mission où la personne me disait « on cherche un UX writer, par contre, je te préviens, les designers ne veulent pas trop qu’on bouge les écrans ». 

Mon conseil, c’est de dire « non », en fait. 

En effet, j’ai dit non et je lui ai expliqué pourquoi. Sur un autre projet pour lequel j’avais dit oui, j’ai été confrontée au même problème. J’ai proposé de faire les choses différemment, mais la réponse était « le business ne veut pas. C’est comme ça et pas autrement. »

Je me répète en disant qu’il y a des entreprises qui sont matures, d’autres pas encore. Par exemple, là, j’ai eu la chance de bosser pour une startup, mais je parle vraiment de chance. C’était pour de la recette, donc je n’ai pas tout revu. J’avais surtout la chance d’être avec une designeuse qui était hyper à l’écoute. Déjà, avant de prendre la mission, j’ai expliqué mon process de travail. Si j’arrive pour faire de la réécriture à la fin, aujourd’hui, ces projets-là, je ne les prends pas. Oui, parce qu’en fait, tu ne peux quasiment rien faire et cela contribue à répandre l’image que l’UX writing c’est juste de la réécriture. 

Des fois, tu n’as pas le choix. Tu sais que ton client a compris, mais là, en gros, on est dans l’urgence. Et là, tout de suite, c’est non. Il y a quand même beaucoup de gens qui ont fantasmé notre métier. C’est pour ça que, et ce n’est pas pour faire la promo du livre, mais dans la deuxième partie, j’ai voulu expliquer notre process de travail. Quelles sont les différentes étapes ? Qu’est-ce qu’on peut faire en phase de recherche ? On voit qu’il y a plein de points communs avec l’UX/UI design. Mais il y a aussi plein de différences et cette complémentarité va nous permettre d’améliorer le produit jusqu’au bout.

Mais ça, ce n’est pas possible si tu arrives à la fin. Donc j’ai des slides, je présente mon process, et je vois à quel point l’entreprise est mature. On est vraiment dans un enjeu de maturité. Parfois l’entreprise va dire « OK, j’ai compris. Malheureusement, j’ai une deadline, mais clairement, sur la suite, on fera autrement ». Là, ça vaut le coup. En tout cas, moi, j’aurais tendance à tester. Mais si c’est juste venir pour faire de la réécriture… ça ne m’intéresse pas.

Ça va de mieux en mieux quand même. On a, je trouve, de moins en moins besoin de sensibiliser et de justifier l’importance qu’on soit là bien en amont.

On a encore à le faire, on est encore en phase d’éducation. C’est pour ça que c’est important d’avoir des conférences, de continuer à expliquer ce qu’on fait, ce qu’on apporte. On ne donne pas juste l’impression que notre travail, c’est de faire de la réécriture ou simplement d’écrire bien (rires). Ouais, super, mais en fait, non, on a vraiment, vraiment un impact. La hiérarchie d’information, je le dis souvent, c’est le plus gros problème « pourquoi on a mis cela, et pourquoi il y a toutes ces infos ? »

Dans certaines boîtes, je pense notamment à Intercom, la hiérarchie de l’information était de la responsabilité du Content design. Ils avaient fait une fiche de poste de Content designer. On pouvait vraiment voir le périmètre de ce métier et la complémentarité entre Product design et Content design. Hyper intéressant. 

Si on veutrésumer la définition d’une architecture d’information, quelles sont concrètement les étapes ?

La première étape, c’est la recherche. Ensuite, se demander : quels sont les contenus à notre disposition ? Un exemple : j’ai travaillé sur un produit, précisément sur de l’aide. Les personnes du métier m’avaient dit qu’elles avaient déjà listé toutes les questions (pour une FAQ). C’était très orienté sur les fonctionnalités du produit, mais est-ce que ce sont les questions que se posent les utilisateurs, réellement ? 

Avec mon binôme, on a commencé à aller chercher sur les forums pour recueillir des données utilisateurs. On a commencé à voir toutes les questions que les gens se posaient et on s’est mis à mapper tous les sujets, à les organiser par thématique. On a posé la logique. C’était hyper intéressant. Par exemple, une question que les gens se posaient à propos des véhicules électriques, c’était « est-ce que je peux recharger ma voiture quand il pleut ? ». Ça, c’est une question utilisateur. 

Quand tu mixes les deux, la vision business et la vision utilisateur, c’est plus complet. Tout le monde se rend compte qu’en fait, les gens ne se posent pas les mêmes questions que nous (rires) !
Tu peux soit demander à des utilisateurs de venir t’organiser les infos, mais là, c’est pour des services qui sont très demandeurs d’informations et de contenu. Ou alors, il y a des parcours beaucoup plus simples où le contenu a moins de place. Et là, on va organiser le dialogue, la conversation dont on parlait tout à l’heure. C’est pour cela que j’ai du mal à te donner une recette, il n’y a pas de recette. La recette, ça dépend de ton produit, de la somme d’informations à gérer, de la somme de travail à faire. Si tu dois partir de l’existant et retravailler un truc, c’est une chose. Si tu dois tout construire, c’en une autre.

Et puis ça dépend du business. Comme je le disais l’heure, si tu travailles la hiérarchie de tout un service, parce que vous devez le rafraîchir, ça fait un moment qu’il existe, vous en voyez les limites, il faut tout repenser… Tu verras que si tu impliques le business, les utilisateurs, que tu réfléchis l’ensemble de ta vision, la sémantique (les termes que l’on va utiliser) va influer sur tous les parcours. Si tu commences à utiliser un terme, il va avoir un impact sur l’ensemble des parcours qui vont suivre. Tu construis ainsi quelque chose de beaucoup plus solide et en même temps plus flexible. Si tu as pris en compte l’ensemble des parties prenantes, les utilisateurs, tu sais à peu près où veut aller la marque. En tout cas, ça a été pensé pour qu’à terme, ça puisse évoluer dans telle ou telle direction. 

Une fois que l’architecture d’information est définie, comment on la matérialise, comment on la représente ?

Après, tu construis ton service, tu vas travailler ton site, tu vas travailler ta navigation. Comment je rentre dans mes éléments ? Est-ce que c’est clair ? Est-ce que les personnes trouvent facilement l’information ? Tu vas tester. Tu t’apercevras peut-être que le problème, c’est un terme qui n’est pas le bon. Ou peut-être que c’est un des aspects du design qui ne fonctionne pas.

Donc c’est vraiment quand vous allez tester, que ce soit l’ensemble du site ou la navigation, vous allez commencer à voir ce qui fonctionne ou pas. 

Comment tu testes l’architecture d’information ?

Je te donne un exemple. Imaginons que tu as un scénario à écrire : « Vous souhaitez acheter un paquet de croquettes pour votre chat ». Tu vas regarder comment la personne utilise le service. Où est-ce qu’elle va, est-ce qu’elle trouve les choses de manière intuitive ? Au contraire, est-ce qu’elle cherche beaucoup ? Pourquoi ? Est-ce que le problème, c’est le terme utilisé ?
Tu la regardes faire pour essayer de comprendre. Si, à un moment donné, il y a un paiement à faire, tu vas lui fournir le faux numéro de carte pour continuer le parcours, mais tu essaies au maximum de la laisser faire.
Ce que j’aime bien faire dans les tests, c’est d’accepter de générer de la frustration. C’est-à-dire que si ça ne marche pas, je veux voir aussi comment les gens réagissent, pour pouvoir anticiper mes messages d’erreur. 
Pour savoir comment les personnes réagissent à telle ou telle pratique que je n’avais peut-être pas anticipée. Ou alors tester ce que j’avais préparé et voir quelles sont les réactions pour que je puisse aussi en tenir compte. Après, je vais itérer et corriger ces éléments.

C’est hyper intéressant ! Pour toi, une interface sans avoir défini une architecture d’information, qu’est-ce que c’est ?

C’est la catastrophe ! (Rires)
Cela va souvent aboutir à des expériences qui vont être hyper difficiles à utiliser, où l’utilisateur va se prendre la tête. Parfois, ça va être des éléments, on ne sait pas pourquoi ils sont là, sur telle page et à tel endroit. Parfois, il y a des bonnes raisons. Ce qu’il ne faut pas oublier, c’est que, quand on est dans le projet tous les jours, on se rend compte qu’il y a des problématiques d’ordre technique. Il y a des interdépendances entre ce que font les différentes équipes. On ne peut pas toujours faire ce qu’on veut. Parfois, on sait que ce n’est pas optimal, mais on ne pouvait pas faire autrement, pour des raisons techniques. 

Parfois, tu peux repenser tes éléments, ta page, ton séquençage, pour remettre de la logique. Cela demande de faire preuve de créativité.

Une hiérarchie d’information qui a été mal pensée, on le voit assez vite dans le parcours. 

Si on devait résumer notre échange, on retient quoi ?

Selon moi, ce qu’il faut retenir, c’est que la hiérarchie d’information, c’est vraiment la structure. C’est pour moi le plus important. S’il y a quelque chose où on doit clairement investir, c’est la hiérarchie de l’information. Et ce, que ce soit au niveau parcours, au niveau des pages ou des écrans, ou au niveau du service.

Il y a un livre qui s’appelle « Don’t make me think » qui dit que si tu as bien construit ton service, la personne n’a pas à se poser de questions. Bien construit et aussi bien testé. Parce que tu peux bien construire et te planter. Mais si tu as testé, tu sais, tu corriges. 

Mais en tout cas, si tu fais fait le travail, de tester et d’itérer, tu vas faire quelque chose où les gens ne se posent pas de questions. Ils avancent naturellement. Personne n’est là pour se prendre la tête avec un service en se demandant comment ça marche (rires). Il faut avoir à l’esprit que le client, ce n’est pas nous. Nous, on est là pour essayer de rendre les choses simples, pour faire en sorte d’avoir compris suffisamment les gens et le business. 

Pour faire de la hiérarchie de l’information, il faut se forger une vision stratégique. En tout cas, c’est vraiment la recommandation que je fais. Vous ne faites pas des produits pour le business, vous faites des produits pour le business ET les utilisateurs. Et si vous arrivez vraiment à mixer les deux et à continuer à vous former sur toutes les petites choses que vous n’avez pas encore (et que vous finirez par avoir), en plus de cette vision stratégique, vous pourrez concevoir de super produits. 

Est-ce que tu as des ressources à partager sur le sujet, si on veut progresser sur l’architecture d’information ?

Oui, il y a un livre qui est assez simple, c’est celui par lequel j’avais commencé. Ça s’appelle « How to make sense of any mess ? ». Il y a aussi le livre « UX Strategy ». Il y a aussi des ressources en français chez Eyrolles ou Dunod.
Je sais qu’il y a des formations au
Laptop. Ils ont une formation en UX stratégie, si vous avez envie de vous former.
Je recommande vraiment les livres de recherche, parce qu’il y a une grosse part de recherche utilisateurs, on ne peut pas y couper, si on veut bien faire les choses. Et là, je pense au livre de Carine Lallemand
 et Guillaume Gronier, Méthodes de Design UX. Sincèrement, habituez-vous à faire de la recherche et à être à l’aise avec les méthodologies de recherche.
Intéressez-vous au tri de cartes et autres méthodes de recherche. Dans son livre, Carine Lallemand en parle. Il y a aussi des articles sur le sujet.

Soyez curieux et curieuses. En plus, tout ce que vous allez apprendre là, ce sont des choses qui vont vous servir sur tous vos parcours.

Vu qu’on parlait de livres et que tu as un peu parlé du tien, est-ce que tu peux nous en dire plus ? Que va-t-on y trouver dedans ? La recette magique de l’UX writing ?

Alors je ne sais pas si c’est la recette magique (rires), mais j’ai essayé de faire le livre que j’aurais aimé avoir en commençant. On y retrouve comment on construit la voix. Mais moi, j’ai voulu aussi parler de narration. La première partie est sur la narration, à quoi il faut penser pour travailler la narration de son parcours.
Savoir qu’il y a un début, un milieu, une fin, ça parait tellement logique. Sauf que, parfois, vous regardez des parcours et il n’y a pas de début, il n’y a pas d’onboarding, c’est direct : « Tu veux acheter ou pas ? » (rires). Je caricature, mais presque pas. Heureusement, ce n’est pas toujours le cas. Donc, il y a plein de logiques narratives et des choses qu’on peut appliquer à des parcours pour commencer à réfléchir avant de rentrer dans le détail. 

Dans toute la deuxième partie, j’ai voulu montrer notre process. J’avais fait un atelier avec plusieurs UX designers, Content designers et je leur avais demandé « que faites-vous à chaque étape ? ». Je me suis servi de cela et des choses que j’ai apprises dans des livres. Mais en tout cas, je reviens sur l’ensemble du process Design Thinking. Je montre, à chaque étape, ce que fait un designer ou UX writer.

Ce n’est pas exhaustif, ça évolue et, clairement, je pense que s’il y a d’autres éditions, il y aura encore de nouvelles choses ! En tout cas, je pense que déjà, plein de gens ne se disent même pas qu’on peut faire ça. Donc, je pense que c’est un point de départ, des méthodes. On parle aussi d’inclusion, d’accessibilité, de localisation, de messages d’erreur, de stress cases. 
On y retrouve également plein d’exemples, quelques interviews, etc.

Cool ! Enfin, une bonne ressource française qu’on a hâte de découvrir, normalement en fin d’année. 

A priori, il sera disponible entre le 25 novembre 2021 et début janvier 2022. 

Je n’hésiterai pas à en parler partout ! 
Pour terminer, où est-ce qu’on peut continuer à échanger avec toi ? Quels sont tes réseaux d’échanges de prédilection ?

Je suis sur LinkedIn, Twitter, ainsi que Clubhouse tous les jeudis soir. C’est cool, on aime bien, il y a des sessions où les gens viennent poser des questions ou juste discuter ou partager leur expérience. C’est assez cool. Et puis d’autres sessions, avec la présence d’experts. 

C’est bien noté. Merci beaucoup pour tous ces échanges et conseils instructifs. J’espère que ça va en aider plusieurs à construire l’architecture d’information de leurs produits.

Merci Apolline.

Recevez, par mail, mes tips d’UX Writing

Deux fois par mois, dans votre boîte mail, je vous aide à améliorer la lisibilité et les contenus de votre interface web ou mobile.

  • Des astuces pour faciliter la vie et l’action de vos utilisateurs sur votre interface
  • Des ressources pour que vous deveniez un fin connaisseur de la microcopie
  • Le dernier épisode de podcast (ce serait dommage de le rater… :))

Pour recevoir ces tips, abonnez-vous 😉 

 

On garde le contact ?

Vous avez aimé l’épisode ? Dites-le moi en laissant un commentaire, un like ou une note sur la plateforme sur laquelle vous l’écoutez.
N’hésitez à me faire des feedbacks sur l’épisode, pour prolonger le débat, ou sur le podcast en général. Cela m’aidera à l’améliorer, pour qu’il réponde à vos besoins.