Fermer

septembre 16, 2021

Des besoins des utilisateurs à la gestion des risques Web —26 minutes de lecture



Résumé rapide ↬

Il y a vingt ans, Elie Sloïm a choisi de consacrer sa vie professionnelle à l'assurance qualité web. Il a commencé à demander : « Qu'est-ce que la qualité signifie pour un internaute ? » Eh bien, cet article explique tout ce qu'il a appris en cours de route.

Chimiste de formation, j'ai obtenu un Master en Management et Contrôle Qualité de l'Université de Bordeaux. Ma première carrière a été dans l'industrie du vin, assurant la qualité des opérations du laboratoire et des analyses qui en découlent. En passant, la dernière question de mon entretien d'embauche en tant que responsable assurance qualité du laboratoire était « Vous aimez le vin ?, j'ai dit que non. Ils ont dit : « vous êtes embauché ».

En 1999, j'ai décidé d'appliquer mes connaissances en matière de gestion de la qualité au Web. J'ai quitté mon travail dans le laboratoire du vin. J'ai immédiatement commencé à travailler sur la réponse à la question « Qu'est-ce que la qualité pour un internaute ? » Cela signifie également répondre à cette autre question : « Comment évaluer, gérer et garantir la qualité d'un site Web ? »

L'assurance qualité (AQ) est définie comme :

« Un programme pour le suivi et l'évaluation systématiques des divers aspects d'un projet, d'un service ou d'une installation afin de garantir que les normes de qualité sont respectées. »

— « Assurance qualité », Merriam-Webster

L'AQ est un élément central de toute approche de gestion de la qualité et toute gestion de la qualité est très étroitement liée à la gestion des risques. Dans la plupart des secteurs où les risques sont compris et perçus comme critiques, l'assurance qualité se développe inévitablement. C'est pourquoi l'assurance qualité est un pilier des industries de l'aéronautique, de l'automobile, de la santé ou encore du jeu vidéo, et peu rêveraient de la remettre en cause.

La recherche de réponses aux questions liées à l'assurance qualité m'a amené à créer mon entreprise et de produire quelques checklists et standards documentés sur les données ouvertes, la performance et l'accessibilité du webdont les deux premières versions de la norme nationale française sur l'accessibilité (« RGAA » pour Référentiel Ggénéral d'Aamélioration de l'Accessibilité). Cela m'a également conduit à écrire un livre sur l'assurance qualité Web et les préfaces de huit autres livres sur l'UX, l'écoconception, le CSS, le développement frontend, entre autres. Répondre à ces questions est également la raison pour laquelle je suis toujours passionné par l'assurance qualité du Web des années plus tard. Et, ce sont ces mêmes questions qui m'amènent vers vous et vos projets web. Soit dit en passant, maintenant j'aime le vin, de partout.

Que signifie la qualité pour les utilisateurs ?

En explorant le concept d'assurance qualité des sites Web en 2001, nous avons commencé par une question simple : « Qu'est-ce que la qualité signifie pour les utilisateurs ? »

Selon l'ISO (Organisation internationale de normalisation), le terme qualité est :

« … le degré auquel un ensemble de caractéristiques inhérentes à un objet remplit les exigences. »

Poser cette première question sur un site Web implique d'analyser les besoins des utilisateurs. Au cours de nos recherches, nous avons créé un modèle composé de cinq exigences fondamentales des utilisateurs :

  1. La visibilité est la capacité d'un site à être rencontré par ses utilisateurs potentiels.
  2. La perception représente sa capacité à être rencontré. utilisable et positivement perçue par ses utilisateurs.
  3. Technique concerne sa capacité à fonctionner correctement.
  4. Contenu couvre la capacité à délivrer une information de qualité.
  5. Les services déterminent sa capacité à offrir, accompagner, et/ou générer des services de qualité.

Modèle VPTCS

Modèle VPTCS © Élie Sloïm — Éric Gateau — 2001 — www.opquast.com. ( Grand aperçu)

