Activité :
|
Objet
|
|
Rôle : Concepteur d'interface utilisateur | |
Fréquence :
En pratique, la conception de l'interface utilisateur est généralement effectuée en conjonction avec le prototype de l'interface utilisateur (voir l'activité de création du prototype de l'interface utilisateur). Lors de la conception de l'interface utilisateur, vous devez continuellement présenter un prototype de votre conception aux autres et tenir compte des recommandations spécifiques au projet. Toutefois, une conception "complète" d'interface utilisateur n'est pas effectuée avant la création du prototype correspondant. Il est souvent conseillé de reporter la conception détaillée de l'interface utilisateur et de l'effectuer après la création et la revue de plusieurs itérations d'un prototype d'interface utilisateur |
|
Etapes
Ces étapes sont présentées selon un ordre logique, mais vous devrez peut-être alterner entre les différentes étapes ou effectuer certaines d'entre elles en parallèle. Certaines étapes peuvent être facultatives, en fonction de la complexité de l'interface utilisateur concernée. |
|
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : | |
Plus d'informations :
Pour obtenir des informations complètes sur la création de conceptions qui traitent tout particulièrement des possibilités d'utilisation, voir [CON99]. |
Détails sur l'enchaînement d'activités : |
Lorsque vous concevez l'interface utilisateur, tenez compte des Storyboards créés pendant la formulation des exigences, des recommandations spécifiques au projet, ainsi que des prototypes d'interface utilisateur. Si vous devez affiner les storyboards à l'issue de cette activité, ces mises à jour sont effectuées par l'analyste système (voir l'activité de mise à jour des requêtes des parties prenantes).
Décrivez les caractéristiques des utilisateurs (humains) qui interagiront avec le système pour satisfaire les exigences de l'itération en cours. Attachez-vous à décrire les utilisateurs principaux, car la plus grande partie des interactions concerne ces utilisateurs. Ces informations sont importantes pour les étapes ci-après.
Collaborez avec l'analyste système afin de déterminer si des modifications doivent être apportées à la description d'Acteur pour refléter les descriptions des caractéristiques. Pour plus d'informations, voir les Principes et conseils sur les acteurs et les caractéristiques.
En recherchant les exigences définies dans l'itération en cours (spécialement les cas d'utilisation et/ou les Storyboards), identifiez les principales fenêtres de l'interface utilisateur du système. Les fenêtres "principales" sont les fenêtres avec lesquelles l'utilisateur interagira le plus (les éléments de l'interface qui se trouvent au centre du modèle du système tel que se le représente l'utilisateur). Elles contiennent des menus et peuvent contenir également des panneaux ou des formulaires. Les fenêtres principales sont les fenêtres entre lesquelles l'utilisateur navigue. Toutefois, une fenêtre peut devenir une partie de fenêtre principale.
La première fenêtre principale doit être celle qui s'ouvre lorsque l'utilisateur lance l'application. Elle reste normalement toujours ouverte pendant que l'application est en cours d'exécution ; c'est dans cette fenêtre que l'utilisateur passe une partie considérable de son temps d'utilisation. Etant donné qu'elle est toujours ouverte et constitue le premier contact de l'utilisateur avec le système, elle constitue le principal vecteur de mise en application du modèle de système tel que se le représente l'utilisateur. La première fenêtre principale est généralement appelée "page d'accueil".
Tentez de regrouper les éléments de l'interface utilisateur dans la même fenêtre principale s'ils doivent s'afficher ensemble ou en relation spatiale avec d'autres éléments de l'interface utilisateur. Mais cela n'est pas toujours possible en raison des limites imposées par la taille de l'écran. Il est à noter que les volumes d'objet moyens constituent une entrée importante à cette étape, car ils indiquent le nombre d'objets devant potentiellement être affichés simultanément. Si trop d'objets doivent être affiché, ils ne pourront pas tous apparaître dans la même fenêtre. Par conséquent, une représentation compact des objets s'affiche dans la fenêtre principale et d'autres fenêtres principales peuvent être définies pour chacun des objets (ou ensembles d'objets).
Les recommandations suivantes s'appliquent aux fenêtres principales :
Souvenez-vous que l'objectif consiste à minimiser le nombre de fenêtres principales et le nombre de chemins de navigation entre celles-ci.
Sur la base des fenêtres principales identifiées et des Storyboards, définissez la carte de navigation du système.
La carte de navigation doit inclure les principaux éléments de l'interface utilisateur et leurs chemins de navigation. Elle ne doit pas nécessairement contenir tous les chemins d'accès possibles aux différents éléments de l'interface utilisateur, mais seulement les principales voies d'accès. L'objectif est que la carte de navigation puisse servir de carte routière de l'interface utilisateur du système.
Il est évident que la page d'accueil (la fenêtre dans laquelle l'utilisateur passe la plus grande partie de son temps d'utilisation) est un élément potentiel privilégié pouvant devenir l'élément "clé" de l'interface utilisateur dans la carte de navigation.
La carte de navigation doit indiquer le nombre de clics qu'un utilisateur doit effectuer pour obtenir l'affichage d'un écran ou d'une fonction spécifique. Généralement, vous souhaitez afficher "en un seul clic" les zones les plus importantes de l'application à partir de la fenêtre principale. Si vous indiquez des chemins de navigation trop longs, cela entraîne (outre l'ajout d'interactions inutiles consommant du temps système), une situation où l'utilisateur risque de se perdre dans le système. Idéalement, toutes les fenêtres doivent s'ouvrir à partir de la page d'accueil, ce qui porte le nombre de fenêtres ouvertes à deux. Tentez d'éviter d'avoir plus de trois fenêtres ouvertes entre lesquelles vous naviguez.
La carte de navigation doit également refléter la métaphore d'utilisation applicable à l'interface utilisateur du système, comme l'illustrent les recommandations spécifiques au projet.
Vous pouvez utiliser une grande variété de représentations pour la carte de navigation. En voici quelques exemples :
La sélection de la représentation à utiliser est spécifiée dans les recommandations spécifiques au projet.
A ce stade, la conception de l'interface utilisateur est terminée :
La conception détaillée des éléments de l'interface utilisateur peut désormais être effectuée. Les aspects suivants décrivent la conception des éléments de l'interface utilisateur. Chacun d'entre eux fait l'objet d'une description ci-après :
La visualisation des fenêtres principales et de la page d'accueil en particulier aura un impact important sur les possibilités d'utilisation du système. Sa conception consiste à déterminer les parties (propriétés) des éléments qui seront visualisées. Le Storyboard contient le flot des événements à utiliser pour établir les priorités d'affichage des propriétés. Si l'utilisateur a besoin d'afficher un grand nombre de propriétés des éléments de l'interface utilisateur, vous pouvez implémenter plusieurs vues d'une fenêtre principale (chaque vue permettant d'afficher un ensemble différent de propriétés). Pour concevoir cette visualisation, vous devez également déterminer comment ces propriétés doivent s'afficher, en utilisant toutes les dimensions visuelles. Pour plus d'informations, accédez à la section sur les "dimensions visuelles" des Principes et conseils sur l'interface utilisateur (général).
Dans la mesure du possible, tentez d'identifier les "dénominateurs communs" de tous les éléments à afficher dans les fenêtres principales. Grâce à la visualisation des dénominateurs communs dans une dimension spécifique, l'utilisateur peut relier les éléments entre eux et commencer à voir se dégager des schémas. Cela augmente considérablement la "largeur de bande" de l'interface utilisateur.
Supposons que vous disposiez d'un système d'assistance clientèle, dans lequel vous souhaitez afficher des aspects tels que:
Ici, le commun dénominateur est la "durée." Par conséquent, l'affichage des réclamations/questions, des achats et des factures sur le même axe horizontal permet à l'utilisateur de voir les schémas des relations entre les différents éléments (le cas échéant).
Vous devez déterminer la méthode d'"implémentation" des actions utilisateur qui peuvent être appelées dans les fenêtres principales. Ces actions prennent souvent la forme d'options de menus présentées sur une barre de menus et sont complétées par des raccourcis et des barres d'outils.
Pour chaque fenêtre principale, définissez les menus et les options de menus. Par exemple, dans un éditeur de texte, un menu Edition regroupe des opérations telles que Couper, Copier, etc.
Certaines actions utilisateur peuvent nécessiter une interaction complexe avec l'utilisateur, ce qui justifie la présence d'une fenêtre secondaire indépendante. Par exemple, dans un éditeur de texte, une opération d'impression de document requiert une interaction complexe et justifie l'affichage d'une boîte de dialogue séparée.
Si un grand nombre d'objet doit être visualisé dans une fenêtre, il peut être nécessaire de concevoir des actions utilisateur pour ces objets. Voici des exemples d'actions utilisateur :
Pour plus d'informations, voir les Principes et conseils sur l'interface utilisateur (général).
Ajoutez le comportement dynamique requis à l'interface utilisateur. La caractéristique dynamique est le plus souvent fournie par la plate-forme cible (paradigme de sélection qui s'ouvre via un double clic, menus contextuels qui s'affichent via un clic sur le bouton droit de la souris, etc.). Vous devez toutefois prendre certaines décisions, comme par exemple :
Evaluez également d'autres caractéristiques susceptibles d'augmenter les possibilités d'utilisation de l'interface, comme par exemple :
Pour plus d'informations, voir les Principes et conseils sur l'interface utilisateur (général).
RUP (Rational Unified Process)
|