Meilleures pratiques et principes pour la conception d'interfaces graphiques
Quelle est votre meilleure conception ou principe pratique d'interface utilisateur conviviale?
Veuillez soumettre ces pratiques qui, selon vous, rendent les choses vraiment utiles - quoi qu'il arrive - si cela fonctionne pour vos utilisateurs, partagez-les!
Résumé/Collation
Des principes
- BAISER.
- Soyez clair et précis sur ce qu'une option permettra de réaliser: par exemple, utilisez des verbes qui indiquent l'action qui suivra un choix (voir: Impl. 1).
- Utilisez des actions par défaut évidentes adaptées à ce que l'utilisateur a besoin/veut réaliser.
- Adapter l'apparence et le comportement de l'interface utilisateur à l'environnement/au processus/au public: application autonome, page Web, portable, analyse scientifique, jeu flash, professionnels/enfants, ...
- Réduisez la courbe d'apprentissage d'un nouvel utilisateur.
- Plutôt que de désactiver ou de masquer les options, envisagez de donner un message utile où l'utilisateur peut avoir des alternatives, mais uniquement là où ces alternatives existent. Si aucune alternative n'est disponible, il vaut mieux désactiver l'option - qui indique alors visuellement que l'option n'est pas disponible - ne masque pas les options indisponibles, expliquez plutôt dans une fenêtre contextuelle de la souris pourquoi elle est désactivée.
- Restez cohérent et conforme aux pratiques et au placement des contrôles, comme cela est mis en œuvre dans les applications réussies largement utilisées.
- Dirigez les attentes de l'utilisateur et laissez votre programme se comporter conformément à ces attentes.
- Tenez-vous au vocabulaire et aux connaissances de l'utilisateur et n'utilisez pas la terminologie de programmation/implémentation.
- Suivez les principes de conception de base: contraste (évidence), répétition (cohérence), alignement (apparence) et proximité (groupement).
La mise en oeuvre
- (Voir la réponse de paiNie) "Essayez d'utiliser des verbes dans vos boîtes de dialogue."
- Autoriser/implémenter annuler et rétablir.
Les références
- Consignes relatives à l'expérience utilisateur de Windows Vista [ http://msdn.Microsoft.com/en-us/library/aa511258.aspx]
- Sites Web néerlandais - directives "Drempelvrij" [ http://www.drempelvrij.nl/richtlijnen]
- Consignes d'accessibilité du contenu Web (WCAG 1.0) [ http://www.w3.org/TR/WCAG10/]
- Consistance [ http://www.Amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746]
- Ne me faites pas penser [ http://www.Amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pdbbssr_1?ie=UTF8&s=books&qid=1221726383&sr=8-1 ]
- Soyez puissant et simple [ http://msdn.Microsoft.com/en-us/library/aa511332.aspx]
- Lois sur la conception de la Gestalt [ http://www.squidoo.com/gestaltlaws]
Essayez d'utiliser des verbes dans vos boîtes de dialogue.
Cela signifie utiliser
au lieu de
Je teste mon interface graphique contre ma grand-mère.
Suivez les principes de conception de base
- [~ # ~] c [~ # ~] ontrast - Rendre les choses différentes regardez différentes
- [~ # ~] r [~ # ~] epetition - Répéter le même style sur un écran et pour les autres écrans
- [~ # ~] a [~ # ~] alignement - Alignez les éléments de l'écran! Oui, cela inclut du texte, des images, des contrôles et des étiquettes.
- [~ # ~] p [~ # ~] roximité - Regroupez les éléments associés. Un ensemble de champs de saisie pour saisir une adresse doit être regroupé et distinct du groupe de champs de saisie pour saisir les informations de carte de crédit. C'est de base lois de conception de Gestalt .
Jamais demandez "Êtes-vous sûr?". Autorisez simplement des annulations/restaurations illimitées et fiables.
Essayez de penser à ce que votre utilisateur veut réaliser au lieu de ce que sont les exigences.
L'utilisateur entrera dans votre système et l'utilisera pour atteindre un objectif. Lorsque vous ouvrez calc, vous devez effectuer un calcul simple et rapide dans 90% des cas, c'est pourquoi par défaut, il est réglé en mode simple.
Alors ne pensez pas à ce que l'application doit faire mais pensez à l'utilisateur qui le fera, probablement ennuyé, et essayez de concevoir en fonction de ses intentions, essayez de lui faciliter la vie.
Si vous faites quoi que ce soit pour le Web, ou toute application logicielle frontale d'ailleurs, vous vous devez vraiment de lire ...
Fil d'Ariane dans les webapps:
Dites -> L'utilisateur -> Où -> Elle -> Est dans le système
C'est assez difficile à faire dans les systèmes "dynamiques" avec plusieurs chemins vers les mêmes données, mais cela aide souvent à naviguer dans le système.
J'essaie de m'adapter à l'environnement.
Lorsque je développe pour une application Windows, j'utilise les Windows Vista User Experience Guidelines mais lorsque je développe une application Web, j'utilise les directives appropriées, car je développe des sites Web néerlandais, j'utilise " Drempelvrij "guidelines qui sont basés sur les Web Content Accessibility Guidelines (WCAG 1.0) du World Wide Web Consortium (W3C).
La raison pour laquelle je fais cela est de réduire la courbe d'apprentissage d'un nouvel utilisateur.
Je recommanderais d'acquérir une bonne compréhension solide de la conception graphique en lisant le livre The Design of Everyday Things. Bien que l'imprimable principal soit un commentaire de Joel Spolsky: lorsque le comportement de l'application diffère de ce que l'utilisateur attend alors vous avez un problème avec votre interface utilisateur graphique.
Le meilleur exemple est, quand quelqu'un échange autour du OK et Cancel sur certains sites Web. L'utilisateur attend la OK bouton à gauche et le bouton Cancel bouton à droite. Donc, en bref, lorsque le comportement de l'application diffère de ce que l'utilisateur attend de ce qui se passe, vous avez un problème de conception d'interface utilisateur.
Cependant, le meilleur conseil, quel que soit le modèle ou le modèle de conception que vous suivez, est de garder la conception et les conventions cohérentes tout au long de l'application.
Évitez de demander à l'utilisateur de faire des choix chaque fois que vous le pouvez (c'est-à-dire ne créez pas de fork avec une boîte de dialogue de configuration!)
Pour chaque option et chaque boîte de message, demandez-vous: puis-je plutôt proposer un comportement par défaut raisonnable
- logique?
- ne gêne pas l'utilisateur?
- est-il assez facile d'apprendre qu'il en coûte peu à l'utilisateur que je lui impose cela?
Je peux utiliser mon ordinateur de poche Palm comme exemple: les paramètres sont vraiment minimalistes, et j'en suis très satisfait. Les applications de base sont suffisamment bien conçues pour que je puisse simplement les utiliser sans ressentir le besoin de peaufiner. Ok, il y a des choses que je ne peux pas faire, et en fait j'ai dû m'adapter en quelque sorte à l'outil (au lieu du contraire), mais au final cela me facilite vraiment la vie.
Ce site Web est un autre exemple: vous ne pouvez rien configurer, et pourtant je le trouve vraiment agréable à utiliser.
Les valeurs par défaut raisonnables peuvent être difficiles à comprendre, et de simples tests d'utilisabilité peuvent fournir de nombreux indices pour vous aider.
Montrez l'interface à un échantillon d'utilisateurs. Demandez-leur d'effectuer une tâche typique. Surveillez leurs erreurs. Écoutez leurs commentaires. Apportez des modifications et répétez.
Lorsque vous créez des messages d'erreur, faites en sorte que le message d'erreur soit la réponse à ces 3 questions (dans cet ordre):
Qu'est-il arrivé?
Pourquoi est-ce arrivé?
Que peut-on y faire?
Il s'agit de "Human Interface Guidelines: The Apple Desktop Interface" (1987, ISBN 0-201-17753-6), mais il peut être utilisé pour n'importe quel message d'erreur n'importe où. Il y a un - version mise à jour pour Mac OS X. La page Microsoft Messages d'interface utilisateur dit la même chose: "... dans le cas d'un message d'erreur, vous devez inclure le problème, le et l'action de l'utilisateur pour corriger le problème. "
Incluez également toute information connue du programme, pas seulement une chaîne fixe. Par exemple. pour la partie "Pourquoi est-ce arrivé" du message d'erreur, utilisez "Fichier de spectre brut L:\refDataForMascotParser\TripleEncoding\Q1LCMS190203_01Doub leArg.wiff n'existe pas" au lieu de "Fichier n'existe pas".
Comparez cela avec le tristement célèbre message d'erreur: "Une erreur s'est produite.".
La conception des choses de tous les jours - Donald Norman
Un canon de la tradition du design et la base de nombreux cours HCI dans les universités du monde entier. Vous ne concevrez pas une excellente interface graphique en cinq minutes avec quelques commentaires d'un forum Web, mais certains principes orienteront votre réflexion dans le bon sens.
-
MC
Utilisez des fonctionnalités animées discrètes/simples pour créer des transitions fluides d'une section à l'autre. Cela aide l'utilisateur à créer une carte mentale de navigation/structure.
Utilisez des titres courts (un mot si possible) sur les boutons qui décrivent clairement l'essence de l'action.
Utilisez le zoom sémantique dans la mesure du possible (un bon exemple est le fonctionnement du zoom sur les cartes Google/Bing, où plus d'informations sont visibles lorsque vous vous concentrez sur une zone).
Créez au moins deux façons de naviguer: verticale et horizontale. Vertical lorsque vous naviguez entre différentes sections et horizontal lorsque vous naviguez dans le contenu de la section ou de la sous-section.
Gardez toujours visibles les principaux nœuds d'options de votre structure (là où la taille de l'écran et le type d'appareil le permettent).
Lorsque vous allez profondément dans la structure, gardez toujours un indice visible (par exemple sous la forme d'un chemin) indiquant où vous êtes.
Masquez les éléments lorsque vous souhaitez que l'utilisateur se concentre sur les données (comme la lecture d'un article ou la visualisation d'un projet). - attention cependant aux points # 5 et # 4.
(Volé à Joel: o))
Ne désactivez pas/supprimez les options - donnez plutôt un message utile lorsque l'utilisateur clique/sélectionne.
Comme mon professeur de structure de données l'a souligné aujourd'hui: donnez des instructions sur le fonctionnement de votre programme à l'utilisateur moyen. Nous, les programmeurs, pensons souvent que nous sommes assez logiques avec nos programmes, mais l'utilisateur moyen ne saura probablement pas quoi faire.
Avec les interfaces graphiques, les normes sont spécifiques à la plate-forme. Par exemple. Lors du développement de l'interface graphique dans Eclipse, cette lien fournit des directives décentes.
Oh, et embauchez un designer/apprenez des compétences en design. :)
J'ai lu la plupart de ce qui précède et une chose que je ne vois pas mentionnée:
Si les utilisateurs sont censés utiliser l'interface UNE FOIS, ne montrer que ce dont ils ont besoin si possible est génial.
Si l'interface utilisateur doit être utilisée à plusieurs reprises par le même utilisateur, mais peut-être pas très souvent, il est préférable de désactiver les contrôles que de les masquer: la modification de l'interface utilisateur et les fonctionnalités cachées n'étant pas évidentes (ou mémorisées) par un utilisateur occasionnel sont frustrantes pour l'utilisateur.
Si l'interface utilisateur doit être utilisée TRÈS RÉGULIÈREMENT par le même utilisateur (et qu'il n'y a pas beaucoup de roulement dans le travail, c'est-à-dire pas beaucoup de nouveaux utilisateurs se connectant tout le temps), la désactivation des contrôles est absolument utile et l'utilisateur deviendra habitués aux raisons pour lesquelles les choses se produisent mais les empêchant d'utiliser accidentellement les commandes dans des contextes inappropriés sont appréciés et évitent les erreurs.
Juste mon avis, mais tout cela revient à comprendre votre profil d'utilisateur, pas seulement ce qu'une session utilisateur unique pourrait impliquer.