Il existe de nombreuses exigences des utilisateurs qui sont importantes pour les utilisateurs. Par exemple, ces cinq exigences ne portent pas sur les émotions (plaisir, attachement, gratitude, etc.) mais uniquement sur la réussite des exigences fondamentales. Le modèle ne vise pas à identifier de manière exhaustive tous les besoins des utilisateurs. Cependant, il peut être utilisé pour les classer et les ordonner. Nous l'avons appelé le modèle VPTCS.

Il nous dit que quel que soit le produit ou le service, ou qui sont les utilisateurs :

Les utilisateurs doivent pouvoir trouver le site Web. Ils doivent pouvoir l'utiliser et le percevoir correctement, ils ont besoin que le site Web fonctionne correctement, ils ont besoin d'un contenu de haute qualité et ils doivent également avoir une bonne expérience après leur visite.

Plus après le saut ! Continuez à lire ci-dessous ↓

Comment l'assurance qualité Web est-elle liée à l'UX et à l'interface utilisateur ?

Pour travailler sur l'assurance qualité Web, nous avons également dû travailler sur une autre partie de la définition de la qualité : le caractéristiques inhérentes à un objet. Cela signifie décrire ce qu'est un site Web. Cela nous a amené à travailler sur la structure de l'UX (expérience utilisateur) et comment elle est liée à l'UI (interface utilisateur). Pour ce faire, nous avons également utilisé le modèle VPTCS (Visibilité, Perception, Technique, Contenu, Services).

Le modèle se lit dans l'ordre chronologique relatif à la visite de l'utilisateur sur le site et aux trois grandes phases : avantpendant et après.

  • V : avant la visite
  • PTC : pendant
  • S : après la visite

Comme vous le verrez ci-dessous, nous avons décidé d'utiliser le modèle VPTCS pour distinguer l'expérience utilisateur totale (UX) de l'interface utilisateur (UI). L'UI est couverte par les trois sections centrales du modèle : Perception, Technique et Contenu, et n'est qu'une partie du parcours.

L'UX commence avant et se termine après l'UI.

Modèle VPTCS

Modèle VPTCS © Élie Sloïm — Éric Gateau — 2001 — www.opquast.com. ( Grand aperçu)

La visibilité nous amène à nous intéresser au pourquoi et au comment l'utilisateur est arrivé. La visibilité commence avant que l'utilisateur ne rencontre l'interface. Par exemple, la façon dont le site Web est décrit dans les pages de résultats des moteurs de recherche ou la façon dont les gens parlent du site Web sur les réseaux sociaux ; tout cela fait partie de l'expérience utilisateur.

À l'autre extrémité du modèle, la section Services nous amène à voir ce qui se passe après que l'utilisateur a quitté l'interface. Par exemple, sur un site e-commerce, votre expérience ne s'arrête pas au moment où vous quittez le site, elle continue. Par exemple, lorsque vous ne pouvez pas joindre le service client ou que vous devez attendre 20 minutes pour parler à une personne en direct, lorsque votre colis est livré endommagé ou partiellement ouvert, ou lorsque vous vous rendez compte que la description du produit sur le site Web n'était pas exacte . Dans ces cas, vous n'utilisez plus l'interface elle-même, mais interagissez dans une expérience utilisateur réelle.

Bien que le modèle VPTCS nous ait fourni un point de vue sur ce qu'est un site Web et quelles sont les exigences de l'utilisateur. , nous avons également voulu déterminer les conséquences pour les acteurs du projet web c'est-à-dire ceux qui conçoivent, produisent, développent, commercialisent ou commercialisent le site web.

Quels métiers sont impliqués dans l'assurance qualité web ?

expérience utilisateur de haute qualité dans les offres d'une entreprise, il doit y avoir une fusion transparente des services de plusieurs disciplines, y compris l'ingénierie, le marketing, la conception graphique et industrielle et la conception d'interfaces. (UX) », Don Norman et Jakob Nielsen

