Quel est l'obstacle à un processus de conception basé sur les données?
De nombreuses organisations et agences gouvernementales adoptent les principes de conception GOV.UK - GDS, ce qui a certainement eu pour conséquence que la tendance des sites Web gouvernementaux devient moins encombrée et moins axée sur le contenu. Cependant, je pense que cela ne va vraiment que jusqu'à l'esthétique visuelle et les interactions de base du site Web, et en ce qui concerne les transactions et les processus des utilisateurs, les directives sont beaucoup plus difficiles à mettre en œuvre.
L'illustration la plus significative de cela, je crois, est le principe numéro 3: Design with Data .
En fait, je dirais que ce principe de conception ne va pas assez loin et devrait être Conception utilisant des données car il ouvre alors la discussion sur de meilleures normes dans la mise en œuvre de l'infographie et de la visualisation des données dans les sites Web du gouvernement qui aident également les utilisateurs à prendre des décisions (pas seulement les administrateurs du site Web et les gestionnaires/dirigeants du gouvernement), et il est également lié à l'initiative des données ouvertes.
Je suis intéressé à découvrir quels sont les obstacles aux processus de conception basés sur les données dans diverses entreprises et organisations. Je pense que les principaux obstacles sont les suivants:
- Normes uniformes/unifiées pour la collecte et la gestion des données
- Manque de compréhension des meilleures pratiques de conception des informations/données
- Manque de transparence des données au sein de l'organisation
- Manque de compréhension des meilleures pratiques de recherche/test
Y en a-t-il d'autres que je ne connais pas qui pourraient également y contribuer?
La conception de visualisations de données est un sujet différent de la conception avec des données. Ce n'est pas parce qu'ils partagent les données Word qu'ils ont un chevauchement ou une synergie important, sinon nous pourrions également regrouper les bases de données. Ce dernier consiste à utiliser des statistiques sur les comportements, l'utilisation et les utilisateurs (réels et potentiels) pour guider et améliorer un produit - l'étude de marché numérique. La première consiste à concevoir une interface visuellement orientée qui révèle le sens/les modèles/les valeurs aberrantes dans des combinaisons spécifiques de types de données, de tâches et d'utilisateurs. Les modèles et processus pour cela sont différents avec des nuances marquées, par ex. voir:
https://www.cs.ubc.ca/labs/imager/tr/2009/NestedModel/NestedModel.pdf doi: 10.1109/TVCG.2009.111
http://publik.tuwien.ac.at/files/PubDat_223990.pdf doi: 10.1016/j.cag.2013.11.002
Je pense que votre liste est un bon début! Ces quatre sont difficiles, et ensemble, ils pointent vers un problème encore plus important: Manque de ressources pour implémenter et maintenir un régime de métriques d'utilisation.
Les phases et les composants des projets logiciels basés sur le Web forment une sorte de Hiérarchie des besoins de Maslow , où les parties prenantes du projet considèrent certains composants comme critiques et d'autres comme "agréables à avoir". Lorsque les ressources pour la réalisation d'un projet sont limitées, comme elles le sont presque toujours, les choses en bas de la liste sont coupées.
Voici ce que je vois être les priorités typiques, du plus essentiel au moins essentiel:
- Construire (c'est-à-dire le coder et le déployer)
- Développement du contenu
- Conception graphique
- Possibilité pour les parties prenantes non techniques de mettre à jour le contenu (aka CMS)
- Itération progressive (c.-à-d. Amélioration au fil du temps)
- Architecture de l'information
- UX Design
- QA
- Accessibilité
- Implémentation et maintenance d'un régime de métriques d'utilisation
Encore une fois, ce n'est pas une liste de priorités mon, mais ce que j'ai vu au cours de mes 18 années de création de sites Web et d'applications Web.
Je pense que le cœur du problème que vous signalez est que les gens ont tendance à privilégier l'itération progressive SUR la mise en œuvre d'un régime de métriques d'utilisation - lorsque vous et moi savons que vous ne pouvez pas faire efficacement le premier sans le second.
Je pense que ce que vous devriez également considérer, c'est que les entreprises qui se concentrent sur la création de nouvelles applications/web/logiciels, quel que soit le projet, n'auront probablement pas de données pour prendre de telles décisions. Bien sûr, il y a de la recherche mais rien ne peut remplacer la vraie analyse.
Je ne pense pas Concevoir (uniquement) en utilisant des données est la bonne façon. Le design sera toujours qualitatif, subjectif et animé par l'expertise.
Vous n'obtiendrez jamais une bonne conception uniquement basée sur des chiffres. Peut-être que vous obtenez un design moyen et agréable, car il sera attrayant à 50%. Les concepteurs apprennent généralement à l'Université pourquoi et comment ils décident/choisissent pour la création, ceci est également guidé par des règles de conception objectives et établies.
Les données peuvent prendre en charge la conception mais ne mènent jamais. Les données peuvent vous indiquer le "comment" et le "combien", mais jamais le "pourquoi". Et même les données doivent être interprétées pour être informatives. Et ce sont les obstacles - cela n'a pas de sens de n'utiliser que des données ou des données comme force principale pour la conception.
Aucune entreprise (malgré Facebook et al) ne collectera de données sans aucun scénario d'utilisation. Mettre en place l'infrastructure et alimenter les serveurs coûte de l'argent. Donnez-leur une analyse de rentabilité décente pour la collecte de données et les dirigeants la collecteront. Le simple fait de leur dire "Hé, les données sont les nouvelles choses" ne convaincra personne. Parce qu'il y en a d'autres qui pleurent "Devops", "Internet des objets", "Paiement mobile" et et et.