Navigation d'entreprise : méthodologies de conception pour la collaboration des parties prenantes

Publié: 2022-03-11

Concevoir (ou reconcevoir) un système de navigation d'entreprise n'est pas une tâche à prendre à la légère. Les applications d'entreprise servent un grand nombre d'utilisateurs, s'adaptent à un large éventail de personnes et contiennent un volume important de contenu et de fonctionnalités. Certaines applications d'entreprise ont même plusieurs produits de bureau et mobiles basés sur le Web qui doivent s'intégrer de manière transparente pour une expérience utilisateur plus agréable.

Bien que cela puisse sembler être une tâche intimidante, voire impossible, mieux gérée par une grande équipe d '«experts», un architecte d'information ou un concepteur UX solo peut s'attaquer à lui seul à une refonte de la conception UX d'une application d'entreprise, tant qu'il suit une méthodologie efficace pour la collaboration des parties prenantes.

"Lorsque vous mangez un éléphant, prenez une bouchée à la fois." - Creighton Williams Abrams Jr.

À propos des systèmes de conception de navigation d'entreprise

Les principales différences entre les applications d'entreprise et les systèmes Web plus petits sont le volume de contenu et la variété des fonctionnalités. Là où les petits systèmes peuvent effectivement s'appuyer sur un système de navigation relativement plat (c'est-à-dire moins de clics pour accéder à tout le contenu), l'architecture des applications d'entreprise nécessite souvent des menus à plusieurs niveaux et des mécanismes d'orientation soigneusement placés. Plus le système de navigation est complexe, plus il est important que le système lui-même soit facile à utiliser, bien organisé et aligné sur le modèle mental de l'utilisateur.

L'objectif final peut être clair, mais s'il existait une conception « parfaite » pour un système de navigation d'entreprise, chaque entreprise l'aurait adopté. Sans un système perfectionné, il y a beaucoup de place pour l'amélioration, la créativité et l'innovation. Cela révèle également le fait que chaque entreprise est différente, avec des cas d'utilisation et des exigences variables pour la navigation dans une application complexe.

La navigation est simplement une « orientation »

Fondamentalement, la navigation est une «orientation». Les navires de mer peuvent naviguer sur un large océan en utilisant les étoiles ; les voyageurs terrestres peuvent trouver leur destination à l'aide de points de repère; et, les utilisateurs d'applications d'entreprise atteignent leurs objectifs finaux en s'appuyant sur divers indicateurs numériques.

Par exemple, dans l'univers numérique, la navigation dépend de la sélection et du placement des mots-clés, des étiquettes, de la couleur, de l'iconographie, des objets d'appel à l'action et d'autres indicateurs à l'écran. Lorsque le contenu est mal organisé, les fonctionnalités sont étiquetées de manière non intuitive, les mots clés sont sélectionnés au hasard ou les icônes sont obtuses ou non conventionnelles, les utilisateurs peuvent devenir frustrés ou perdus… et ils peuvent tout simplement partir.

La conception de la navigation imite les systèmes de transport en commun, comme le métro de Londres.

Le métro de Londres est un réseau complexe de tubes et de tunnels. Cependant, avec un système de navigation bien conçu, l'expérience de l'utilisateur est simple et facile à comprendre. (La source)

Méthodologie de collaboration dans la conception de la navigation

Les environnements d'entreprise sont intrinsèquement complexes et nécessitent une grande organisation pour fonctionner efficacement. Aucune personne ne peut connaître ou comprendre intuitivement l'ensemble de la portée d'une application d'entreprise ou les attentes uniques et variées de sa base d'utilisateurs. Il existe de nombreuses opinions concernant les livrables essentiels à une méthodologie de conception donnée. Indépendamment de ce qui est finalement créé, toute méthodologie doit commencer par la collaboration des parties prenantes.

1. Réunion de lancement des parties prenantes

Tout projet à grande échelle devrait commencer par une réunion de lancement des parties prenantes. Fondamentalement, il s'agit d'une grande réunion avec tous les acteurs clés présents (à distance ou sur site) pour lancer le projet. En règle générale, une réunion de lancement des parties prenantes a un seul animateur qui présente les objectifs du projet, identifie tous les rôles des parties prenantes et s'en remet aux chefs de projet (le cas échéant) pour un contexte supplémentaire, afin que la collaboration puisse commencer.

Plus l'équipe est nombreuse, plus il est important de tenir une réunion officielle de lancement des parties prenantes. Tout comme la cérémonie d'ouverture des Jeux olympiques, ce point de départ un peu cérémoniel pour un projet indique clairement à toutes les parties prenantes que « les jeux ont commencé ».

En tant que concepteur, il est préférable d'obtenir la liste des parties prenantes et leurs rôles comme référence lors de la planification des sessions de conception de navigation et des entretiens. Tout le monde sur cette liste est important et précieux pour le travail qui doit être fait.

2. Remue-méninges sur le ciel bleu

Une fois toutes les parties prenantes identifiées et engagées, trouvez le temps de vous réunir en petits groupes ou planifiez des entretiens individuels pour mener des séances de remue-méninges et d'idéation. En ouvrant la porte au rêve d'un avenir « ciel bleu », les individus sont moins enclins à filtrer leurs idées ou leurs opinions, et l'innovation a une chance de déployer ses ailes.

Dans de nombreux cas, des obstacles historiques ou des limitations non fondées peuvent persister dans l'esprit des parties prenantes mais n'existent plus dans la réalité (en raison, par exemple, de nouvelles technologies, de changements sur le marché, de changements dans les revenus générés par l'application d'entreprise ou d'autres facteurs) . Lorsque les parties prenantes partagent des préoccupations au sujet de ces obstacles, essayez de demander « pourquoi » avant de les accepter tels qu'ils sont. Il peut y avoir une opportunité cachée ici.

Pour lancer ce processus de brainstorming, commencez par quelques questions :

  1. Si vous deviez sauter 5 ou 10 ans dans le futur sans limites ni obstacles, qu'aimeriez-vous voir dans la conception future ?
  2. Avez-vous eu des idées, qu'elles soient simples ou compliquées, mais aucune possibilité de les concrétiser ?
  3. Si vous étiez le PDG de cette entreprise, que feriez-vous dans cette situation ?
  4. Voyez-vous des besoins sur le marché qui pourraient être satisfaits par cette application ?

Il peut sembler que cette approche ouvrirait une «boîte de Pandore», mais tant que tout le monde est clair sur le scénario «ciel bleu», de grandes choses peuvent se produire. Essaie!

Une équipe de navigation d'entreprise réfléchit à des idées de "ciel bleu".

Des séances de remue-méninges individuelles ou en petits groupes peuvent révéler des obstacles historiques et générer des idées « ciel bleu » qui peuvent favoriser l'innovation.

3. Points douloureux et identification des problèmes

Lorsque les utilisateurs éprouvent de la difficulté ou de la frustration à naviguer dans un système d'entreprise à grande échelle pour trouver du contenu ou des fonctionnalités qui devraient être plus facilement accessibles, ces utilisateurs sont plus susceptibles d'abandonner et (parfois) de trouver une alternative. Cette alternative peut être avec un concurrent.

Soyez réaliste et agressif dans l'identification des points faibles et des problèmes des utilisateurs. De nombreuses parties prenantes ont un accès direct aux commentaires des utilisateurs par le biais d'enquêtes, de sessions de formation et d'autres formes de communication. Tirez parti de ces connaissances pour mieux comprendre les défaillances du système de navigation d'entreprise actuel.

Ces questions peuvent lancer le processus en identifiant les points douloureux et les problèmes :

  1. De quoi les utilisateurs se plaignent-ils le plus ?
  2. Utilisez-vous des services (tels que l'analyse du trafic Web ou le suivi des clics) qui suivent le comportement des utilisateurs dans le système ?
  3. Y a-t-il des domaines du système d'entreprise qui sont rarement utilisés, et vous ne pouvez pas expliquer pourquoi ?
  4. Si vous pouviez changer quelque chose à propos de cette application, ce serait quoi ?

La compréhension des problèmes rencontrés par les utilisateurs jouera un rôle majeur dans l'identification des lacunes de la conception actuelle. Capturez ces points pour les utiliser dans cette méthodologie.

4. Diagramme d'affinité

En tant que designer, les "notes autocollantes" peuvent être votre meilleur ami. Mais si trop de parties prenantes ne sont pas situées dans le même bureau ou si vous êtes la seule ressource distante, les notes autocollantes en papier sont utilisées en vain. Il est essentiel de trouver une approche efficace pour la collaboration en ligne. Il existe une grande variété d'outils de collaboration en ligne qui peuvent être utilisés pour capturer toutes les entrées des phases Blue Sky Brainstorming et Pain Points and Problem Identification.

Une fois que vous avez capturé une quantité importante d'entrées, l'étape suivante consiste à organiser ces entrées en groupes d'affinité. Le diagramme d'affinité est un exercice collaboratif qui permet à toutes les parties prenantes de trouver des relations ou des fonctionnalités partagées entre des idées individuelles ou des types de contenu. Cet exercice permet à un concepteur de rassembler toutes les idées « ciel bleu » et les « points faibles et problèmes ».

Par exemple, il peut être utile de regrouper le contenu des processus et des procédures dans une bibliothèque, ou les événements actuels et les mises à jour dignes d'intérêt dans un journal en ligne consolidé. Encouragez les parties prenantes à faire preuve de créativité dans la manière dont elles forment les groupes d'affinité.

Dans les séances de diagrammes d'affinité des parties prenantes, posez des questions comme celles-ci :

  1. Quelles fonctionnalités ou contenus semblent appartenir ensemble ?
  2. Les utilisateurs essaient-ils d'effectuer certaines actions qui seraient plus faciles si elles se produisaient dans l'ordre ?
  3. Existe-t-il des fonctionnalités redondantes qui pourraient être facilement fusionnées ou simplifiées ?
  4. Existe-t-il une possibilité de faire correspondre des idées de ciel bleu avec des points douloureux ou des problèmes existants ?

Encouragez les parties prenantes à réfléchir à des scénarios spécifiques qui amènent les utilisateurs à une fonctionnalité donnée au sein du système. L'utilisation de scénarios réels met les choses en perspective et permet aux parties prenantes d'être plus empathiques vis-à-vis de l'expérience utilisateur.

Un groupe mène une séance de création de diagrammes d'affinité pour définir la conception de la navigation.

La création de diagrammes d'affinité aide les équipes à donner un sens à de nombreuses données qualitatives et à créer des étapes suivantes claires et exploitables pour développer une architecture d'application d'entreprise.

5. Réorganisation logique

Une fois l'exercice de création de diagrammes d'affinité terminé, il est important de prendre du recul et d'examiner le système de manière holistique. Il existe souvent un ordre logique des opérations qu'un utilisateur peut suivre dans un environnement complexe donné. Examinez attentivement s'il existe des possibilités de fournir un service qui n'est pas disponible actuellement (innovation) ou d'encourager un utilisateur à étendre son utilité du système de navigation d'entreprise (découverte) en fournissant des indicateurs d'orientation.

Pour capturer cette organisation logique ou ordre des opérations, un concepteur peut créer un organigramme ou, dans des scénarios plus complexes, une carte de parcours utilisateur, en commençant par le flux de travail principal, puis en se ramifiant vers d'autres contenus ou fonctionnalités.

Les questions qui pourraient encourager vos parties prenantes incluent :

  1. Maintenant que l'utilisateur est "ici", que peut-il faire d'autre ?
  2. Quelle est la prochaine activité logique pour l'utilisateur dans ce scénario ?
  3. Manquons-nous des occasions de résoudre le problème de l'utilisateur de ce point de vue ?
  4. Existe-t-il des fonctionnalités ou du contenu existant ailleurs qui pourraient être utiles dans ce scénario ?

Une fois que vous avez lancé la conversation sur ce sujet, collaborez avec les parties prenantes pour réorganiser les groupes d'affinité en conséquence.

6. Hiérarchie

Au sein d'un groupe d'affinité plus large ou entre des groupes d'affinité individuels, il y aura probablement des relations ou des dépendances. Travaillez avec les parties prenantes pour identifier ces relations ou dépendances, puis organisez-les en hiérarchies. Une hiérarchie est simplement une manière sophistiquée de décrire comment un élément de contenu ou une fonctionnalité appartient à un groupe de contenu ou de fonctionnalités similaires. Par exemple, un seul article d'actualité appartient à un sujet, et le sujet appartient à une section dédiée aux actualités.

Exemple de hiérarchie de contenu : flux d'actualités vers le sujet d'actualités A vers l'article d'actualités A.1

Les groupes d'affinités révèlent les relations entre les informations et peuvent constituer la première étape de la définition de l'architecture des applications d'entreprise.

Avertissement!

À ce stade du processus de conception, les parties prenantes peuvent souhaiter utiliser l'organisation départementale existante de l'entreprise comme référence pour la hiérarchie du système d'entreprise. Bien qu'il soit facile d'imiter l'organisation des services de l'entreprise (qui est généralement là où se trouvent la propriété du contenu et des fonctionnalités), cela peut être une énorme erreur !

Les utilisateurs ne se soucient pas de savoir à qui appartient le contenu. De plus, étant donné que les grandes entreprises aiment se réorganiser fréquemment, le système de conception de navigation d'entreprise qui s'aligne sur l'organisation des départements ne sera plus valide dès la première "réorganisation".

Tirez parti de la méthodologie présentée jusqu'à présent et repoussez cette approche dangereuse. Ces questions peuvent aider à faciliter une conversation avec les parties prenantes :

  1. Comment ces groupes d'affinités sont-ils liés et pourquoi sont-ils liés ?
  2. Existe-t-il des dépendances entre les groupes d'affinité que nous devons reconnaître ?
  3. Les utilisateurs pourront-ils effectuer une tâche sans avoir à naviguer vers une autre zone du système ?
  4. Existe-t-il des hiérarchies conventionnelles familières aux utilisateurs d'autres secteurs ou modèles de services pouvant servir de référence ?

À ce stade du processus de conception, il existe de nombreuses façons de vérifier si l'approche fonctionne. Envisagez différentes méthodes de test utilisateur et de recherche d'utilisateurs pour confirmer votre hiérarchie ou pour identifier les problèmes qui nécessitent plus d'attention.

7. Nomenclature et paramètres

Avec un modèle complet de la future architecture des applications d'entreprise, également connue sous le nom d'architecture de l'information, il est temps de sélectionner des mots-clés (nomenclature) et de définir des paramètres (définitions).

La nomenclature, ou étiquetage, est un élément important de la conception de la navigation pour trois raisons principales : (a) la nomenclature est directement liée au référencement (optimisation pour les moteurs de recherche) dans la mesure où les moteurs de recherche recherchent principalement du contenu par mots-clés ; (b) l'utilisation d'une terminologie appropriée comme mécanisme d'orientation aidera les utilisateurs à trouver ce qu'ils recherchent en servant de « point de repère » numérique ; et (c) les étiquettes intelligentes peuvent conduire les utilisateurs vers une zone du système qui peut ne pas être facilement accessible à partir d'une page de destination principale ou d'une page d'accueil. La trouvabilité est pilotée par des mécanismes d'orientation, comme les étiquettes. Si une étiquette est trompeuse ou non intuitive, l'utilisateur peut ne pas prendre la peine de cliquer dessus.

Avec toute la nomenclature (étiquettes) identifiée dans le modèle d'architecture de l'information, collaborez avec les parties prenantes pour définir les paramètres (définitions) pour chaque zone étiquetée dans le modèle. Cela garantira que le contenu et les fonctionnalités appartiennent à un domaine particulier. De plus, cet exercice crée des directives à long terme pour la construction de l'architecture d'application d'entreprise qui durera plus longtemps que le processus de conception actuel.

Concernant la nomenclature et les paramètres, voici quelques questions à poser aux acteurs qui animeront la conversation :

  1. Que recherchent le plus souvent les utilisateurs lors de leur visite ?
  2. Certains contenus ou fonctionnalités sont-ils difficiles à trouver ? Pourquoi sont-ils difficiles à trouver ?
  3. Existe-t-il des termes ou un jargon de l'industrie qui pourraient ne pas être familiers à certains utilisateurs, ce qui rend plus difficile pour eux de trouver ce qu'ils recherchent ?
  4. Comment choisir des labels conventionnels ou mainstream ?

Comme mentionné ci-dessus, il existe de nombreuses méthodes différentes qui peuvent être utilisées pour tester la nomenclature, telles que le tri des cartes, les tests A/B et l'UX orientée objet (OOUX). Lorsque vous traitez avec un système d'entreprise hautement technique avec des tonnes de jargon industriel, envisagez de créer un vocabulaire contrôlé ou un glossaire intégré au système pour référence utilisateur.

8. Intégration avec le processus de conception de l'expérience utilisateur

Avec une image complète de la future architecture de l'information, il est maintenant temps d'appliquer les résultats de cette méthodologie au processus global de conception de l'expérience utilisateur.

Un concepteur utilise des épingles et des impressions pour déterminer la conception UX de l'application d'entreprise.

La conception de la navigation s'intègre directement dans le projet plus large de conception UX.

Bien qu'il puisse y avoir des zones du nouveau système de navigation d'entreprise qui n'existent pas lorsque le projet de conception est en cours, ces zones peuvent être « désactivées » ou masquées jusqu'à ce que le contenu ou les fonctionnalités soient prêts à être publiés. Ensuite, une fois que le concepteur est parti, les parties prenantes peuvent continuer à construire le système vers leurs rêves de « ciel bleu ».

"Si vous le construisez, ils viendront." - Champ de Rêves, 1989.

L'essentiel

Concevoir un système de navigation d'entreprise n'est pas une tâche facile. Cependant, tirer parti des connaissances des parties prenantes rendra cet effort gérable.

Mis à part la complexité des projets de conception à grande échelle, l'objectif est toujours de garder l'utilisateur à l'esprit. Avec une approche pratique de la recherche d'utilisateurs et en posant des questions intelligentes aux personnes qui ont un contact direct avec l'utilisateur, même un designer distant, solo ou indépendant peut gérer de gros problèmes de conception. Ne soyez pas intimidé, faites simplement les choses une étape à la fois.