J'ai posé une question ici pour faire une recommandation sur une mise à niveau sur la sélection de la palette de couleurs.
Nous avons un tableau de bord qui contient de nombreuses cases affichant du texte. Vous pouvez changer la couleur des cases et du texte comme vous le souhaitez.
L'une de mes suggestions était de remplacer la palette de couleurs d'un sélecteur RVB complet par une sélection de couleurs plus petite, car l'utilisateur est le moins susceptible de faire la différence entre quelque chose comme:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
... s'ils ne sont pas assez proches (oui, ce sont deux nuances de rouge différentes).
Une autre idée était de limiter les combinaisons texte/arrière-plan pour assurer un bon contraste
Mon collègue m'a dit que "l'utilisateur devrait pouvoir choisir un fond noir sur du texte noir si c'est ce qu'il voulait", j'ai répondu que je n'étais pas d'accord. Spécifiquement avoir l'exemple de berceau donné dans cette vidéo TED de la minute 6:00 à la minute 9:00.
La vidéo dit:
Vous voulez rendre difficile une mauvaise utilisation. Vous voulez faire de la bonne façon de l'utiliser la manière la plus simple de le faire.
Donc ma question est:
Vaut-il mieux Limiter l'utilisateur dans les choix de couleurs qu'il peut faire afin d'assurer une meilleure expérience utilisateur? (Pour une raison que je ne peux pas arrêter de penser à Steve Jobs en ce moment).
BONUS: Citer Hick's Law me ferait vraiment plaisir (le cas échéant). Je veux voir quel est l'impact sur la loi de Hick sur une palette de couleurs 32 bits :)
Autoriser les utilisateurs finaux à modifier les couleurs de l'interface utilisateur conduit les utilisateurs à utiliser le thème Hot Dog dans Windows 3 ou tout autre thème à pois dans SharePoint.
C'est un "ooh soigné!" fonctionnalité qui offre peu ou pas de valeur et, souvent, est un énorme préjudice pour chaque personne qui doit utiliser le site.
Je pouvais voir offrir quelques options bien conçues et bien conçues, mais laisser les gens faire au hasard comme ils le souhaitent dans la plupart des cas entraînera des résultats hémorragiques.
Laissez-les choisir facilement l'arrière-plan avec un ensemble initial limité de couleurs, en l'étendant à un nombre illimité - et basculez automatiquement (en fonction des mathématiques chromatiques) la couleur de premier plan entre un clair et un sombre pour donner un bon contraste.
Balsamiq le fait automatiquement. Ci-dessous, j'ai créé deux boutons - lorsque j'ai changé l'arrière-plan du bouton droit en rouge, il a automatiquement basculé le texte de premier plan en blanc. Un utilisateur ambitieux pourrait changer la couleur du texte en Fuchsia, mais la plupart des utilisateurs se soucieront probablement le plus de la couleur d'arrière-plan.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Cela dépend de l'intérêt des différentes couleurs: est-ce uniquement pour la personnalisation, par exemple. les couleurs du tableau de bord ne sont pas conçues pour un public, mais plutôt pour vous-même?
Dans le cas où il s'agit d'une personnalisation, la question suivante concerne le nombre de boîtes de tableau de bord: quel est le montant probable que vous aurez?
Il se peut que si vous avez une centaine de cases, vous souhaitez avoir un arrière-plan similaire, un premier plan différent pour avoir un sous-groupe, alors que s'il n'y en a qu'une douzaine ou deux, il suffit d'avoir des groupes basés sur un seul schéma de couleurs.
Dans le cas où le premier, vous feriez mieux de donner un accès à grain fin, bien que cela soit suffisant pour le faire avec des "crayons de couleur": OS X vous donne la possibilité de choisir parmi une palette prédéfinie de manière intuitive:
Faites cela pour les deux couleurs.
Dans ce dernier cas, il est préférable de fournir des schémas prédéfinis, un "sélecteur de thème": affichez un exemple de widget dans chaque jeu de couleurs avec un nom.
deux thèmes dans un sélecteur de thème: je suis presque sûr que MS Word a de meilleurs exemples ...
Dans le cas où cela s'adresse à un public public, il est préférable de laisser aux utilisateurs un contrôle précis. Cela signifie, un sélecteur de palette de couleurs pour les deux couleurs ...
Je pense que vous êtes sur la bonne voie - un ensemble limité d'options est probablement ce que j'irais avec. (À moins que votre application ne soit une sorte de sélecteur de couleur ou de conception.) Dans mon esprit, la principale raison pour laquelle vous utiliseriez un sélecteur de couleur est lorsque l'utilisateur doit mettre une couleur exacte. Ce n'est probablement pas votre situation, alors je serais discret.
En supposant que vous ne fassiez pas le prochain Photoshop, je ferais suffisamment d'options discrètes pour couvrir vos utilisations. Autrement dit, si l'utilisateur moyen a besoin d'utiliser ~ 10 couleurs différentes, donnez-leur entre 20 et 30 et voyez comment cela se passe dans les tests utilisateur.
Utilisez un prototype papier pour tester explicitement certains scénarios clés qui nécessitent beaucoup de couleurs. Découvrez comment les utilisateurs réagissent.
Et, je resterais probablement loin du noir sur noir. Faire des options comme ça ne semble pas avoir beaucoup de sens. (Sauf si vos utilisateurs veulent explicitement cacher des choses ou les rendre déroutants pour les autres. Cela pourrait être intéressant pour un jeu, mais probablement pas ce que vous recherchez.)
Si vous limitez les options, vous devez couvrir tous les cas d'utilisation ou vous échouerez à certains de vos utilisateurs. Dans quelle mesure êtes-vous confiant que vos options couvrent tous les cas d'utilisation?
Quelques cas d'utilisation que vous n'auriez peut-être pas envisagés:
photosensible: le noir/blanc et le blanc/noir sont en fait terribles pour certains utilisateurs; c'est trop contrasté/lumineux. Ces utilisateurs auront plutôt besoin de nuances de gris ou de brun/beige. Si vous connectez en dur vos choix de texte au noir/blanc et offrez, par exemple, 16 couleurs d'arrière-plan (mi-clair, mi-foncé), ce ne sera pas suffisant.
daltonien: vos rouges, verts et jaunes sont-ils vraiment aussi distinctifs que vous le pensez?
catégorisation: comme l'a souligné Aadaam, les utilisateurs peuvent attacher la sémantique à des couleurs similaires mais pas identiques, et si vous enlevez les couleurs similaires qui ne fonctionneront pas.
cohérence avec les autres applications: votre application n'est pas le seul logiciel que l'utilisateur utilise; si vous fournissez des fonctionnalités similaires à une autre application qu'il utilise également, il peut essayer de personnaliser les deux applications de la même manière pour un transfert plus facile.
Étant donné que vous avez déjà le schéma de couleurs le plus permissif, la question ne devrait pas être "pourquoi devrais-je le conserver?" mais "pourquoi devrais-je le supprimer?". Si l'utilisateur ne peut nuire à personne d'autre et peut potentiellement bénéficier de plus d'options de couleur, pourquoi pas le laisser faire?