Techniques de conception de L'interface graphique pour améliorer l'expérience de l'utilisateur [fermé]

si vous posez une question à l'utilisateur, n'en faites pas une question oui/non. Prenez le temps de faire une nouvelle forme et mettez les verbes comme choix comme dans mac.

par exemple:

 Would you like to save?    
     Yes        No

Devrait Être:

  Would you like to save?
    Save        Don't Save 

il y a une explication plus détaillée ici.

découvrez le grand livre Don't make me think par Steve Krug.

Il est axé sur le web, mais beaucoup de conepts peuvent s'appliquer à n'importe quoi, des mélangeurs aux tableaux de bord de voiture.

Sujets abordés:

• les habitudes de l'Utilisateur
• Conception pour la numérisation
• utilisation judicieuse de la copie
• conception de Navigation
• page D'accueil mise en page
• tests d'Utilisabilité

Il a aussi un blog appelé "1519230920 Avancée" Sens Commun

et certains liens aléatoires liés à L'assurance-chômage:

- Conception de l'Interface Utilisateur pour les Programmeurs par Joel Spolsky

- 10 Cauchemars D'Utilisabilité Vous Devez Être Conscient De

First Principles: Wilfred James Hansen

• connaître l'utilisateur
• Réduire La Mémorisation
• Optimiser Les Opérations
• ingénieur pour erreurs

Agrandissements Ultérieurs: Dr. Theo Mandel

placer les utilisateurs en contrôle

• utiliser les Modes judicieusement (modeless)
• permettent aux utilisateurs d'utiliser le clavier ou la souris (flexible)
• permet aux utilisateurs de changer de Focus (interruptible)
• afficher les Messages descriptifs et le texte (utile)
• Immédiate et Réversible Actions, et les Commentaires (pardonner)
• de Fournir des Chemins d'accès et les Sorties (navigable)
• répondre aux besoins des Utilisateurs avec Différents Niveaux de Compétence (accessible)
• Rendre l'Interface Utilisateur Transparente (facilitation)
• permettent aux utilisateurs de personnaliser l'Interface (préférences)
• permettent aux utilisateurs de manipuler directement les objets de L'Interface (interactif)

Réduire Utilisateurs De La Charge Mémoire

• Soulager la Mémoire à Court terme (rappelez-vous)
• S'appuient sur la reconnaissance, pas sur le rappel (reconnaissance)
• Fournit Des Indices Visuels (informer)
• Fournissent les valeurs par Défaut, Undo et Redo (pardonner)
• Fournir de l'Interface Raccourcis (fréquence)
• promouvoir une syntaxe objet-action (intuitif)
• utiliser des métaphores du monde réel (transfert)
• Divulgation Progressive Par L'Utilisateur (context)
• promouvoir la clarté visuelle (organiser)

Rendre l'Interface Cohérente

• maintenir le contexte des tâches des utilisateurs (continuité)
• maintenir L'uniformité à l'intérieur et entre les produits (expérience)
• garder les mêmes résultats D'Interaction (attentes)
• Fournir de l'Esthétique et de l'Intégrité (attitude)
• encourager L'Exploration (prévisible )

pour ajouter à votre liste, aku, je mettrais explorabilité comme l'une de mes plus grandes priorités. En gros, je veux que l'utilisateur se sente en sécurité en essayant les fonctionnalités. Ils ne devraient jamais renoncer à utiliser quelque chose de peur que leur action pourrait être irréversible. Le plus souvent, cela est mis en œuvre en utilisant des commandes undo/redo, mais d'autres options sont sans doute disponibles, par exemple des sauvegardes automatiques.

aussi, pour les applications qui sont plus axées sur le processus (plutôt que des applications de saisie de données), je considérerais la mise en œuvre d'une interface que guide l'utilisateur un peu plus. Microsoft Inductive normes d'Interface Utilisateur peut aider ici, mais vous devez être très prudent de ne pas exagérer, comme vous pouvez facilement ralentir l'utilisateur vers le bas trop.

