Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette rubrique décrit le modèle d'interface utilisateur connu sous le nom d'interface utilisateur inductive (IUI). Également appelé navigation inductive, le modèle IUI propose de simplifier les applications logicielles en divisant les fonctionnalités en écrans ou en pages faciles à expliquer et à comprendre. Ce modèle d'IUI est évident dans divers projets Microsoft, tels que Microsoft Money 2000, les applets du panneau de contrôle Windows, divers écrans et boîtes de dialogue dans Microsoft Visual Studio 2010, et les panneaux de tâches dans Microsoft Office.
- Introduction
- IUI en action : Résoudre un problème de conception courant
- Étapes de la création d'une interface utilisateur inductive
- Conseils supplémentaires
- Assistance utilisateur
- Annexe : Conception et test de Microsoft Money 2000
Introduction
L'IUI est un modèle d'interface utilisateur qui suggère comment simplifier les applications logicielles en divisant les fonctionnalités en écrans ou en pages faciles à expliquer et à comprendre. Microsoft a mis en œuvre ce modèle dans Money 2000, un grand logiciel commercial. Des tests informels suggèrent que les utilisateurs peuvent effectuer des tâches aussi rapidement avec ce modèle qu'avec des interfaces traditionnelles, et qu'ils peuvent trouver les choses plus facilement.
De nombreux logiciels commerciaux comprennent des interfaces utilisateur dans lesquelles un écran présente un ensemble de commandes, mais laisse à l'utilisateur le soin de déduire l'objectif de la page et la manière d'utiliser les commandes pour atteindre cet objectif.
Les principes décrits dans le présent document ne requièrent ni n'impliquent aucun ensemble rigide particulier de conceptions, de contrôles ou d'éléments visuels. À l'instar des interfaces graphiques en général, les principes décrits dans ce document laissent une grande place à la flexibilité et à la créativité dans la conception.
Les principes généraux de l'interface utilisateur inductive sont démontrés à l'aide d'exemples tirés de Money 2000.
Important
Le concept global de l'interface utilisateur inductive n'en est qu'à ses débuts. Les concepteurs qui emploient ces techniques en apprennent et en découvrent davantage au fur et à mesure qu'ils les utilisent pour leurs logiciels. Les informations contenues dans ce document évolueront avec le temps, au fur et à mesure que la recherche et les connaissances dans ce domaine se développeront. Cette rubrique constitue une introduction à l'IUI, plutôt qu'un ensemble de lignes directrices fermes et exhaustives.
L'IUI en action : Résolution d'un problème de conception courant
Cette section traite d'un problème de conception courant dans les produits logiciels actuels et présente l'IUI comme une technique permettant de résoudre ce problème.
Le problème : les logiciels sont difficiles à utiliser
La plupart des logiciels sont trop difficiles à utiliser. Cette conclusion est tirée de tests de convivialité, de preuves anecdotiques et d'expériences personnelles de concepteurs de logiciels. Le concept d'IUI a été créé en menant des recherches, en faisant des suppositions éclairées sur ce qui rend les logiciels actuels difficiles à utiliser, puis en proposant des solutions. Les concepteurs qui utilisent l'IUI devraient s'appuyer sur la satisfaction du client pour déterminer le succès final de la conception.
La plupart des logiciels actuels sont difficiles à utiliser pour les raisons générales suivantes :
Les utilisateurs ne semblent pas construire un modèle mental adéquat du produit.
La conception de l'interface de la plupart des logiciels actuels suppose que les utilisateurs comprendront un modèle conceptuel que les concepteurs ont soigneusement élaboré. Malheureusement, la plupart des utilisateurs ne semblent jamais acquérir un modèle mental suffisamment complet et précis pour guider leur navigation. Ces utilisateurs sont probablement très occupés et surchargés d'informations. Ils n'ont ni le temps, ni l'énergie, ni l'envie d'étudier un modèle conceptuel pour leur logiciel.
Même les utilisateurs de longue date ne maîtrisent pas les procédures courantes.
Les concepteurs savent que les nouveaux utilisateurs peuvent rencontrer des difficultés au début, mais ils s'attendent à ce que ces problèmes disparaissent au fur et à mesure que les utilisateurs apprennent les tâches courantes. Les données relatives à l'utilisabilité indiquent que ce n'est souvent pas le cas. Dans une étude, les chercheurs ont mis en place un équipement automatisé pour enregistrer les utilisateurs chez eux. Les enregistrements ont montré que les utilisateurs qui se concentrent sur la tâche à accomplir ne remarquent pas nécessairement la procédure qu'ils suivent et ne tirent pas de leçons de leur expérience. La prochaine fois qu'ils effectueront la même opération, ils risquent de trébucher exactement de la même manière.
Les utilisateurs doivent travailler dur pour comprendre chaque fonctionnalité ou écran.
La plupart des logiciels sont conçus pour les utilisateurs (peu nombreux) qui en comprennent le modèle conceptuel et qui maîtrisent les procédures courantes. Pour la majorité des utilisateurs, chaque fonctionnalité ou procédure est un casse-tête frustrant et indésirable. Les utilisateurs peuvent penser que ces énigmes sont un coût inévitable de l'utilisation des ordinateurs, mais ils seraient certainement plus heureux sans ce fardeau.
La meilleure solution à ces problèmes consiste à trouver une stratégie générale pour rendre les fonctionnalités des produits logiciels plus évidentes et plus explicites. Les utilisateurs doivent pouvoir trouver une fonctionnalité chaque fois qu'ils en ont besoin et doivent pouvoir utiliser cette fonctionnalité chaque fois qu'ils veulent l'utiliser.
Interface utilisateur déductive
La plupart des éléments des logiciels actuels exigent que l'utilisateur les étudie et en déduise le comportement, comme le montre la capture d'écran suivante.
Les utilisateurs d'ordinateurs expérimentés, y compris les concepteurs de logiciels, reconnaissent rapidement que cette boîte de dialogue leur permet de gérer une liste d'éléments. Ils comprennent que les boutons situés sous la liste permettent d'ajouter, de supprimer et de fournir des informations sur les éléments de la liste. Cependant, vous remarquerez qu'aucun de ces comportements n'est explicitement mentionné dans la boîte de dialogue elle-même.
Examinez maintenant la boîte de dialogue du point de vue d'un utilisateur occasionnel. Face à cette boîte de dialogue, de nombreux utilisateurs se demanderont : « Qu'est-ce que je suis censé faire avec ça ? » Lorsque la boîte de dialogue apparaît, l'utilisateur doit s'arrêter et déterminer ce qu'il doit faire ensuite. Tout d'abord, il doit déduire que le grand rectangle blanc est une zone de liste vide qui doit être remplie d'éléments. La petite étiquette de la boîte, « Choses », offre un vague indice. Certains utilisateurs essaieront de taper dans la zone de liste, car elle ressemble à une zone de texte d'édition.
Ensuite, l'utilisateur doit déduire que les boutons situés sous la liste affectent son contenu. Certains de ces boutons sont initialement désactivés, ce qui constitue une autre source potentielle de confusion pour l'utilisateur. L'utilisateur doit expérimenter les contrôles pour apprendre comment fonctionne la boîte de dialogue.
L'utilisateur peut également poser d'autres questions : »Combien d'éléments dois-je mettre dans la liste ? Dois-je entrer les éléments dans un ordre spécifique ? Pourquoi ai-je obtenu cette boîte de dialogue en premier lieu ? À quoi sert-elle ? »
Les utilisateurs sont détournés de leurs objectifs lorsqu'ils doivent comprendre l'utilité d'un écran et la manière de l'utiliser. Cela représente en fin de compte un coût en termes de temps et de satisfaction de l'utilisateur. Pire encore, les utilisateurs paient ce coût de manière répétée, car ils se perdent dans les méandres de l'interface à chaque fois qu'ils utilisent une fonctionnalité.
Un écran doit avoir un titre qui explique clairement son objectif. Lorsque les concepteurs créent un écran, il est rare qu'ils lui demandent d'avoir un objectif clairement exprimable. Au lieu de cela, il peut simplement faire partie d'un modèle conceptuel plus large que l'utilisateur doit déduire.
Des études montrent que de nombreux utilisateurs sont déconcertés par les opérations de base des logiciels. Ils ont du mal à comprendre ce que le produit peut faire pour eux, où aller pour effectuer une opération et comment effectuer cette opération une fois qu'ils l'ont trouvée. Simplifier les logiciels en apportant des changements fondamentaux est un moyen efficace de mieux satisfaire les clients existants et d'attirer de nouveaux utilisateurs.
Une solution : L'interface utilisateur inductive
En tant que nouvelle méthode de conception de logiciels, l'interface utilisateur inductive a pour objectif de réduire la quantité de réflexion superflue que les utilisateurs doivent mener pour passer d'une partie à l'autre d'un produit et en utiliser les fonctionnalités. Le mot inductif vient du verbe induire, qui signifie conduire ou déplacer par influence ou persuasion.
L'IUI est une extension de l'interface commune de type Web. Dans l'environnement Web, les pages doivent être simples et axées sur les tâches, car chaque information doit être envoyée à un serveur par le biais d'une connexion relativement lente. Le serveur répond ensuite avec l'étape suivante, et ainsi de suite. Une bonne conception Web consiste à se concentrer sur une seule tâche par page et à assurer la navigation entre les pages. De la même manière, la navigation inductive commence par concentrer l'activité de chaque page sur une seule tâche principale.
Une interface inductive bien conçue aide les utilisateurs à répondre à deux questions fondamentales auxquelles ils sont confrontés lorsqu'ils regardent un écran :
- Que suis-je censé faire maintenant ?
- Où dois-je aller pour accomplir ma prochaine tâche ?
Les logiciels conçus selon ces principes répondent à ces questions en partant d'un principe fondamental : un écran dont l'objectif est unique, clairement énoncé et explicite est plus facile à comprendre qu'une page qui n'a pas cet objectif. Si l'écran est plus facile à comprendre, il sera plus facile pour l'utilisateur de savoir quoi faire et où aller ensuite.
Ce principe fondamental peut être développé en une série de quatre étapes pour la conception d'un logiciel utilisant l'IUI :
- Concentrez chaque écran sur une seule tâche.
- Énoncez la tâche.
- Adapter le contenu de l'écran à la tâche.
- Proposer des liens vers des tâches secondaires.
Ce document décrit les principes généraux de l'IUI, mais il les met également en pratique en montrant des exemples tirés de Money 2000 et d'autres logiciels. Vous devez considérer ces exemples comme des expressions particulières de l'interface utilisateur, et non comme un modèle strict de mise en œuvre.
Outre les quatre étapes énumérées ci-dessus, vous pouvez renforcer votre interface en suivant les cinq lignes directrices suivantes :
- Utilisez des modèles d'écran cohérents.
- Fournissez des écrans pour démarrer les tâches.
- Expliquez clairement comment effectuer la tâche à l'aide des commandes à l'écran.
- Fournissez un moyen facile de terminer une tâche et d'en commencer une nouvelle.
- Faites en sorte que la prochaine étape de navigation soit évidente.
Processus
De nombreuses tâches exigent des utilisateurs qu'ils naviguent dans une série d'écrans. Un utilisateur effectuant une tâche peut cliquer sur un lien menant à une tâche secondaire qui s'éloigne de la séquence d'écrans constituant la tâche principale. Lorsque l'utilisateur termine la tâche secondaire, il doit pouvoir revenir facilement au point de branche de la tâche initiale. Les utilisateurs risquent d'avoir des difficultés à utiliser les commandes de navigation conventionnelles, telles que les boutons Précédent et Suivant, pour revenir à leur point de départ.
Pour ce faire, l'IUI définit un concept de navigation appelé processus, c'est-à-dire un écran ou une série d'écrans qui exécutent une tâche. Un processus agit comme une sorte de sous-programme de navigation. Les utilisateurs peuvent commencer un processus, parcourir sa série d'écrans et, à la dernière page, cliquer sur un bouton « Terminé » pour revenir rapidement à la page où ils ont commencé le processus.
Étapes de la création d'une interface utilisateur inductive
Cette section décrit en détail les quatre étapes à suivre pour créer une interface utilisateur inductive.
Première étape : Concentrez chaque page sur une seule tâche
La première étape de la conception d'une IUI consiste à prendre une fonctionnalité ou un ensemble de fonctionnalités et à les diviser en écrans distincts. Chaque écran doit être axé sur une seule tâche, appelée tâche principale de l'écran.
Cette idée semble simple, mais peu d'applications la suivent. La plupart des applications présentent un écran à partir duquel toutes les fonctionnalités connexes sont exécutées. Cette conception oblige les utilisateurs à découvrir (déduire) ce qu'il est possible de faire et comment le faire.
La tâche principale peut être spécifique ou ouverte. Par exemple, dans un programme de finances personnelles, une tâche spécifique pourrait être « Sélectionnez la facture que vous voulez payer », tandis qu'une tâche ouverte pourrait être « Examinez la performance de vos investissements ».
La tâche principale doit être quelque chose de logique pour l'utilisateur, plutôt que le reflet d'un détail de mise en œuvre ou d'un autre concept abstrait. La tâche doit être quelque chose que les utilisateurs pourraient penser à faire, de préférence décrite avec leurs propres mots.
Exemple
Cette section compare deux versions différentes de Money. Les exemples montrent des fonctionnalités très similaires qui permettent aux utilisateurs de visualiser et de gérer des comptes financiers.
Le modèle IUI a été développé lors de la création de Money 2000, une application de gestion des finances personnelles. Money 2000 est la huitième version majeure du produit. Money 2000 est un gros programme Windows qui compte plus d'un million de lignes de code.
Money 2000 est une application de type Web. Ce n'est pas un site Web, mais il partage de nombreux attributs avec les sites Web. Son interface utilisateur consiste en des pages plein écran affichées dans une trame partagée, avec des outils permettant de se déplacer en avant et en arrière dans une pile de navigation. Sur cette base, Money 2000 ajoute un ensemble de nouvelles conventions d'interface utilisateur qui créent une expérience utilisateur plus structurée.
Bien que l'IUI ait été utilisée pour la première fois dans la conception de style Web de Money 2000, elle peut également être utilisée avec des éléments d'interface traditionnels tels que les fenêtres et les boîtes de dialogue.
Dans Money 99, les utilisateurs effectuaient souvent une grande variété de tâches sur un seul écran. Par exemple, la capture d'écran suivante montre le gestionnaire de compte qui présente toutes les fonctionnalités liées au compte dans Money 99 sur un seul écran.
Cet écran regroupe une tâche courante, la navigation vers un compte, ainsi que des tâches peu fréquentes comme la création et la suppression de comptes. Aucune de ces tâches spécifiques n'est directement exprimée dans le titre de l'écran, Account Manager. Pour de nombreux utilisateurs, cet écran peut être aussi difficile que l'exemple de dialogue de la figure 1. Dans les deux cas, l'utilisateur doit déduire l'objectif de l'écran et la manière de l'utiliser.
Money 2000, qui suit l'IUI, offre un ensemble presque identique de fonctionnalités liées aux comptes, mais les présente sur deux écrans distincts. La capture d'écran suivante montre le premier de ces écrans, qui est entièrement axé sur la sélection d'un compte par l'utilisateur.
L'écran Money 2000 contient à peu près le même nombre d'éléments visuels que l'écran Money 99, mais la page est désormais entièrement axée sur la sélection d'un compte par l'utilisateur. Par exemple, dans la version Money 99, l'utilisateur devait faire deux clics pour ouvrir un compte : un pour le sélectionner et un autre pour sélectionner l'opération d'ouverture. Dans la version Money 2000, la seule raison pour laquelle un utilisateur clique sur un compte est de l'ouvrir, et un seul clic peut donc suffire. Ainsi, même si le nombre d'écrans augmente, le nombre de clics nécessaires à l'exécution d'une tâche courante est souvent réduit.
Il arrive que les utilisateurs veuillent ajouter ou supprimer un compte. Pour effectuer cette tâche dans Money 2000, les utilisateurs naviguent vers un deuxième écran (illustré dans la capture d'écran suivante) qui se concentre sur la configuration des comptes.
L'objectif de chaque écran est plus clair dans la version IUI de Money 2000. En outre, chaque écran dispose de plus d'espace pour remplir sa fonction. Par exemple, le gestionnaire du compte Money 99 pouvait accorder très peu d'espace au bouton Supprimer le compte, parce qu'il était rarement utilisé par rapport aux autres commandes à l'écran. En revanche, l'écran de configuration des comptes dans Money 2000 peut mettre en fonctionnalité cette commande de manière plus évidente, ce qui la rend plus facile à découvrir et à expliquer.
Qu'est-ce qu'une tâche unique ?
Comment savoir si un écran est réellement axé sur une seule tâche ? Un écran qui prend en charge de nombreuses tâches peut être expliqué comme n'ayant qu'un seul objectif si cet objectif est suffisamment abstrait. Voici une règle empirique : un écran est axé sur une seule tâche si le concepteur peut exprimer cette tâche à l'aide d'un titre d'écran concis, significatif et naturel.
Les concepteurs de Money 2000 ont envisagé de diviser ces écrans (Choisir un compte à utiliser et Configurer vos comptes dans Money) en plusieurs écrans. Cependant, comme chaque écran possède déjà un titre concis, significatif et naturel, les concepteurs ont estimé que les écrans étaient suffisamment ciblés. Lors de la conception d'un écran, si vous ne parvenez pas à trouver un titre clair et simple, c'est que vous essayez probablement d'en faire trop.
Deuxième étape : Énoncez la tâche
Le titre de chaque écran doit comporter une instruction concise et explicite de sa tâche principale. Il peut s'agir d'une instruction directe (« Sélectionnez le compte que vous souhaitez solder ») ou d'une question à laquelle vous souhaitez que l'utilisateur réponde (« Quel compte souhaitez-vous solder ? »).
Il s'agit là d'un autre principe simple à première vue, mais qui n'est souvent pas mis en pratique. Par exemple, les versions antérieures de Money avaient des écrans intitulés Gestionnaire de services financiers en ligne et Compte de solde. Les utilisateurs devaient déduire l'objectif et le comportement de ces écrans à partir de la disposition et des étiquettes de leurs commandes.
Le titre de l'écran ou de la page est très important. Que le produit utilise des fenêtres, des pages de style Web, des boîtes de dialogue ou une autre conception, le titre ne doit pas pouvoir défiler.
Les écrans utilisables ont des titres clairs
Les écrans qui exécutent de nombreuses tâches nécessitent des titres abstraits ou complexes. Par exemple, l'écran Money 99 illustré à la figure 2 permettait à l'utilisateur de naviguer vers les comptes et de créer des comptes. Le titre abstrait « Gestionnaire de compte » a été donné à cette page pour tenter de rendre compte de ces deux objectifs. Bien que les utilisateurs puissent avoir une idée de ce qu'une page « Gestionnaire de compte » pourrait faire, ils peuvent ne pas se rendre compte que la tâche la plus courante pour cet écran était simplement de choisir un compte.
Certains écrans ou commandes ont des objectifs abstraits qui ne suggèrent pas facilement des titres clairs. Pour ces écrans, les concepteurs peuvent choisir des noms délibérément vagues, tels que « Paramètres », des mots à la mode, comme « QuickStep », ou un jargon qui révèle des détails de mise en œuvre (« Compaction de la base de données »). Ces types de noms prêtent souvent à confusion ou induisent les utilisateurs en erreur. En outre, ces noms sont généralement des substantifs qui n'expriment pas l'action que l'utilisateur souhaite accomplir, ce qui ajoute à la confusion.
Les titres d'écran et autres noms ne sont souvent déterminés que vers la fin du processus de conception. Les concepteurs demandent souvent aux rédacteurs de trouver un nom approprié pour un écran après qu'il a été conçu et codé. À ce stade, il n'y a pas de recours si un bon nom ne peut être trouvé, et l'équipe peut donc devoir se contenter de noms qui ne sont pas clairs. La solution à ce problème est que les concepteurs réfléchissent à la clarté des fonctions et des titres d'écran dès le début du processus de conception.
Les fonctions et les titres des écrans doivent être axés sur les tâches les plus courantes effectuées par les clients. Les concepteurs sont souvent tentés de fournir d'énormes quantités de fonctionnalités afin de satisfaire le plus grand nombre de clients, ainsi que les désirs de l'équipe de conception elle-même. Cependant, les fonctionnalités supplémentaires ajoutent toujours de la complexité et d'autres coûts.
Le titre de l'écran indique la clarté de la conception
Dans le modèle IUI, les concepteurs choisissent les titres des écrans dès les premières étapes du processus de conception. Au lieu de choisir un titre pour justifier le fonctionnement de l'écran, le titre est utilisé pour déterminer si l'écran a un sens. Si aucun titre approprié ne peut être trouvé, la fonctionnalité est redessinée. Si aucune conception ne permet de trouver un titre clair et concis (c'est-à-dire s'il n'y a aucun moyen d'expliquer la fonctionnalité), les concepteurs peuvent abandonner la fonctionnalité. Dans les captures d'écran suivantes, comparez l'écran de paiement de factures de Money 99 à gauche, qui fournit un libellé statique pour la page (« Factures à venir & Dépôts »), et l'écran correspondant de Money 2000 à droite, qui a un titre explicite (« Cliquez sur la facture que vous souhaitez payer ») :
Un titre d'écran, qui n'est bien sûr qu'une phrase, est plus facile à modifier qu'un dessin ou un code. Malgré cela, l'expérience de l'IUI a montré que le fait d'insister sur un titre d'écran clair dès le début permet d'obtenir de meilleures conceptions. Les titres doivent être choisis avec l'aide des membres de l'équipe chargée de la formation des utilisateurs et de l'utilisabilité, ainsi que des concepteurs du produit.
Les membres de l'équipe peuvent parfois essayer de reporter cette décision, en supposant que les clients partageront leur compréhension de l'objectif d'un écran. Cependant, lorsqu'ils sont contraints de proposer une instruction claire et concise de cette finalité, des divergences d'opinion apparaissent souvent. En résolvant ces divergences et en choisissant un titre dès le début, les discussions sur la conception peuvent se dérouler plus facilement.
Une fois le titre choisi, vous ne devez pas le considérer comme immuable. Les concepteurs affineront probablement les titres des écrans au fil du temps, comme c'est le cas pour toute conception. Toutefois, le premier titre choisi doit être aussi fort que possible à ce stade du développement.
Lignes directrices pour le choix des titres d'écran
Cette section décrit une technique simple pour choisir de bons titres d'écran. Pour utiliser cette technique, les concepteurs imaginent qu'un ami leur demande : « À quoi sert cet écran ? », puis ils trouvent une réponse claire et utile qui complète la phrase : « C'est l'écran où vous... ». Les mots qui complètent la phrase deviennent le titre de l'écran.
Au cours du développement de Money 2000, les rédacteurs de la documentation de l'équipe ont élaboré des directives sur les titres d'écran afin de garantir la qualité et la cohérence. Par exemple, ces directives suggéraient des titres utilisant des verbes et formulés comme des questions ou des instructions directes. Les concepteurs ont évité les noms statiques qui permettaient une plus grande abstraction et pouvaient être vagues.
Pour simplifier les titres, les concepteurs ont évité les phrases composées et se sont efforcés d'utiliser un langage conversationnel, en évitant les termes maladroits et le jargon. Si les concepteurs ne peuvent pas décrire la tâche sans recourir à des conjonctions (« et », « ou »), l'écran tente probablement d'accomplir plusieurs tâches, et il est peu probable que l'utilisateur comprenne immédiatement ce qu'il doit faire.
Même si le titre est soigneusement choisi, la région du titre peut être trop petite pour expliquer correctement une tâche complexe. Pour pallier ce problème, vous pouvez inclure un bref paragraphe descriptif en haut de la zone de contenu de l'écran qui développe la tâche.
Le tableau suivant contient quelques exemples de titres d'écran dans Money 99 et de titres d'écrans identiques ou apparentés dans Money 2000.
| Titres d'écran dans Money 99 | Nouveaux titres d'écran dans Money 2000 | Commentaire |
|---|---|---|
| Gestionnaire de comptes |
Choisissez un compteCréez vos comptes |
Titre statique transformé en titre actif. |
| Détails du compte | Modifier la configuration du compte | Titre statique remplacé par un titre actif et spécifique. |
| Calendrier des paiements | Payer une facture | Titre vague rendu descriptif. |
| Responsable des services financiers en ligne | Page inutile après la refonte. |
Mettre le titre d'écran en évidence
Une fois que vous avez choisi un titre d'écran utile, il est important de s'assurer que l'attention de l'utilisateur est attirée sur ce titre. Certaines études ont montré que les utilisateurs lisent rarement les textes d'instruction. Pour remédier à ce problème, les titres d'écran doivent être conçus de manière à être bien visibles et attrayants afin d'attirer l'attention de l'utilisateur. La conception visuelle de l'écran doit informer l'utilisateur que le titre est la chose la plus importante à lire.
Troisième étape : Adapter le contenu de la page à la tâche
Lors de la création d'un logiciel conforme aux lignes directrices de l'IUI, le travail de conception le plus difficile consiste généralement à diviser les fonctionnalités en écrans ou en pages. L'étape suivante consiste à déterminer les commandes qui seront utilisées sur chaque écran pour accomplir sa tâche principale. Ces commandes constituent le contenu de la page, où l'utilisateur effectue son travail. Le titre et le contenu de l'écran sont les deux moitiés d'un dialogue entre le programme et l'utilisateur. Le titre pose la question du programme ou donne une instruction, et l'utilisateur répond par l'intermédiaire de l'interface de l'écran.
Si le titre de l'écran est clair et simple, la conception de l'écran est généralement aisée. Par exemple, l'un des écrans de Money 2000 présentés plus haut s'intitule « Choisissez un compte à utiliser ». Compte tenu de ce titre, l'écran doit évidemment contenir une simple liste de comptes parmi lesquels l'utilisateur peut choisir. Un autre écran de Money 2000 s'intitule « Cochez les éléments à inclure dans vos impôts ». Naturellement, cet écran contient une liste d'éléments à vérifier.
Les utilisateurs devraient pouvoir facilement comprendre comment utiliser les contrôles pour réaliser la tâche principale de l'écran. Lorsque l'utilisateur est invité à sélectionner un compte et qu'il peut consulter l'écran pour trouver une liste de comptes, il confirme qu'il a compris la tâche. Les chances de réussite augmentent, ce qui accroît également la confiance des utilisateurs dans l'exécution d'autres tâches.
Zones de contenu de l'écran
L'emplacement et la forme exacts des zones de contenu de l'écran dépendent de la conception du logiciel. Dans Money 2000, la zone de contenu de l'écran se trouve sous le titre de l'écran et à droite de la liste des tâches. Cette zone peut défiler sur les écrans longs. Certains contenus non essentiels peuvent également apparaître dans la zone d'état située sous la liste des tâches.
Les concepteurs peuvent choisir de développer la tâche principale de l'écran dans un paragraphe situé en haut de la zone de contenu. Les utilisateurs ne sont pas obligés de lire ce texte, mais ils peuvent le trouver utile. De nombreux utilisateurs peuvent l'ignorer et utiliser l'écran avec succès. Contrairement au titre, cette description peut défiler si l'écran est déroulant. Pour plus de détails, reportez-vous à la section Lignes directrices pour la sélection des titres d'écran.
Si les concepteurs souhaitent qu'une page affiche des rappels, des alertes ou d'autres informations d'état non essentielles, elle peut être affichée à gauche de la zone de contenu principale, sous la liste des tâches, sur le côté gauche de l'écran. Sur le plan fonctionnel, cette zone d'état est une région supplémentaire pour le contenu de l'écran. Cette zone n'est pas suffisamment visible pour contenir les contrôles essentiels.
Fournissez une sortie claire de la page
Après avoir accompli une tâche avec succès, l'utilisateur est confronté à un autre problème : quand et comment quitter l'écran. Pour les écrans dont la tâche principale est la navigation, l'exécution de la tâche elle-même permet à l'utilisateur de passer à l'écran suivant. Sur d'autres écrans, il peut être plus difficile pour l'utilisateur de savoir comment procéder. Par exemple, sur un écran qui demande à l'utilisateur de taper des informations dans des champs, l'utilisateur peut avoir besoin d'aide pour savoir quand et comment passer à l'écran suivant. Sur ces pages, il est souvent utile de proposer un bouton Suivant ou Terminé clair et placé à un endroit cohérent.
Des études de convivialité ont montré que les utilisateurs préfèrent utiliser ces boutons même lorsque des boutons de navigation globaux, tels que les boutons Retour ou Accueil d'une barre d'outils, sont disponibles. Les utilisateurs se sentent souvent mal à l'aise sur des écrans sans sortie claire, même sur des écrans dont le seul but est de fournir des informations à lire.
Pour plus d'informations à ce sujet, voir Fournir un moyen facile de terminer une tâche et d'en commencer une nouvelle dans la section Lignes directrices supplémentaires.
Quatrième étape : Proposez des liens vers des tâches secondaires
La dernière étape de la conception d'un écran consiste à proposer des liens vers des tâches secondaires, c'est-à-dire des fonctionnalités qui ne permettent pas d'accomplir directement la tâche principale, mais qui sont liées à l'écran. Par exemple, si la tâche principale d'un écran est d'écrire une lettre, les tâches secondaires de cet écran peuvent consister à rechercher une adresse postale ou à imprimer une enveloppe.
Les tâches secondaires peuvent faire apparaître des boîtes de dialogue, modifier la présentation visuelle du contenu de l'écran ou faire naviguer l'utilisateur vers un autre écran. Une tâche secondaire peut accomplir indirectement la tâche principale ou rediriger les utilisateurs perdus vers l'endroit qu'ils recherchent.
Si une page est une conversation entre l'ordinateur et l'utilisateur, une tâche secondaire permet à l'utilisateur d'ignorer la question actuelle de l'ordinateur et de lui demander de faire autre chose à la place. Par exemple, imaginez ce dialogue : Ordinateur : « Quelle facture voulez-vous payer ? » Utilisateur : « En fait, ce que je veux vraiment faire, c'est retrouver une facture que j'ai payée il y a quelque temps ».
Certains écrans de votre produit n'auront aucune tâche secondaire, tandis que d'autres en auront plusieurs. Vous devez éviter de créer une longue liste de tâches que l'utilisateur aura probablement du mal à analyser. Si un écran comporte une liste relativement longue de tâches secondaires, les tâches les plus courantes doivent être placées en premier, regroupées dans une section distincte ou mises en valeur visuellement d'une autre manière.
La liste ne doit pas inclure toutes les tâches secondaires imaginables, à condition que la prochaine étape de navigation soit évidente. Au lieu d'offrir de nombreuses tâches secondaires, un écran peut proposer des tâches secondaires qui renvoient à des pages subsidiaires énumérant d'autres tâches.
Conception visuelle des tâches secondaires
Les tâches secondaires doivent être listées dans une position subordonnée sur l'écran, où elles sont accessibles en cas de besoin mais ne distraient pas l'utilisateur de la tâche principale. En plaçant cette liste dans une position cohérente sur chaque écran, les utilisateurs peuvent la trouver rapidement lorsqu'ils en ont besoin.
Si vous affichez la liste des tâches secondaires sur le côté gauche de l'écran, la liste elle-même ne doit pas pouvoir défiler, et elle ne doit jamais défiler avec la page, comme le montre la capture d'écran suivante de l'écran Paiement de factures de Money 2000.
Conseils supplémentaires
Cette section décrit cinq lignes directrices utiles pour créer une interface utilisateur selon les quatre étapes décrites dans la section précédente.
Utilisez des modèles d'écran cohérents
Lorsque vous concevez un logiciel qui suit le modèle de l'interface utilisateur, vous devez créer un modèle qui servira de guide pour chaque écran. Le modèle inductif n'impose pas l'utilisation d'un modèle particulier. Il existe de nombreuses variations possibles qui peuvent satisfaire une conception inductive. Votre produit peut n'avoir besoin que d'un seul modèle pour tous ses écrans, ou vous pouvez créer plusieurs modèles différents à des fins diverses.
Un bon modèle permet à un nouvel utilisateur de comprendre rapidement comment fonctionnent les écrans du produit. L'utilisation cohérente du modèle dans les écrans du produit assure une bonne fluidité de l'interface utilisateur d'un écran à l'autre. En apprenant à s'attendre à ce que les mêmes éléments apparaissent aux mêmes endroits, les utilisateurs peuvent analyser et commencer à utiliser chaque nouvel écran plus rapidement.
Prévoyez des écrans pour le démarrage des tâches
Les produits conçus avec l'IUI utilisent souvent des écrans spéciaux conçus pour lancer les utilisateurs dans des séries de tâches. Ces écrans sont appelés pages d'activité parce qu'ils organisent des groupes de tâches communes. Les pages d'activité constituent un point de départ pour les utilisateurs. Une page d'activité présente généralement des liens vers d'autres pages où l'utilisateur effectue réellement son travail. Les pages d'activité demandent à l'utilisateur « Que voulez-vous faire maintenant ? » et présentent une liste de réponses possibles. Les pages d'activité peuvent suivre un modèle spécial pour aider les utilisateurs à les reconnaître.
Une page d'activité est une bonne page de démarrage par défaut pour un produit. Lorsque les utilisateurs démarrent une application, ils ont généralement une idée en tête de la tâche qu'ils souhaitent accomplir. En général, la raison pour laquelle ils démarrent le produit est l'une des quelques tâches très courantes. La page de démarrage par défaut du produit tient compte de ce fait en indiquant clairement comment commencer les tâches courantes.
La page d'accueil de Money 2000 est un exemple de page d'activité. Par défaut, les utilisateurs voient cet écran, où l'accès aux tâches financières courantes telles que le paiement d'une facture et le solde d'un compte est affiché, lorsqu'ils démarrent l'application.
La capture d'écran suivante montre la page d'accueil de Money 2000.
Comme Money offre de nombreuses fonctionnalités financières, seules les tâches financières les plus courantes trouvent leur place sur la page d'accueil. Pour toutes les autres tâches, la page d'accueil renvoie à un ensemble subsidiaire de pages d'activité appelées centres financiers. Chaque grand domaine de Money fournit un centre financier. Ces écrans présentent le niveau suivant de tâches, servant de point de départ à toutes les fonctionnalités de chaque domaine.
Par exemple, la zone MoneyTaxes contient les fonctionnalités fiscales du produit. La zone Taxes propose des liens vers ces fonctionnalités sur une page du Centre fiscal, comme le montre la capture d'écran suivante.
Une page d'activité peut également être beaucoup plus simple si moins d'options sont disponibles. La capture d'écran suivante montre comment une page d'activité peut être utilisée pour gérer les comptes d'utilisateurs Windows.
Expliquez clairement comment effectuer la tâche à l'aide des commandes à l'écran
La meilleure façon de suivre cette ligne directrice est de choisir un titre d'écran approprié et de limiter l'étendue des tâches primaires aux plus courantes. Une fois que le titre et l'objectif de la page sont clairs, le choix de l'ensemble des contrôles est simple.
Facilitez l'achèvement d'une tâche et le démarrage d'une nouvelle tâche
Le dernier obstacle auquel l'utilisateur est confronté sur un écran est de savoir quand et comment le quitter. L'utilisateur quitte généralement l'écran en cliquant sur un lien ou en exécutant une commande qui le dirige vers un autre écran. Ces liens peuvent apparaître dans la zone de contenu de l'écran, dans la liste des tâches ou dans les barres d'outils de navigation. Les utilisateurs peuvent également quitter un écran en fermant le fichier en cours ou l'application elle-même.
Dans certains écrans, la tâche consiste à préparer une opération que l'utilisateur doit confirmer ou annuler. Ces écrans proposent généralement un lien qui exécute et valide l'opération, et un autre lien qui l'annule. Si l'utilisateur ignore ces options et clique sur un autre lien, le programme doit exécuter l'option la moins destructrice. Les écrans doivent indiquer ce qui se passera si l'utilisateur emprunte cette voie. Vous pouvez formuler les liens de manière à ce que cela soit plus évident. Par exemple, un bouton de validation intitulé « Enregistrer les modifications » implique que les modifications apportées à l'écran ne prendront pas effet tant que l'utilisateur n'aura pas cliqué sur ce bouton.
Même si les utilisateurs peuvent quitter la page quand ils le souhaitent, vous pouvez toujours proposer un lien qui suggère une sortie évidente de la page. Il en va de même pour les pages qui se contentent d'afficher des informations statiques. Pour plus d'informations à ce sujet, voir la section Fournir une sortie claire de la page.
Lancement et achèvement de processus
Dans le cadre de cet article, les processus sont des techniques permettant de traiter les tâches qui amènent l'utilisateur à plus d'un écran.
Supposons qu'un utilisateur clique sur un lien dans le contenu d'un écran ou dans une liste de tâches et qu'il soit dirigé vers un autre écran. Cette page peut être la première d'une série d'écrans permettant d'obtenir un résultat global. À la fin de cette série d'écrans, l'utilisateur souhaite revenir à l'écran qui a précédé le processus. Il y a au moins deux façons pour l'utilisateur de revenir en arrière ? en cliquant plusieurs fois sur le bouton Précédent ou en retournant à la page d'accueil et en naviguant à partir de là ? mais aucune de ces méthodes n'est évidente ou naturelle. La plupart des utilisateurs s'attendent à trouver sur l'écran final un bouton qui les ramène directement à l'écran d'origine.
Le modèle IUI prend en charge ce scénario grâce au concept de processus, un écran ou une série d'écrans traités comme une unité de navigation. Les utilisateurs peuvent entrer dans le processus, parcourir ses écrans et, sur le dernier écran, trouver un bouton qui les ramène à leur point de départ. Il est important de noter que l'utilisateur peut lancer le processus à partir de plusieurs endroits du produit. Les utilisateurs sont toujours ramenés à leur point de départ, quel que soit l'endroit où ils se trouvaient lorsqu'ils ont entamé le processus.
Nom du processus
Chaque processus doit recevoir un nom, et ce nom doit apparaître quelque part sur chaque écran du processus. Money 2000 utilise cette approche. Chaque écran faisant partie d'un processus global comprend le nom de ce processus en haut de la page. Ce nom de processus est moins visible que le titre unique de l'écran parce qu'il est moins important. Le nom du processus rappelle à l'utilisateur le processus qu'il est en train de suivre et renforce l'idée que tous les écrans du processus font partie d'une seule et même fonctionnalité. Par exemple, le domaine des impôts sur l'argent comprend un processus d'estimation des impôts qui s'étend sur plusieurs écrans. Chaque écran de ce processus affiche à la fois le nom collectif du processus et son titre unique.
Mise en œuvre des processus
Le même processus peut être lancé à partir de différents liens sur différents écrans, et les utilisateurs seront toujours renvoyés à la bonne page de départ. Ce comportement ne peut être obtenu par un lien codé en dur sur l'écran final du processus, car la destination du lien varie. Au lieu de cela, l'application peut mettre en œuvre ce comportement en maintenant une pile de processus actifs, indépendamment de la pile de navigation normale utilisée par les commandes Précédent et Suivant. Lorsque l'utilisateur lance un processus, l'écran de lancement est poussé dans la pile du processus. Lorsque l'utilisateur clique sur le bouton Terminé dans l'écran final du processus, l'application retire de la pile l'écran de lancement le plus récent et renvoie l'utilisateur à cet écran.
Lorsque l'utilisateur quitte un écran d'un processus, le processus reste actif dans la pile de processus. Les utilisateurs peuvent terminer le processus en revenant à l'écran où ils l'ont laissé, puis continuer. Cela permet aux utilisateurs de faire un détour, de revenir en arrière et de poursuivre le processus. Pour voir comment ce comportement fonctionne, commencez n'importe quel processus d'achat en ligne sur le World Wide Web, quittez le site, puis appuyez sur le bouton Précédent. En règle générale, vous pourrez reprendre le processus là où vous l'avez laissé.
Bouton Terminé
Pour terminer un écran et passer à l'écran suivant dans le processus, les écrans peuvent afficher un bouton près du bas de la page. L'intitulé de ce bouton est « Suivant », « Terminé » ou quelque chose de similaire. Si le bouton met fin au processus et que le processus peut être appelé à partir de plusieurs endroits, la légende du bouton Terminé peut inclure le nom de l'endroit où le processus est appelé.
Barre de navigation
Sur n'importe quel écran, les utilisateurs peuvent décider qu'ils en ont fini avec la partie actuelle du produit et qu'ils veulent commencer quelque chose d'autre. Il se peut qu'il ne veuille pas terminer explicitement l'écran en cours avant de passer à une autre partie du produit. Une barre d'outils de navigation peut offrir à l'utilisateur une série de liens pour commencer de nouvelles tâches. Comme pour les autres listes de liens vers des tâches, ces liens doivent respecter le principe de l'évidence de la prochaine étape de navigation, qui est abordé en détail dans la section suivante.
Rendre la prochaine étape de navigation évidente
Peu de programmes peuvent rendre toutes leurs fonctionnalités disponibles en même temps. Les utilisateurs doivent généralement naviguer dans un programme pour trouver une fonctionnalité particulière. Les utilisateurs réussissent mieux à naviguer s'ils peuvent facilement voir comment se rapprocher au moins d'une étape du résultat souhaité. Les écrans qui utilisent l'IUI sont conçus en tenant compte de ce principe.
Par exemple, les pages d'activité n'affichent pas nécessairement toutes les tâches ou destinations imaginables que l'utilisateur pourrait vouloir atteindre à partir de ce point. Au lieu de cela, les pages d'activité fournissent une liste de tâches suffisamment complète pour que les utilisateurs puissent facilement déterminer le lien approprié sur lequel cliquer, même si cela ne fait que les renvoyer à une autre page de liens. Les tâches les plus fréquentes doivent être les plus visibles et nécessiter le moins de navigation possible. Les tâches moins fréquentes peuvent nécessiter davantage d'étapes.
Voici un exemple tiré de Money 2000. Supposons que les utilisateurs souhaitent effectuer une opération qu'ils ne font qu'occasionnellement, comme vérifier le montant estimé du paiement de l'impôt sur le revenu de l'année suivante. Les utilisateurs commencent par rechercher cette fonctionnalité sur la page d'accueil de Money 2000. Comme la fonctionnalité n'apparaît pas dans la liste des tâches courantes, ils doivent analyser la liste des domaines financiers. La zone des taxes semble prometteuse, ils cliquent donc dessus. La page du Centre fiscal contient un lien vers la fonction d'estimation des taxes qu'ils recherchent, ils cliquent donc dessus et terminent leur tâche. En appliquant les principes de l'IUI, Money 2000 permet aux utilisateurs de trouver intuitivement ce qu'ils recherchent.
Assistance utilisateur
Cette section décrit un ensemble de lignes directrices suggérées pour l'intégration du texte d'assistance à l'utilisateur dans un produit qui utilise l'IUI.
L'assistance primaire fait référence à tout le texte visible à l'écran (comme le montre la capture d'écran suivante). L'assistance primaire fournit des indices textuels axés sur la tâche afin que les utilisateurs puissent facilement comprendre toutes les informations présentées à l'écran. Ils comprennent l'objectif de la page et la manière dont les objets sont liés les uns aux autres pour les aider à accomplir leurs tâches. Le texte étant directement affiché à l'écran, les informations qui répondent à des questions novices telles que « Que dois-je faire ? » sont faciles d'accès et très visibles, sans que l'utilisateur n'ait à faire quoi que ce soit.
L'assistance secondaire est constituée de tout le texte qui n'est pas visible à l'écran et dont l'accès nécessite une certaine interaction de la part de l'utilisateur, par exemple en cliquant ou en survolant un élément de l'interface utilisateur. Ce contenu n'est pas essentiel à l'accomplissement de la tâche à accomplir, mais il est tout de même directement lié.
Assistance primaire
L'assistance primaire peut comprendre tout ou partie des éléments suivants :
Titre de l'écran
Exemple : Changez votre image
Le titre de l'écran est le premier et le plus important élément qui apparaît à l'écran. Il a pour but de décrire, dans la langue de l'utilisateur, la tâche qui peut être accomplie sur cette page. Le titre de l'écran doit éviter de décrire les détails de l'exécution de la tâche. Le texte du titre d'écran ne doit faire référence qu'à la tâche principale de l'écran. En règle générale, plus la description de la tâche est simple et courte, mieux elle est définie. Pour plus d'informations sur ce sujet, reportez-vous à l'étape 2 : Énoncez la tâche.
Sous-titre de l'écran
Exemple : Vous pouvez également télécharger une nouvelle image à partir d'Internet.
Même avec beaucoup d'efforts, le titre de l'écran peut ne pas suffire à expliquer correctement une tâche complexe. Le sous-titre vous permet de préciser l'objectif de l'écran. Vous pouvez utiliser un sous-titre pour clarifier l'objectif de la page, fournir une description supplémentaire de la tâche ou aider à définir les attentes. Les utilisateurs qui ne lisent pas le sous-titre devraient pouvoir utiliser la page avec succès. Tout comme le titre, le sous-titre doit éviter de décrire les détails de la réalisation de la tâche.
Tâches
Exemple : Changez votre économiseur d'écran
Les tâches peuvent être présentées sous forme de liens textuels ou d'images graphiques nécessitant une interaction avec l'utilisateur. Les commandes présentées sous forme de liens textuels doivent être basées sur des verbes et rédigées comme des tâches claires et concises.
Étiquettes pour les boutons de commande
Exemple : Créer un mot de passe
Il existe trois types de boutons de commande :
- Annuler
- Terminé
- Validation
Les boutons « Annuler » et « Terminé » utilisent simplement « Annuler » et « Terminé » comme libellés. Les boutons d'engagement doivent utiliser des étiquettes de texte actif au lieu de « OK ». Par exemple, utilisez « Créer un mot de passe » au lieu de « OK ».
Étiquettes pour d'autres contrôles
Exemple : Tapez votre mot de passe
Les étiquettes des contrôles tels que les boutons radio, les cases à cocher et les zones de texte doivent être rédigées de manière claire et concise afin que les utilisateurs sachent exactement à quoi servent les contrôles, lesquels utiliser et quelles informations doivent être fournies pour accomplir leur tâche.
Liens « Tâches connexes »
Exemple : Tâches connexes - Modifier un autre compte
Les liens « Tâches connexes » sont des points d'entrée explicites vers d'autres tâches liées à la fonctionnalité en cours. Ils doivent être rédigés comme des liens basés sur des tâches.
Liens « Voir aussi »
Exemple : Voir aussi - Modifier votre thème
Les liens « Voir aussi » sont des tâches secondaires. Ils sont liés à la tâche principale, mais sortent l'utilisateur du contexte actuel. Ils doivent apparaître comme des liens de tâches normales. Pour plus d'informations sur les tâches secondaires, voir Conception visuelle des tâches secondaires.
Assistance secondaire
L'assistance secondaire peut inclure tout ou partie des éléments suivants :
InfoTips
Vous pouvez utiliser un InfoTip pour fournir à l'utilisateur des informations supplémentaires sur un lien de tâche ou un bouton de commande. Par exemple, un InfoTip sur un lien de tâche peut être libellé comme suit : « Affiche une page où vous pouvez choisir une image à utiliser avec votre compte ». L'InfoTip apparaît lorsque l'utilisateur passe la souris sur l'objet associé. Vous devez créer des InfoTips pour tous les éléments de l'interface utilisateur sur lesquels l'utilisateur peut cliquer.
Rubriques d'aide « En savoir plus ».
Exemple : En savoir plus sur le téléchargement d'un fichier
Les liens « En savoir plus » ouvrent des rubriques d'aide telles que des aperçus de fonctionnalités, des informations conceptuelles, des informations complémentaires et des informations procédurales. Pour réduire l'encombrement, vous devez minimiser le nombre de rubriques d'aide « En savoir plus » à l'écran.
Annexe : Conception et test de Microsoft Money 2000
Cette section a été adaptée à partir des descriptions de première main des concepteurs. Elle explique comment l'équipe de Money 2000 a modifié le processus de conception et de test pour s'adapter au modèle IUI.
Conception et test de Money 2000
La conception de Money 2000 à l'aide du modèle de navigation inductive a conduit l'équipe à remettre en question des conceptions qui figuraient dans le produit depuis longtemps. Les principes du modèle étant simples, il a été facile de l'adopter dans le processus de conception et de s'y tenir. En fin de compte, les concepteurs estiment que le modèle les a aidés à réaliser de meilleures conceptions que celles qu'ils auraient pu produire sans lui.
Des titres et des dessins plus clairs
Les concepteurs de Money 2000 ont remarqué qu'ils décrivaient souvent les fonctionnalités en utilisant des mots qui n'apparaissaient pas réellement à l'écran. Dans le modèle IUI, les écrans doivent s'expliquer d'eux-mêmes. Par exemple, l'équipe a expliqué que l'écran intitulé Calendrier des paiements était destiné au paiement des factures. Dans Money 2000, cet écran s'appelle Payer des factures. Tous les éléments qui ne sont pas liés à cet objectif ont été déplacés vers des écrans secondaires, ce qui a permis de clarifier la conception.
Un autre exemple concerne un écran appelé Gestionnaire de services financiers en ligne. L'équipe s'est efforcée de trouver une explication simple de l'objectif de cet écran. N'y parvenant pas, elle a supprimé cet écran et réparti ses fonctionnalités sur des pages plus logiques.
Aider les nouveaux concepteurs
L'équipe a trouvé qu'il était facile d'enseigner les techniques de conception de l'interface utilisateur aux nouveaux concepteurs de logiciels inexpérimentés. Ces techniques ont permis aux concepteurs, quel que soit leur niveau d'expérience, d'évaluer leurs conceptions en utilisant les titres d'écran comme test de clarté. Lorsqu'ils ont été contraints de mettre un titre clair et concis sur un écran mal conçu, les concepteurs ont rapidement reconnu qu'aucun titre n'était assez bon pour la page. Ils ont compris que le problème ne résidait pas dans le choix des mots d'un titre, mais plutôt dans une conception défectueuse de l'écran. Forts de cette compréhension, ils ont pu revoir la conception de l'écran pour permettre une interaction plus claire avec l'utilisateur et, par conséquent, un titre plus clair.
Inclure les rédacteurs
Au fur et à mesure de l'avancement de la conception, l'équipe s'est rendu compte que les rédacteurs et les éditeurs de documentation devaient être impliqués dans la création des titres d'écran. Les rédacteurs étaient limités dans leur capacité à choisir de bons titres dans les versions précédentes parce qu'ils n'étaient impliqués qu'à un stade tardif. Les écrans recevaient généralement des titres de travail temporaires de la part des concepteurs ou des programmeurs. Ces titres étaient utilisés jusqu'à la fin du cycle du produit, lorsqu'il était demandé aux rédacteurs d'élaborer les titres définitifs des écrans. À ce stade, il était trop tard pour retravailler des écrans mal conçus.
En revanche, l'équipe de Money 2000 a impliqué les rédacteurs dès les premières étapes du processus de conception. Cela leur a permis d'apporter une contribution précieuse sur les titres d'écran alors qu'ils pouvaient encore aider à la conception. Si un écran était trop complexe pour permettre un titre clair, les rédacteurs pouvaient suggérer que la page soit redessinée.
À la fin du projet, les rédacteurs et les concepteurs ont estimé que les titres d'écran étaient plus clairs et plus forts que dans les versions précédentes. Les rédacteurs ont également trouvé qu'il était plus facile d'expliquer les nouvelles pages, ce qui a simplifié le travail de documentation du produit. Tous les membres de l'équipe ont estimé que l'implication de toutes les disciplines dans la phase de conception a permis d'améliorer le produit et d'en faciliter l'utilisation.
Tests de convivialité
Pendant le développement de Money 2000, l'équipe a effectué plusieurs tests de convivialité pour examiner les différences entre l'ancienne structure de navigation de Money 99 et les changements apportés par l'application du modèle IUI.
Essais de prototypes
Au début du processus de développement du produit, les concepteurs ont créé un prototype pour explorer la façon dont les utilisateurs réagiraient à l'IUI. Ce travail a été effectué très tôt dans le processus de développement afin d'avoir le temps d'affiner les principes du modèle avant que les programmeurs ne commencent à remanier le produit lui-même.
L'équipe a créé un prototype en Microsoft Visual Basic et HTML qui simulait les activités financières personnelles normalement effectuées dans Money. Dans le prototype, les utilisateurs pouvaient naviguer sur plus de 50 pages représentant les principaux domaines du produit. Dans ces domaines, ils pouvaient créer des comptes financiers, payer des factures, consulter des rapports et travailler sur leurs investissements.
Onze participants ont effectué le même ensemble de tâches avec Money 99 et le prototype de l'IUI. Ils ont été désignés au hasard pour utiliser l'un des produits en premier. Quatre participants étaient des utilisateurs actuels de Money, quatre étaient des utilisateurs actuels d'un produit concurrent et trois n'avaient jamais utilisé de produit de finances personnelles auparavant.
Les préférences générales ont indiqué que les quatre utilisateurs actuels de Money préféraient Money 99 (la version qu'ils utilisaient à la maison) tandis que les sept autres utilisateurs préféraient le nouveau prototype à la version actuelle. Pour toutes les autres mesures, il n'y avait pas de différence entre les utilisateurs des trois groupes. En termes de performance globale, les utilisateurs se sont trompés de zone deux fois plus souvent avec Money 99 (2,82 fois par tâche) qu'avec le prototype (1,45 fois par tâche). D'autres données de préférence et mesures de performance, bien que non significatives, semblent favoriser le prototype. Sur la base de ces données et d'autres tests, l'équipe chargée du produit Money a décidé d'incorporer les principes de l'IUI dans Money 2000.
Test du produit
Une fois la majorité du code du produit achevée, l'équipe a réalisé une autre étude de convivialité pour examiner la mise en œuvre finale de l'interface utilisateur. Dans ce test, 10 participants qui n'avaient jamais utilisé un produit de finances personnelles auparavant ont été sélectionnés pour utiliser soit Money 99, soit Money 2000. Tous les utilisateurs ont effectué les mêmes tâches.
Les utilisateurs de Money 2000 ont accompli 89% des tâches, tandis que les utilisateurs de Money 99 n'en ont accompli que 74%. Comme pour le prototype, les utilisateurs ont semblé plus rapides, mais pas de manière significative, pour naviguer dans Money 2000 par rapport à Money 99. En outre, les mesures globales de satisfaction subjective pour la navigation ont également eu tendance à être plus élevées pour Money 2000 que pour Money 99.
Tests contrôlés
Money 2000 étant énorme et complexe, il ne se prête pas à la réalisation d'expériences contrôlées sur les effets de l'application de l'IUI. L'équipe a donc créé un environnement plus contraignant pour le test.
Le test comprenait une application « Stock Market Viewer » qui permettait aux utilisateurs de modifier l'affichage d'un rapport boursier à l'écran. Les utilisateurs pouvaient modifier les colonnes de données incluses dans le rapport, l'ordre des colonnes du rapport, leur alignement et le nombre de décimales utilisées. Les concepteurs voulaient voir comment une approche IUI de cette tâche se comporterait par rapport à une interface utilisateur graphique conventionnelle.
La capture d'écran suivante montre l'interface utilisateur conventionnelle utilisée dans le test. Une seule boîte de dialogue permet d'effectuer toutes les tâches de personnalisation des rapports. De nombreuses applications proposent une boîte de dialogue similaire pour sélectionner un sous-ensemble dans une liste d'éléments. La boîte de dialogue contient deux listes : la liste de gauche affiche toutes les colonnes disponibles du rapport et la liste de droite affiche le sous-ensemble de colonnes que l'utilisateur a sélectionné pour le rapport. Des contrôles supplémentaires modifient l'ordre et les attributs de formatage des colonnes de l'état sélectionnées dans la liste de droite.
Pour la version IUI de cette tâche, l'équipe a créé une application de type Web. Chaque tâche de personnalisation a été placée sur une page distincte. L'application comprenait également une page principale, illustrée dans la capture d'écran suivante, qui demandait aux utilisateurs comment ils souhaitaient personnaliser le rapport.
En cliquant sur les liens de cette page principale, l'utilisateur accède à des pages supplémentaires lui permettant d'effectuer des tâches de personnalisation spécifiques. Par exemple, la capture d'écran suivante montre la page utilisée pour sélectionner les colonnes du rapport.
Dans les tests des deux versions, les sujets ont été invités à personnaliser des rapports à partir d'un état initial donné (affiché à l'écran) jusqu'à un état final spécifié (affiché sur un document papier). L'ordinateur a enregistré le temps et le nombre de tentatives des sujets pour personnaliser le rapport. L'ordinateur informait les utilisateurs lorsqu'ils avaient réussi à personnaliser le rapport.
Le test a été réalisé auprès de 88 participants. Chaque participant a été invité à personnaliser un ensemble de 11 rapports avec l'une des deux versions de l'application. En outre, 72 de ces participants sont revenus une semaine plus tard pour personnaliser une autre série de 11 rapports en utilisant la même version que lors de la première session. Chaque sujet a été classé comme un utilisateur novice d'ordinateur, utilisant principalement l'ordinateur pour le courrier électronique, jouer au solitaire et surfer sur le Web.
Il n'y avait pas de différences significatives entre les utilisateurs des deux versions ou entre les autres variables d'intérêt. Les utilisateurs ont effectué les tâches à la même vitesse, ont répété la tâche le même nombre de fois et ont obtenu les mêmes notes de satisfaction subjective globale pour les deux versions. Ce test n'a donc pas permis de mettre en évidence des mesures dans lesquelles l'IUI aurait entraîné une amélioration ou une dégradation des performances ou des évaluations subjectives.
On pourrait faire valoir que si l'utilisateur doit naviguer davantage pour effectuer une tâche, le temps nécessaire à l'exécution de cette tâche devrait être plus important. Bien que cette expérience ne suggère pas ce résultat, il est important de noter que les temps de performance moyens et les écarts types associés pour les deux approches différentes de cette tâche étaient presque identiques.
D'autres recherches seront nécessaires pour déterminer si l'utilisation de l'IIU entraîne des améliorations mesurables. À tout le moins, ce test n'a pas apporté la preuve que l'assurance-chômage nuit à la performance ou à l'utilisation du produit.
Comparaison avec des sites Web
De nombreux sites Web bien conçus utilisent des principes similaires au modèle d'IUI décrit dans ce document. Il s'agit probablement d'un effet secondaire du fonctionnement du Web. Comme il est difficile de mettre en œuvre des interactions complexes entre des contrôles sur une seule page Web, les concepteurs divisent souvent les tâches en plusieurs parties qui impliquent plus d'un voyage vers le serveur pour obtenir une nouvelle page. Certains sites comportent même des titres de page qui indiquent clairement l'objectif de la page.
Les concepteurs d'applications traditionnelles disposent d'un ensemble d'outils beaucoup plus riche. Cela leur donne plus de flexibilité, mais aussi plus de possibilités de créer des pages complexes et confuses. Lorsqu'ils créent des interfaces utilisateur inductives, les concepteurs doivent utiliser ce pouvoir avec discernement et ne pas oublier d'accorder de l'importance à la clarté et à la simplicité.