Share
La fin de semaine dernière, j’avais une conversation intéressante avec un ami d’un ami, sur la nécessité de disposer d’outils de flux de production de contenu antérieurs au système de gestion de contenu (CMS classique). Plus précisément, cet ami d’ami contestait l’idée de découpler les systèmes de gestion de contenu: disposer de plates-formes distinctes du système de gestion de contenu (CMS) exclusivement axées sur les flux de production et d’édition. Il pensait que tout ce travail pouvait être effectué directement dans le système de gestion de contenu..
Bien que ce soit un point juste (techniquement du moins), j'ai depuis été sujet aux arguments que j'aurais pu donner contre cette idée de tout faire dans le CMS..
À l'époque, je venais de critiquer l'expérience utilisateur générale d'écriture et de gestion de la production de contenu dans un système de gestion de contenu, et j'ai marmonné l'analogie de Karen McGrane à propos des presses à imprimer (à propos de la difficulté d'avoir un seul outil qui tente de tout faire)..
Depuis, j'ai réalisé que ma réponse ne permettait absolument pas de résoudre le problème le plus criant: cela implique que la production de contenu ne nécessite pas de processus dédié..
La chose amusante à propos de cette conversation était que l'homme travaillait réellement dans un cabinet de conseil UX; un endroit où le processus est évidemment une affaire énorme.
Dans le contexte de la recherche en conception extrême, des tests utilisateurs et de l’évaluation des entreprises, il semble un peu fou de suggérer que tout ce qui entoure la création de contenu peut tout simplement être fait dans le CMS. Une réflexion après coup, ou du moins quelque chose qui peut être exécuté dans un vide (très général).
Et ce serait ma réponse plus réfléchie à l'homme: qu'en suggérant que le contenu puisse être développé dans le système de gestion de contenu, je pense que nous risquons d'assigner du contenu après coup; ce qui implique qu'il ne nécessite pas vraiment de processus dédié et (plus sérieusement) qu'il ne doit pas être considéré comme une composante de la conception ou du travail UX.
Voici quelques raisons plus concrètes d'éviter une approche centrée sur la CMS pour développer du contenu:
Le temps pris pour la production de contenu est souvent sous-estimé. Ceci est évidemment plus probable lorsque la planification de la production n'est pas faite à l'avance (il est impossible d'estimer le nombre d'heures pour un travail non défini)..
"Nous avons terminé votre site Web, nous attendons juste le contenu" - le gars
En n'évaluant pas correctement les exigences de contenu au début d'un projet, ou en évitant toute gouvernance autour de votre production de contenu, vous ne pouvez pas vraiment vous plaindre lorsque les estimations sont faussées et que votre projet est en retard.
Une approche populaire consiste à organiser des ateliers de planification du contenu (avec des personnes du côté client et du côté agence du projet) au début d'un projet. Celles-ci peuvent très bien fonctionner pour amener tout le monde à participer au processus de production de contenu…
À la suite de ces ateliers (/ séances de thérapie de groupe), chacun verra aussi combien de travail est impliqué et les estimations seront plus précises..
Il peut être intéressant de centrer l’atelier sur la définition des étapes de production permettant de faire passer un type de contenu spécifique du brouillon à la publication. Vous pouvez donc consulter les différents cycles de recherche, de rédaction et de révision nécessaires à la publication d'une "page d'événements" (et à sa mise à jour!)..
Une fois que vous avez terminé le processus, vous pouvez calculer le temps nécessaire pour terminer le processus, puis le multiplier par le nombre de pages de votre projet. Les gens peuvent pleurer.
Un résultat évident des échecs d'estimations est un échec dans le respect du budget. Une pensée après coup chère.
Une fois que vous avez terminé votre atelier, vous pouvez très clairement inclure la production de contenu dans votre budget de manière compréhensible pour votre client. Vous avez préparé le terrain et mis en évidence la nécessité d'investir dans la production de contenu.
Journée au sol: un contenu de bonne qualité prend du temps à produire. Quand ce n'est pas donné temps, recherche, planification et considération le résultat sera un contenu qui n'engagera pas les gens. C'est assez dangereux.
La création de contenu efficace, dans certaines situations, peut définitivement s'avérer plus longue et complexe (au moins en termes de gestion) que la création de la technologie et la conception visuelle d'un projet de site Web..
Vous soutenez certainement que les conceptions visuelles sont plus facilement répétées à l'aide de bibliothèques de modèles et de guides de style, créant ainsi un ensemble de règles pouvant être répétées. Il existe également des normes très claires et des attentes des utilisateurs en matière d’architecture de l’information et de conception structurelle de sites Web. C'est beaucoup plus évident lorsque cette interface utilisateur ou cette conception structurelle est incohérente ou ne fonctionne pas (le contenu est un moyen très «dense» et un support «ambigu» à tester).
Donnez-vous du temps. Et définir un processus.
En ayant un processus dédié autour du contenu (avant le CMS), il devient beaucoup plus facile d'intégrer des outils pour vous aider à créer un contenu qui fonctionne.
Vous devriez consacrer du temps au début à la création d'un guide de style pour aider les personnes à créer un contenu répondant aux critères de votre projet. Cela peut sembler un peu intimidant, mais vous pouvez utiliser de nombreux exemples comme modèles pour créer votre propre.
Vous pouvez également utiliser des outils d'édition en ligne collaboratifs tels que Google Documents, Brouillon, Penflip ou GatherContent pour héberger votre production de contenu dans un emplacement central. faciliter la gestion de votre processus et l'application de votre guide de style.
Comme on pouvait s'y attendre, cet argument nous ramène à l'idée d'une approche d'abord axée sur le contenu pour la conception Web. Tout le concept de contenu restant jusqu'à ce que le CMS suggère une approche très axée sur le contenu. Cela suggère que la recherche et la conception ont lieu, puis que le système de gestion de contenu est construit, et qu'il ne reste plus qu'à remplir les blancs avec le contenu..
Celui-ci est assez rhétorique: vous prenez simplement des décisions de conception avec une connaissance (et basée sur) du contenu. Adieu, lorem ipsum.
Il existe de nombreuses ressources récentes sur le wireframing et le prototypage avec un contenu réel (Typecast est un outil très utile pour vous aider dans ce domaine)..
Les prototypes fonctionnants de TypecastMême s'il ne s'agit pas de la version finale, il est logique d'utiliser du contenu réel dans vos structures filaires et vos premiers modèles. pour voir si votre communication fonctionne réellement, de manière holistique.
Lorsque la conception et le contenu sont déconnectés, toute l'expérience utilisateur est menacée. Lorsque nous considérons l'expérience d'une personne utilisant un site Web, nous devrions être grandement informés (et tester) le contenu qu'elle consomme. Tester simplement le parcours de quelqu'un au contenu ne teste pas vraiment l'expérience. C'est comme analyser le voyage de quelqu'un au cinéma, mais ne pas tenir compte de ce qu'ils pensaient du film.
Les tests d'utilisabilité ont tendance à négliger le contenu. Si vous effectuez des tests utilisateur, vous devez inclure des tâches et des questions sur les informations extraites de la session. Qu'ont-ils extrait du contenu? Est-ce ce que vous attendiez? Quelque chose d'important est-il rendu flou? Est-ce que quelque chose de trop important ne devrait pas être? Quel impact cela at-il eu sur leur expérience?.
Même si vous ne testez pas l'expérience utilisateur formelle, il s'agit en réalité de reconnaître que le contenu constituera toujours un élément important de l'expérience de quelqu'un sur le Web..
Lorsque le contenu ne répond pas aux besoins de vos utilisateurs, il est peu probable que vos objectifs commerciaux soient atteints..
Et quand vos objectifs commerciaux ne sont pas atteints…
cela rend le projet un échec.
Et personne ne veut ça.
Personne (très peu de gens) ne croit vraiment que le contenu peut être laissé à la dernière minute. Toute la campagne «le contenu est important» est bien terminée; et la valeur du contenu, et de travailler contenu-premier a définitivement été adopté.
Cependant, même si nous pouvons convenir que le contenu est stratégiquement important… il semble toujours y avoir un manque d'investissement dans un processus de production permettant de créer ce contenu. Répétant les paroles de Karen McGrane:
"Un client m'a posé la question une fois:" Le CMS ressemble-t-il davantage à une presse à imprimer ou à un outil de flux de travail permettant de gérer tous nos processus de publication? " Pour de nombreuses organisations, la véritable difficulté réside dans les processus de production qui se déroulent en dehors du système de publication. " - Karen McGrane
En ce qui concerne les composants de conception et de technologie des projets Web, il semble exister un ensemble de processus aussi avancé qui prend en charge le développement (et l’itération) de solutions bien pensées. Le contenu ne semble pas exister de la même manière.
La croyance dans la production de documents Word et de contenus CMS semble mettre en évidence le problème, et c’est pourquoi je continuerais à plaider en faveur de l’existence d’outils, de processus et de méthodologies pratiques qui encouragent la gouvernance de la production et des tests de contenus bien conçus. En dehors du CMS.
Avez-vous un processus de production pour le contenu? J'aimerais entendre vos pensées dans les commentaires.
Accentsconagua