enfin, comme pour tout ce qui inclut du texte, rendez l'interface utilisateur aussi scannable que possible. Par exemple, si vous avez des rubriques sous quelles commandes / options apparaissent, pensez à mettre le mot action au début, plutôt qu'un mot question. Le point que fait Maudite est aussi un bon exemple de scannabilité, car le texte du bouton "Ne pas Sauvegarder" ne s'appuie pas sur le contexte du paragraphe précédent.

une technique utile que je ne vois jamais personne utiliser est d'ajouter un infobulletin pour un contrôle de L'UI désactivé expliquant pourquoi le contrôle est désactivé. Donc s'il y a une liste de diffusion qui est désactivée et qu'on ne sait pas pourquoi elle est désactivée, je veux la survoler et elle me dit pourquoi elle est désactivée. Je veux voir quelque chose comme "il est désactivé parce que deux boîtes de texte sur l'écran ont été laissés vides ou parce que je n'ai pas entré assez de caractères dans un certain champ ou parce que je n'ai pas fait une certaine action.".

j'entre dans soooooo beaucoup de telles situations et c'est frustrant. Parfois je finis par poster dans le forum du logiciel en demandant pourquoi un contrôle est grisé alors qu'un tooltip aurait pu m'aider en une seconde! La plupart de ces logiciels ont des fichiers d'aide qui sont inutiles dans ce genre de scénarios.

essayez de faire comme si vous ne saviez rien de votre logiciel et essayez de l'utiliser. Cependant, ce n'est pas pratique parce que vous avez déjà un certain esprit fixé vers l'application. Alors regardez les développeurs ou Amis utiliser l'application et de regarder les points de douleur et de demander des commentaires.

un des livres classiques pour vous aider à penser au design est" le Design des choses quotidiennes " de Donald Norman. Il donne de grands exemples du monde réel. Par exemple, si vous concevez bien une porte, vous ne devriez jamais avoir à ajouter des étiquettes qui disent "pousser" et "tirer"."Si vous voulez tirer, mettre une poignée; si vous le souhaitez pousser, mettre à plat. Il n'y a aucun moyen de le faire mal, et ils n'ont même pas à y penser.

C'est un bon objectif: rendre les choses évidentes. Si évidente qu'il ne se produit jamais à l'utilisateur de faire la mauvaise chose . S'il y a quatre boutons sur un poêle, chacun en regard d'un œil, il est évident que chaque bouton contrôle l'œil, c'est à côté. Si les boutons sont en ligne droite, tous sur le côté gauche, vous devez les étiqueter et l'utilisateur doit s'arrêter et réfléchir. Mauvaise conception. ne les faites pas penser.

un autre principe: si l'utilisateur fait faire une erreur, il devrait être très facile à défaire . Le logiciel D'image de Google, Picasa, en est un bon exemple. Vous pouvez recoller, recoller et retoucher vos photos autant que vous voulez, et si jamais vous changez d'avis - même un mois plus tard - vous pouvez annuler vos changements. Même si vous enregistrez explicitement vos modifications, Picasa effectue une sauvegarde. Cela libère l'utilisateur pour jouer et explorer, parce que vous n'allez rien blesser.

j'ai trouvé UI Patterns être une référence utile pour ce genre de chose. Il est organisé un peu comme le classique Gof Design Patterns book, avec chaque description de modèle contenant:

• Le problème le modèle résout
• Un exemple de modèle en action
• Exemple de cas d'utilisation pour le modèle
• la solution pour mettre en œuvre le modèle
• Justification de la solution

si vous mettez en œuvre une recherche, faites-en une recherche en direct comme ce que Locate32 et Google Suggest fait maintenant. Je suis tellement habitué à ne pas appuyer sur "Entrée" dans la boîte de recherche maintenant.

Eh bien, une chose qui peut être évidente: ne changez pas (même légèrement) la position, la couleur, la taille de la police, etc. des boutons, des menus, des liens, etc. entre les écrans s'ils font le même type d'action.

Vraiment bon retour est extrêmement important. Même des choses simples comme rendre évident ce qui peut et ne peut pas être cliqué peuvent être négligées ou trop subtiles. Commentaires quand quelque chose pourrait se passer à l'arrière-plan est excellent. Dans gmail, c'est génial qu'il y ait un ruban d'état qui apparaît en haut qui vous permet de savoir si quelque chose envoie ou charge, mais c'est encore mieux qu'il vous permette de savoir que quelque chose a envoyé avec succès ou est encore chargement.