Lorsque nous avons commencé à travailler sur l'assurance qualité Web, nous avons constaté que l'identification des besoins des utilisateurs (Visibilité – Perception – Technique – Contenu – Services) n'était pas suffisante. Pour obtenir une adhésion professionnelle à l'approche d'assurance qualité, nous avons dû identifier les différentes disciplines impliquées dans un projet Web et les relier aux exigences. En cartographiant les différents métiers, on voit que chaque métier est nécessaire et qu'ils ont tous au moins un point commun : l'utilisateur.

Modèle VPTCS

Modèle VPTCS © Élie Sloïm — Éric Gateau — 2001 — www.opquast.com. ( Grand aperçu)

À ce stade, nous disposions d'un ensemble d'outils pour comprendre un ensemble d'exigences côté utilisateur, et la manière dont les métiers du Web étaient liés à ces exigences utilisateur.

Travailler sur le concept de qualité est toujours une approche multidisciplinaire. . Chaque utilisateur a sa propre vision subjective de la qualité d'un produit. Certains utilisateurs sont plus sensibles aux problèmes techniques, d'autres sont plus préoccupés par la qualité du contenu, certains sont profondément impactés par la qualité des services. L'évaluation de la qualité ne peut pas être totalement objective mais il est toujours possible de convertir les exigences générales des utilisateurs en outils plus exploitables. Pour ce faire, l'un des outils les plus simples que l'on puisse créer est une liste de contrôle, et c'est exactement ce que nous avons fait. et tire parti des connaissances que les gens ont, mais compense aussi d'une manière ou d'une autre nos inévitables insuffisances humaines. Et il existe une telle stratégie – même si elle semblera presque ridicule dans sa simplicité, peut-être même folle pour ceux d'entre nous qui n'ont pas passé des années à développer soigneusement des compétences et des technologies de plus en plus avancées.

C'est une liste de contrôle. »

— Atul Gawand, The Checklist Manifesto

Nous avons décidé de traduire le modèle VPTCS en règles individuelles en appliquant les vérifications suivantes :

« Existe-t-il des règles universelles, réalistes, durables, directement vérifiables par des utilisateurs finaux qui ont le consensus et la valeur ajoutée pour les utilisateurs ? »

En 2004, nous avons soumis un ensemble de règles à la communauté Opquast de professionnels du web dans le cadre d'ateliers publics en ligne. Nous leur avons donné les critères suivants pour soumettre des règles : chaque règle doit avoir un impact décrit sur les utilisateurs, doit être réaliste, doit avoir un consensus, doit être universelle et vérifiable par l'utilisateur final. Cet ensemble de « règles pour créer des règles » est un test de santé mentale pour ne conserver que les règles qui peuvent être acceptées et utilisées par la communauté.

Depuis lors, nous avons produit 4 versions de notre liste de contrôle – en 2004, 2010, 2015, et 2020. Au total, nous avons collecté plus de 10 000 commentaires, rejeté plus d'un millier de règles de qualité et conservé seulement 240 qui ont réussi le test de santé mentale. Cette liste de contrôle n'est pas destinée à remplacer d'autres listes de contrôle ou normes de confidentialité, de sécurité, d'accessibilité, de référencement ou d'écoconception. Il s'agit uniquement de lister les principales règles non numériques vérifiables, réalistes, utiles et universelles qui s'appliquent à un projet Web. une licence ouverte1. Nous avons créé des fiches qui répertorient les objectifs (valeur ajoutée pour les utilisateurs), comment mettre en œuvre la règle (implémentabilité) et comment la vérifier (vérifiabilité). En remarque, les règles ne peuvent pas contenir de chiffres. Nous l'avons appris à nos dépens : après la sortie de la première version, l'une des règles stipulait que les images et la page d'accueil ne pouvaient pas dépasser 150 ko. Cela semblait réaliste en 2004, mais la règle était déjà hors de propos en 2005. Nous avons besoin que les règles restent pertinentes pendant au moins cinq ans, et la détermination de limites numériques nuit gravement au consensus que nous visons à atteindre. Nous avons donc ajouté cette contrainte à notre contrôle de cohérence.

1Les règles sont sous licence ouverte CC-BY-SA (Creative Commons Attribution–ShareAlike License).

