Clarifier la tâche et la décision
Ce guide transforme le choix du mode de langue approprié en un flux de travail opérationnel révisable. Il relie les décisions de domaine, la propriété, les preuves et l'acceptation afin que le résultat continue de fonctionner en production.
Utilisez une décision à quatre facteurs : public, tâche, conséquence d'un malentendu et capacité d'examen.
Méthode pratique
- 1
Définissez le public avec des preuves, y compris l'expérience de lecture, le contexte, l'appareil et l'assistance disponible.
- 2
Sélectionnez une tâche réelle et indiquez ce qu'un lecteur qui réussit doit comprendre ou faire.
- 3
Créez la version linguistique en préservant tous les faits, conditions, dates et chemins de contact pertinents pour la décision.
- 4
Exécutez une révision spécialisée et éditoriale avec des critères d’acceptation enregistrés.
- 5
Testez avec des membres du public visé, enregistrez les résultats, révisez et approuvez la version.
Exemple ou outil
Une matrice de décision transforme quatre faits du projet en un choix de mode documenté. Dans l'outil, enregistrez également la référence, le propriétaire, la décision, les preuves, le problème en suspens et la date d'approbation. Utilisez une page ou une transaction réelle pour que l'équipe voie les dépendances, les exceptions et le travail de maintenance qui suit la publication.
| Point de décision | Enregistrer | Critère d'acceptation |
|---|---|---|
| Référence | État actuel observé | Source et date d'enregistrement |
| Décision | Option sélectionnée et justification | Risque et public pris en compte |
| Preuve | Tester, documenter ou mesurer | Révisable et spécifique à la version |
| Approbation | Nom, rôle et date | Tous les critères obligatoires sont remplis |
Notez quatre facteurs avant de sélectionner un mode
Organisez un court atelier de décision avec le propriétaire du service, l'éditeur, le spécialiste de l'accessibilité et une personne qui connaît le public. Notez les besoins du public, la complexité des tâches, les conséquences d'un malentendu et la capacité de révision disponible de un à trois. Un score élevé en termes de besoins du public signifie que de nombreux lecteurs visés se heurtent à des barrières en matière d'alphabétisation, de langue, cognitives ou situationnelles. Un score de conséquence élevé signifie qu’un malentendu peut supprimer un droit, créer une perte financière ou empêcher l’achèvement d’un service essentiel.
Le total est une invitation au jugement professionnel et non une classification automatique. Les scores de quatre à six soutiennent normalement le langage clair avec révision éditoriale. Des scores de sept à neuf justifient des preuves supplémentaires, telles que des tests utilisateurs ou des formats parallèles. Des scores de dix à douze indiquent de solides arguments en faveur d'une version en FALC avec une évaluation par des spécialistes et un public cible. Enregistrez toute décision qui diffère de la note, y compris les preuves et l'approbateur responsable.
| Facteur | 1 point | 2 points | 3 points |
|---|---|---|---|
| Besoin du public | Large public avec une forte expérience de lecture | Public mixte ou contexte stressant | Groupe connu avec des barrières de compréhension importantes |
| Complexité des tâches | Une action familière | Plusieurs conditions ou documents | Décisions dépendantes multiples et termes inconnus |
| Conséquence | Inconvénient mineur | Retard ou contact d’assistance évitable | Perte de droits, d’argent, de santé ou d’accès |
| Capacité de révision | Revue éditoriale disponible | Conseils spécialisés disponibles | Examen spécialisé et tests d’audience disponibles |
Appliquer la matrice à des scénarios de service réels
Une page sur les heures d'ouverture d'une bibliothèque s'adresse à un large public, a une tâche familière et entraîne de faibles conséquences. Un langage clair est normalement suffisant. Une demande d’aide au logement combine conditions d’éligibilité, exigences en matière de justificatifs, délais et conséquences financières. La page de service général doit être utilisée en langage clair, tandis qu'une explication supplémentaire en langage clair peut être nécessaire pour les personnes qui ne pourraient autrement pas comprendre leurs options. L'application elle-même a toujours besoin d'une conception et d'un support de formulaire accessibles, car une version linguistique ne peut pas réparer une transaction inaccessible.
Pour une alerte d’urgence, le public est large et les conséquences sont importantes, mais la vitesse et la précision dominent. Utilisez un langage clair et direct, un vocabulaire d’avertissement établi, plusieurs canaux et des repères visuels testés. N’appliquez pas un long cycle de production FALC à l’alerte initiale. Une explication préparée en langage clair peut suivre pour les incidents persistants. Ces distinctions montrent pourquoi le public, la tâche, le risque et la capacité opérationnelle doivent être considérés ensemble.
Utilisez une vraie page et une audience nommée, pas une catégorie de contenu abstraite.
Incluez les conséquences d’un malentendu et d’un retard de publication.
Séparez la page d’informations, le formulaire, la confirmation et le canal d’assistance dans l’évaluation.
Indiquez si une version parallèle complète ou remplace la copie existante.
Identifiez les preuves qui confirmeront le choix après la libération.
Transformez les décisions individuelles en règles de portefeuille
Après avoir évalué les services représentatifs, définissez les classes de contenu avec les modes par défaut. La navigation générale, les messages d'état et les résumés de service peuvent être définis par défaut en langage clair. Les parcours à fort impact en matière de prestations, de santé, de migration, de justice et de handicap peuvent nécessiter une évaluation explicite en FALC. Les slogans de campagne et les documents sources juridiques ne doivent pas être transformés sans un objectif et un propriétaire définis. Les valeurs par défaut réduisent les débats répétés tout en préservant une voie d'exception pour des publics ou des risques inhabituels.
Stockez le mode sélectionné sous forme de métadonnées structurées dans le CMS. Les champs utiles incluent l'audience, le score de décision, le propriétaire de la source, la norme linguistique, le réviseur, l'état de la révision, la version source, la prochaine date de révision et la justification de l'exception. Les métadonnées permettent de créer des rapports et empêchent la publication d'un brouillon généré non révisé comme s'il avait suivi le processus correct. Cela permet également à l’équipe de trouver du contenu à haut risque lorsqu’une règle, un service ou une décision terminologique change.
- 1
Évaluez cinq à dix services représentatifs avec la matrice à quatre facteurs.
- 2
Regroupez les décisions similaires dans des classes de contenu et définissez un mode par défaut.
- 3
Créez une règle d'exception avec un approbateur responsable.
- 4
Ajoutez des champs de décision et de révision au modèle de contenu CMS.
- 5
Examinez les règles du portefeuille chaque trimestre par rapport aux preuves des utilisateurs et à la demande de support.
Confirmer le choix avec des preuves
Pour le langage clair, testez si les lecteurs visés peuvent trouver le passage pertinent, énoncer la bonne réponse et effectuer l'action suivante. Pour FALC, recrutez des personnes qui représentent réellement le public défini et faites appel à un spécialiste capable de distinguer la conformité linguistique de la véritable compréhension. Capturez la réussite de la tâche, les malentendus critiques, l'assistance demandée, la confiance et la révision exacte que les participants ont vue.
La décision de mode est confirmée lorsque la version sélectionnée répond à ses critères de tâche sans créer de nouveau risque de précision ou de maintenance. Si les lecteurs échouent toujours parce que le formulaire, la navigation ou le processus est complexe, enregistrez-le comme un problème de conception de service plutôt que de raccourcir le texte à plusieurs reprises. Approuvez le mode linguistique, le contenu et le parcours environnant en tant que décisions distinctes, avec des propriétaires pour chaque dépendance non résolue.
Rôles, preuves et approbation
La qualité linguistique est une responsabilité opérationnelle. Donnez au propriétaire de la source la responsabilité de l'exactitude des faits, à un éditeur la responsabilité de la clarté, à un spécialiste la responsabilité des règles d'accessibilité et au propriétaire du produit la responsabilité de la publication. L'enregistrement de version doit identifier la version source, le mode linguistique, les réviseurs, les preuves de test, la date d'approbation et l'événement qui déclenche une nouvelle révision.
Opérations et entretien
Le travail ne s'arrête pas à la publication. Liez la version linguistique ou la configuration à sa source, surveillez les mesures de qualité et de service et définissez des déclencheurs de révision concrets. Les déclencheurs incluent les changements de source, les changements juridiques, les nouveaux besoins du public, les questions d'assistance récurrentes, les changements techniques et les incidents. Un propriétaire nommé évalue le déclencheur, ouvre une nouvelle révision si nécessaire et enregistre une nouvelle approbation.
Liste de contrôle avant publication
Le public et la tâche sont explicites.
Tous les faits juridiques et opérationnels correspondent à la source.
Les dates, montants, conditions et exceptions sont complets.
Les titres décrivent les questions ou les actions du lecteur.
Les liens et les contrôles ont des étiquettes significatives.
La terminologie spécialisée est expliquée de manière cohérente.
Le public visé a testé le parcours critique.
La propriété et le prochain déclencheur de révision sont enregistrés.