la technique "yellow fade" est quelque chose d'autre rendu populaire parmi la foule des RoR qui accomplit quelque chose de similaire. Vous ne voulez jamais que l'utilisateur pose la question, " Qu'est-ce qui vient juste de se passer?"ou" que se passera-t-il quand je ferai ça?".

un autre truc qui est devenu plus populaire dernièrement que j'ai beaucoup utilisé est l'édition en place. Au lieu d'avoir une vue de certaines données avec un écran séparé "edit" (ou sauter la vue et seulement ayant un l'écran d'édition), il peut souvent être plus convivial d'avoir une joliment aménagé de vue de certaines données et de cliquer pour modifier des parties d'elle. Cette technique n'est vraiment appropriée que lorsque la lecture des données se produit plus souvent que l'édition, et n'est pas appropriée pour la saisie de données sérieuse.

les éléments de la liste que vous avez présentée dépendent vraiment de la situation - ils varieront d'une application à l'autre. Certaines applications auront besoin d'un bouton de sauvegarde, d'autres non. Certaines conditions justifieront une boîte de dialogue modale, d'autres non.

ma principale règle pour concevoir une interface utilisable: suivre les conventions D'UI existantes. Rien ne trouble plus un utilisateur QU'une interface utilisateur qui ne fonctionne pas comme tout ce qu'il a déjà utilisé. Lotus Notes A l'une des pires interfaces utilisateur et c'est presque entièrement parce qu'ils sont allés à l'encontre des conventions communes de L'assurance-chômage avec à peu près tout ce qu'ils ont fait.

si vous vous demandez comment vous devriez concevoir un certain morceau de votre UI, pensez à quelques applications standard/bien connues qui fournissent des fonctionnalités similaires et voir comment ils le font.

si vous faites un logiciel d'entreprise, beaucoup d'utilisateurs auront de petits moniteurs à basse résolution. Ou s'ils sont vieux ils l'auront à une basse résolution pour qu'ils puissent voir des boutons Géants ( j'ai vu un 800x600 sur un moniteur 24"ish). J'ai un vieux moniteur 15" à basse résolution (800 x 600) donc je peux voir ce que le programme ressemblera dans des conditions de moins que le ralenti de temps en temps. Je sais que les utilisateurs d'entreprise ont à peu près à accepter ce qu'ils sont donnés, mais si vous concevez une winform qui ne rentre pas dans un écran 800x600, ça n'aide personne.

essayez de penser aux objectifs finaux de votre Utilisateur avant de décider quelles tâches individuelles ils effectueraient en utilisant votre logiciel. Le livre sur le visage a d'excellentes discussions sur ce genre de chose et même si assez long est très intéressant et perspicace. Il est intéressant de noter combien de leurs suggestions sur l'amélioration de la conception du logiciel semblent utilisées dans google docs...

Une autre chose, gardez votre interface utilisateur simple et la plus propre possible.

ici est un grand podcast DotNetRocks épisode où Mark Miller parle de la façon de créer bon UI ; même si le titre de l'émission est .net rocks, cet épisode parle d'une règle générale de pouces sur la façon de créer une UI pour augmenter la productivité de l'utilisateur du programme.

voici un épisode de

bonne conception de l'interface utilisateur peut être fait en s'en tenant à quelques bonnes règles et éviter les erreurs courantes. Vous ne devez pas être un latte-sippin tattoo-wearin MacBook-designer porteuse pour créer des interfaces utilisateur qui fonctionnent.

j'aime suivre ces 3 lignes directrices:

1. Standard-suivez les normes/modèles connus, réutilisez les idées de tous les produits que vous respectez
2. Simple-Gardez vos solutions simples et faciles à changer (si nécessaire)
3. élégant - utiliser moins pour accomplir plus

la meilleure technique que j'ai trouvé est de se mettre dans les chaussures des utilisateurs. Qu'est-ce que tu voudrais voir de L'interface graphique et mettre ça devant. Cela vous donne également la capacité de prioriser car ces choses devraient être faites d'abord puis travailler à partir de là.