Les 240 règles avoir un impact sur chaque rôle dans une équipe Web, des développeurs au support client, de la gestion aux opérations, et des concepteurs UX aux producteurs de contenu. Par exemple, nous avons 35 règles sur 240 relatives à l'écoconception, 23 à la sécurité, 37 au référencement, 126 à l'accessibilité, 38 au commerce électronique.

L'approche la plus logique et la plus évidente consiste à utiliser des listes de contrôle (celle-ci ou autres) comme outils de conception ou de pré-lancement. Dans notre cas, cela signifie que cette liste de contrôle complète peut être utilisée pour les audits, à l'aide de la section de contrôle de chaque règle. Il peut également être utilisé pendant le processus de conception et de conception à l'aide d'extraits de la liste de contrôle.

Cependant, nous avons constaté que l'audit ou le pré-lancement n'était probablement pas la première chose nécessaire pour démarrer efficacement un processus d'assurance qualité Web. Avant d'essayer de respecter les règles, vous devez vous assurer que toute l'équipe impliquée dans un projet Web les comprend, même lorsque les règles ne semblent pas directement liées à leur rôle dans le projet.

 Capture d'écran de trois règles de la liste de contrôle.

Capture d'écran de trois règles de la liste de contrôle. (Source) ( Grand aperçu)

La dernière version de la checklist (240 cartes — 2020) en français, anglais et espagnol : https://checklists.opquast.com/en/web-quality-assurance/.

Comment utiliser les listes de contrôle d'assurance qualité Web ?

À première vue, la chose la plus importante à comprendre dans une règle est la règle elle-même. Mais peut-être que la raison pour laquelle une règle existe est plus intéressante et perspicace. Regardons un exemple avec notre Règle n°233 : « Le texte des documents PDF internes peut être sélectionné. être utile :

  • Le contenu du fichier PDF peut être vocalisé avec un lecteur d'écran ;
  • Le contenu du fichier PDF peut être indexé sur les moteurs de recherche ;
  • Le contenu du fichier PDF peut être recherché ;[19659068]Le contenu du fichier PDF peut être traduit ;
  • Le contenu du fichier PDF peut être copié-collé.

Ces cas d'utilisation peuvent concerner cinq utilisateurs différents :

  1. Un aveugle utilisateur utilisant un lecteur d'écran ;
  2. Un utilisateur qui recherche du contenu sur un moteur de recherche ;
  3. Un utilisateur qui recherche un contenu déterminé dans le document ;
  4. Un utilisateur qui ne parle pas la langue du document et a besoin d'une traduction ;
  5. Un utilisateur qui souhaite réutiliser une partie du contenu du document.

Alternativement, il peut également c oncnera le même utilisateur qui connaîtra les cinq cas ci-dessus. Par exemple, imaginons un scientifique bulgare aveugle, cherchant où il est cité sur le web, trouve un PDF en anglais, puis cherche son nom dans le fichier pdf, le traduit automatiquement en bulgare et termine en copiant-collant un partie du contenu de son portfolio.

Cela signifie qu'avec une seule règle sur 240, on peut identifier cinq contextes où la règle sera utile pour les utilisateurs. Cela signifie que c'est un moyen de déclencher de l'empathie pour les utilisateurs qui sont de l'autre côté de l'écran dans la diversité de leurs contextes.

Par conséquent, la première chose pour un professionnel qui envisage une règle de qualité n'est pas de savoir comment appliquer la règle. lui-même, mais pour comprendre ce que c'est, à qui il s'adresse et pourquoi il existe . Toutes les règles ont un avantage pour les utilisateurs, mais la réalité du projet web est que les professionnels n'ont pas des moyens illimités. Ils doivent donc prendre des décisions et enfin, les professionnels doivent pouvoir prendre des décisions éclairées sur l'application ou non d'une règle.

En tant que professionnel du web, et malgré les moyens limités des projets web dans lesquels vous participer, vous devez être capable d'évaluer objectivement la qualité d'un site, d'argumenter et d'expliquer le fondement de cette évaluation, d'identifier les risques et d'arbitrer en toute connaissance de cause.

