Définition de valeurs par défaut sûres pour la configuration de l'interface utilisateur par le client
Je suis actuellement un consultant travaillant pour une société de développement de logiciels qui construit une application pour leur client. La société de développement estime que chaque aspect de l'interface utilisateur doit être personnalisable, jusqu'à la police. Ainsi, par exemple, si le client utilisant l'application est Porsche, il aurait la possibilité d'utiliser sa propre police propriétaire. Il s'agit d'une application, de lignes et de colonnes de données très TRÈS centrée sur les données.
Bien que je pense que je les ai mis dans des valeurs par défaut sûres pour la configuration des couleurs pour fournir une expérience de marque, mais utilisable, je n'arrive pas à surmonter la police "hump". peu importe le chemin que je prends, ils estiment que le client devrait être en mesure de configurer la police, dans tous les domaines, en fonction des directives de marque de l'entreprise. Je suis allé jusqu'à ces sites Web de sociétés et j'ai montré que le test "lisible" sur ces sites n'est pas la police de marque, mais une police lisible courante.
Ai-je tort ici? Le client final devrait-il être en mesure de configurer l'application jusqu'à la police, ce qui pourrait rendre l'application inutilisable pour son utilisateur final? Ou devrions-nous, en tant que société de développement de logiciels, fournir des "valeurs par défaut sûres" et les empêcher de détruire l'intégrité de l'application?
Quelqu'un peut-il consulter des ressources, des études, donner son avis? Soit je me trompe dans ma lutte pour être une société de logiciels responsable et pour maintenir une sorte de standard, soit je manque lamentablement mon client d'expliquer pourquoi nous devons sauver le client final d'eux-mêmes.
Désolé pour la longue question ... Merci d'avance pour toutes les informations fournies .. Je pourrais vraiment utiliser des faits durs et froids!
À partir de maintenant, vous et la société de développement êtes en désaccord sur une question abstraite.
La réponse la plus utile sera éclairée par des tests sur les utilisateurs, pas seulement la meilleure théorie.
Sortez la bataille des volontés de la question en la reformulant comme suit: la police de l'application doit-elle être corrigée? (Ou la police de l'application doit-elle varier?)
Avec des tests A/B simples de paires de polices, vous pouvez découvrir: des polices de plus en moins utilisables comment la variation de police de l'application affecte les utilisateurs
À partir de là, reprenez-vous pour décider d'abord si l'application aura une police fixe, ensuite, sinon quel ensemble de polices l'application offrira aux utilisateurs.
Les questions d'efficacité de l'image de marque visuelle sont noueuses, voire inconnaissables. Limitez votre définition des objectifs de marque à une définition pouvant être prise en charge quantitativement. Ainsi, au lieu de "bon/mauvais pour la marque", demandez "aide/nuit à la réalisation efficace par l'utilisateur de l'objectif de son application".
Todd a tout à fait raison de souligner que des données illisibles rendraient l'application effectivement cassée.
Être capable de donner un sens aux données, en particulier lorsqu'elles sont nombreuses, dépend d'abord de pouvoir les lire correctement. La typographie et d'autres pratiques de conception d'informations sont ce qui rend cela possible, et il y a de bonnes raisons de ne pas inviter les utilisateurs finaux qui ne sont probablement pas familiarisés avec la conception à le changer: vous ne voulez pas que les gens se personnalisent dans des affichages erronés ou incomplets
Lorsque vous devez essayer d'étendre les paramètres par défaut de sécurité que vous pouvez fournir, c'est dans le domaine de l'accessibilité, il vous incombe donc de choisir certains paramètres qui conviennent aux personnes utilisant des appareils et accessoires fonctionnels ou ayant une vision réduite.
Il ne s'agit donc pas d'une solution unique lorsqu'il s'agit de valeurs par défaut sûres, et c'est peut-être ce qui retarde la discussion avec votre client. Au lieu de cela, il s'agit de décisions bien informées sur la façon de rendre les données lisibles, et de ne pas déranger l'utilisateur final pour comprendre comment y arriver. Voilà notre travail.
Il semble que vous compreniez les risques liés à l'ajout de la fonctionnalité. Je le dirais à votre client directement et gardez vos armes à feu.
Vous êtes là pour consulter et vous le déconseillez en raison des implications de l'ajout de la fonctionnalité. Je n'y vois aucun mal.