pour ce faire, j'essaie de trouver des" couches d'utilité " et d'ajouter / soustraire des couches jusqu'à ce qu'elles semblent propres. Fondamentalement pour trouver les couches je fais une liste de toutes les fonctions que L'interface graphique doit avoir, toutes les fonctions qu'elle devrait avoir ont, et toutes les fonctions qu'il serait bien d'avoir. Puis je les regroupe pour que chaque chose ait un ordre logique et les regroupements deviennent les"couches". À partir des couches, j'ajoute la fonctionnalité la plus importante (ou ce qui serait utilisé pour le fonctionnement au jour le jour) et cela devient la partie la plus importante, et je travaille des choses dans la fonctionnalité autour de ces éléments.

une des choses les plus difficiles est la navigation car vous avez tellement à donner l'usage comment faire pour qu'il soit utile et ce c'est là que les couches aident vraiment. Il est facile de voir comment mettre en page des menus, comment d'autres pièces interagissent, quelles pièces peuvent être cachées, etc.

j'ai trouvé que la meilleure façon de le faire est de commencer par voir en quoi et comment vos utilisateurs fonctionner sur une base quotidienne, ce qui le rendra plus facile à obtenir dans leurs chaussures (encore mieux, c'est de faire leur travail pour quelques jours). Faites ensuite quelques démonstrations et mettez-les devant les utilisateurs, même S'il s'agit de Prototypes en papier (il y a un livre sur ce processus appelé prototypage sur papier par Carolyn Snyder). Puis commencer à le construire et le mettre devant les utilisateurs comme il est construit souvent .

je recommanderai aussi le livre Designing Interfaces de Jenifer Tidwell publié par O'Reilly

si votre UI implique la saisie ou la manipulation de données (typique des applications d'affaires), alors je recommande d'accorder à vos utilisateurs la capacité d'agir sur ensembles d'éléments de données autant que possible. Essayez également de concevoir de manière à ce que les utilisateurs expérimentés puissent interagir avec L'interface de manière très aléatoire, par opposition à séquentielle (touches accélératrices, hyperliens, etc.).

Sung Meister a mentionné Mark Miller. Vous pouvez trouver certains de ses billets de blog concernant great UI sur le Developer express blog . Voici un screencast de sa Science de grande présentation UI: part1 et part2 . (les deux requièrent Veoh player ).

Vous pouvez également le trouver sur dnrTV: Sciences de la grande expérience de l'utilisateur: part1 et part2 .

Voici une google techtalks sur l'expérience utilisateur par Jen Fitzpatrick.

Cheers

lorsque vous utilisez un dropdown, la hauteur de dropdown par défaut est généralement trop faible (la valeur par défaut est de 8 éléments pour les winforms, par exemple).

en L'augmentant, il sera soit enregistrer l'utilisateur un clic si le nombre d'articles est faible ou il sera plus facile de rechercher la liste déroulante s'il ya beaucoup d'articles.

En fait, je vois peu d'intérêt à ne pas utiliser tout l'espace disponible !

C'est tellement évident pour moi maintenant, mais pour par exemple, il semble que même les designers VisualStudio ne l'ont pas compris (btw, si vous augmentez manuellement la hauteur D'Intellisense, il restera de cette façon, mais c'est offtopic:))

je vais donner un de mes favoris personnels: éviter les boîtes de dialogue à tout prix. Un U vraiment bon je ne devrais presque jamais avoir besoin de pop up une boîte de dialogue. Ajoutez - les à votre programme uniquement en dernier recours.

pour plus, vous pourriez vouloir vérifier conseils d'ui facilement digestible pour les développeurs .

le blog Coding Horror donne régulièrement de grandes idées. Juste quelques exemples:

• apprentissage exploratoire et progressif
• l'Auto-documentation de l'interface utilisateur
• recherche Incrémentale de fonctionnalités/clavier Smart access
• conception axée sur les tâches (ruban au lieu de menus et de barres d'outils)
• fournissant undo au lieu d'une confirmation constante

un autre aspect: utilisez des icônes modulables pour résoudre le problème des résolutions d'écran de plusieurs utilisateurs sans maintenir des bitmaps de résolution différents.

coins arrondis!

(Oui, c'est la langue dans la joue)