L'assurance qualité doit devenir un élément primordial. réflexe pour les équipes intégrées à l'échelle de l'organisation — concepteurs Web, direction, ventes, développeurs, marketing, après-vente, chauffeurs-livreurs — toutes les personnes impliquées dans l'expérience utilisateur.

À ce stade de notre réflexion, nous avons un premier ensemble d'outils pour déployer l'assurance qualité web, mais cela ne veut pas dire que nous avons tout ce qu'il faut pour intégrer l'assurance qualité web et la gestion de la qualité web dans nos processus.

Pour aller plus loin, il faut regarder les risques majeurs de la b.

Où sont les principaux risques d'un projet Web ?

« Une évaluation des risques est l'effort combiné d'identification et d'analyse d'événements potentiels (futurs) susceptibles d'avoir un impact négatif sur les individus, les actifs et/ou l'environnement ( c'est à dire analyse de risque); et porter des jugements "sur la tolérabilité du risque sur la base d'une analyse de risque" tout en tenant compte des facteurs d'influence (c'est-à-dire l'évaluation du risque). l'industrie a appris à ses dépens que, oui, les activités Web comportent des risques abondants. De même dans d'autres industries comme l'aéronautique, l'automobile ou la santé ; chaque risque doit être classé en tenant compte de son caractère critique ou non (analyse des risques).

Apprécier un risque comme critique est toujours en partie subjectif. Ainsi, dans le cas de l'industrie du web, j'ai trouvé quatre sujets où les risques sont particulièrement critiques. Trois de ces sujets (accessibilité, sécurité et confidentialité) ont des conséquences potentielles majeures pour les utilisateurs. Ces conséquences peuvent également affecter négativement votre image de marque et votre entreprise. Elles peuvent entraîner des problèmes insurmontables pour les utilisateurs, des pertes de revenus et des litiges.

Le dernier sujet que j'ai choisi (l'écoconception) est également critique d'un point de vue systémique avec des conséquences potentielles majeures sur nos vies personnelles et professionnelles.

Là. Il y a beaucoup de problèmes qui peuvent vraiment nuire à votre entreprise (mauvaises performances, mauvaise conception UX, référencement insuffisant, etc.), mais en général, ils ne feront pas autant de mal que les quatre que j'identifie ci-dessous. Les quatre sujets énumérés sont de loin les plus critiques pour vous, les entreprises et les clients avec lesquels vous travaillez et, en premier lieu, les utilisateurs.

Ces quatre sujets et leurs risques associés sont présents dans tous les projets Web. Jetons-y un coup d'œil :

  1. Accessibilité
    Mon site est-il accessible aux personnes handicapées ? Suis-je discriminatoire envers certaines personnes ? Si oui, quels sont les risques ?
    Dans un rapport publié par Accessibility.comil a été estimé que 265 000 lettres de demande d'accessibilité de sites Web ont été envoyées aux entreprises l'année dernière, ce qui a conduit les entreprises américaines à dépenser peut-être des milliards de en dollars de frais juridiques résultant directement de sites Web inaccessibles rien qu'en 2020 (Source : BOIA).
  2. Sécurité
    Mon projet met-il en danger mon organisation, mes collègues ou les utilisateurs ? Si oui, quels sont les risques ?
    En 2020, selon govtech.com, il y a eu une augmentation de 141% des enregistrements compromis dus à des violations de données par rapport à 2019. De loin le plus grand nombre d'enregistrements exposés en une seule année depuis qu'ils ont été rapports sur les activités de violation de données (www.govtech.com). Ils ont également signalé que le coût moyen d'une violation de données était de 3,86 millions de dollars en 2020. (Source : IBM).
  3. Confidentialité
    Est-ce que je mets les données de mon entreprise, mes utilisateurs les données de mes employés en danger ? Quelles sont les conséquences potentielles ?
    Le règlement général sur la protection des données (RGPD) est entré en vigueur en mai 2018. Le RGPD permet aux autorités de protection des données de l'UE d'infliger des amendes pouvant aller jusqu'à 20 millions d'euros (24,1 millions de dollars) ou 4 % du montant annuel. chiffre d'affaires global (selon le plus élevé). […] Les sanctions prévues par le RGPD s'élevaient à 158,5 millions d'euros (191,5 millions de dollars). (Source : Tessian).
  4. Ecodesign
    Quel est l'impact environnemental de mon projet ? Dans quelle mesure mon projet contribue-t-il au changement climatique ?
    L'association The Shift Project a examiné près de 170 études internationales sur l'impact environnemental des technologies numériques. Selon les experts, leur part dans les émissions mondiales de CO2 est passée de 2,5 à 3,7 % entre 2013 et 2018 […] Le Borderstep Institute compare différentes études et conclut que les émissions de gaz à effet de serre causées par la production, l'exploitation et l'élimination des les terminaux et les infrastructures représentent entre 1,8 et 3,2 % des émissions mondiales (à partir de 2020). (Source : RESET).

Nous ne pouvons pas nous permettre d'ignorer l'un des risques mentionnés. Au cours des dix dernières années, ces risques et leurs conséquences ont augmenté, entraînant des coûts croissants, des échecs de refonte, des poursuites judiciaires, des cyberattaques, un épuisement professionnel, un taux de rotation élevé, un impact environnemental, etc. Comme nous pouvons le voir dans les exemples précédents, tout cela a des coûts financiers, humains, sociaux et environnementaux, qui doivent tous être évités dans notre industrie.

Quatre risques critiques du projet web

Quatre risques critiques sujets de le projet web. (Elie Sloïm — 2016) ( Grand aperçu)

Ce que nous voyons maintenant avec le Web n'est qu'une phase de maturation très classique d'une jeune industrie où, progressivement, les normes, les méthodes et les cadres se déploient à mesure que les clients exigent une qualité supérieure et que les fournisseurs se fixent des objectifs de qualité pour y parvenir. Des risques et des domaines disparates tels que l'accessibilité, l'écoconception, les performances, la sécurité et la confidentialité sont de plus en plus structurés, standardisés et soumis aux lois et réglementations nationales.

Regardons ce qui a émergé dans les industries établies confrontées à une gestion de la qualité similaire. équations à résoudre.

Vers une gestion de la qualité Web interdisciplinaire

Au tournant des années 80, les professionnels de la gestion de la qualité travaillaient principalement sur des problèmes de qualité, en utilisant principalement la norme ISO9000. Le contrôle qualité, l'assurance qualité et la gestion de la qualité étaient les seules matières que j'ai apprises vers 1990. Cependant, il y avait d'autres personnes travaillant sur un ensemble différent de risques avec des normes : ISO14000 était la référence pour l'environnement et ISO 27000 pour la sécurité informatique.

La conformité et le déploiement de ces normes de gestion ont été pilotés par des départements distincts des entreprises industrielles. À un moment donné, parce que toutes les normes étaient liées et probablement parce qu'il y avait beaucoup de tâches et d'outils à mutualiser, les entreprises ont créé HQSE (Heath Qualité Ssécurité Environment). Ce type d'approche est appelé « systèmes de gestion intégrés » :

« Il était une fois un responsable H&S (santé et sécurité) dont le rôle s'est élargi à un HSE (santé, sécurité et environnement) directeur. A la même époque, il y avait un responsable qualité dont les rôles étaient complètement séparés du superviseur HSE. Mais à mesure que la technologie s'intégrait de plus en plus dans le flux de travail et que la demande de services et de produits rapides et de qualité augmentait, les rôles ont fusionné en un seul responsable QHSE. 19659006] Il y a quelque chose de vraiment important à savoir sur la gestion de la qualité ou les systèmes de gestion intégrés, c'est qu'ils ne « produisent » pas de la qualité, ils ne fournissent pas de conformité environnementale ou de sécurité. Ils aident simplement le reste de l'organisation à maîtriser et à améliorer ces sujets. Aucune des personnes de ces départements ne remplace les experts, ils leur fournissent simplement les outils, les normes, l'automatisation des machines, etc. Ils aident tout le monde à rester à jour et à interagir avec les clients lorsqu'une entreprise doit prouver qu'elle sera capable de fournir un certain niveau de qualité.

Maintenant, il est temps pour moi de faire un pari sur l'avenir. Comme cela s'est produit dans des industries déjà établies comme l'aéronautique, l'automobile et la médecine, l'assurance qualité a été introduite comme conséquence directe de la perception des risques. Les équipes web gèrent déjà les risques séparément, mais si les utilisateurs sont concernés par chacun d'eux, nous aurons besoin d'une approche transversale qui rassemble tous les sujets que nous devons traiter lors de la construction ou de la maintenance d'un projet web.

C'est ça. trop tôt pour dire exactement ce qui se passera en détail, mais ce que j'envisage, c'est l'intégration d'une nouvelle couche d'assurance qualité Web qui assemblera, maintiendra et rapprochera les différents métiers et domaines du Web. Cet article

Au cours de mon parcours (qui, j'espère, n'est pas terminé 🙂), j'ai appris pas mal de choses.

Pour que nous puissions déployer l'assurance qualité Web, nous devons comprendre les exigences des utilisateurs et les conséquences pour les métiers web impliqués dans un projet web. Pour en revenir au modèle VPTCS, l'une des choses les plus importantes que nous ayons observées est que la partie Visibilité et Services est fréquemment sous-estimée par les équipes Web, en particulier par les propriétaires de sites Web.

Nous avons également observé que les deux exigences qui apportent le la valeur la plus élevée pour les utilisateurs sont les content et services. Cependant, il est fréquemment perçu que les professionnels du Web travaillant dans des rôles qui relèvent des catégories Visibilité, Perception et Technique sont les plus importants dans le projet Web. Ils ne peuvent pas fonctionner sans un contenu et des services de haute qualité (support, logistique, livraison, etc.) qui s'intègrent de manière transparente au sein de l'équipe de projet Web. travail visuel et ergonomique. Montrer que l'UI est un mélange de perception, de technique et de contenu permet de créer moins de malentendus entre les différentes équipes travaillant à distance. Cela nous amène au besoin d'équipes unifiées impliquant et faisant travailler ensemble tous les métiers. , des audits manuels, des listes de contrôle, etc. Le web voit l'assurance qualité augmenter progressivement, mais en ce qui me concerne, nous ne sommes qu'au tout début de la route. Pour commencer, les listes de contrôle sont des outils très simples qui peuvent être utilisés pour atteindre la conformité, mais aussi pour partager une culture et un vocabulaire communs.

Les équipes Web peuvent utiliser des listes de contrôle pour la conformité, mais selon ma propre expérience, si vous souhaitez améliorer la conformité. et si vous souhaitez que l'assurance qualité Web soit déployée de manière durable dans votre organisation, il est plus efficace de commencer par créer une culture de la qualité Web avec un vocabulaire commun et un cadre de base à partir duquel démarrer.

« 63 % des personnes qui sont dans un processus de transformation numérique disent que la culture est la barrière numéro un….56% ont déclaré que la collaboration inter-services était leur 3ème plus grand défi. est de créer un socle culturel de partage des risques — comme celui que j'ai évoqué et tous les autres — et des responsabilités orientées vers les utilisateurs. Un ensemble de règles global est l'une des solutions que vous pouvez utiliser pour responsabiliser les équipes Web et créer une culture et un vocabulaire globaux, mais il doit également être accompagné d'un système global de gestion des risques mutualisés pour les projets Web. . Ce système de gestion doit prendre en charge un ensemble global de règles, de normes et d'outils pouvant faire appel à des experts spécialisés pour des problèmes complexes. les utilisateurs, les clients et les meilleurs intérêts des citoyens.

Le voyage continue.

Autres lectures

Smashing Editorial" width="35" height="46" loading="lazy" decoding=" async(ah, vf, yk, il)




Source link

0 Partages