Prototypage.

Prototypage

Sortes de prototypes Servent à la conception, et au tests avec les utilisateurs Sortes de prototypes: Prototype statique / dynamique Prototype de haute fidelité / basse fidelité Prototype horizontal / vertical Prototype horizontal Prototype vertical Système complet

Prototypes en papier Basse fidelité Vites à faire et à modifier
Peuvent utiliser le papier, les transparences, les collants (“post-its”), les cartes en carton, les ciseux, ruban gommé, crayons, stylos, ...

Le bureau d’un concepteur
Studio de design IDEO (pris de l’article de Guimbretière, Stone, Winograd, UIST 2001)

Exemples … can create pre-made interface components on paper
eg, these empty widgets were created in visual basic and printed out: buttons menu alert box combo box list box tabs entries

Des outils flottants ou optionnels ...

Storyboarding a series of key frames
originally from film; used to get the idea of a scene snapshots of the interface at particular points in the interaction

Example frame from a movie Storyboard

Storyboard of a computer based telephone
Computer Telephone Last Name: First Name: Phone: Place Call Help Help-> Return Help Screen You can enter either the person's name or their number. Then hit the place button to call them Call by name-> Computer Telephone Last Name: Greenberg First Name: Phone: Place Call Help Establishing connection-> Computer Telephone Last Name: Greenberg First Name: Phone: Place Call Help Dialling.... Cancel Call connected... Computer Telephone Last Name: Greenberg First Name: Phone: Place Call Help Connected Hang up Call completed...

Prototypage en papier Avantages: Vites à faire et à modifier
“Un maximum de feedback pour un minimum d’effort” (Snyder) Vites à faire et à modifier Ne demande pas d’expertise Aspect informel encourage la créativité Ne donne pas l’impression au client que l’interface est presque finie Évitent que les concepteurs soient attachés à la conception et qu’ils hésitent de la changer Évitent que les utilisateurs hésitent de suggérer des gros changements Permettent les utilisateurs à participer dans la conception Exemples: PICTIVE (“Plastic Interface for Collaborative Technology Initiative through Video Exploration”, Muller 1992), une technique de conception participatoire (“participatory design”)

Exercise en classe ! (distribuer les descriptions des exercises)
Pourquoi garder des détails secrets de votre participant eventuel ? Dessiner vos … Fenêtres Dialogues Menus Curseur(s) Messages d’erreur Images “vidéo” N.B.: pas un “storyboard”, mais plutôt montrer l’écran de départ et ensuite montrer la réaction aux entrées du participant

Exercise en classe ! (suite)
Tester avec un utilisateur Rappelez à votre participant de penser à haute voix (la technique “think aloud”) Montrer ce qui arrive en réponse aux actions du participant Expliquer le moins possible ce qui arrive ou pourquoi, à moins que le participant soit bloqué ou complètement “dans le champ” Prenez en note les problèmes rencontrés par l’utilisateur (exemples: erreurs, sources de confusion) À la fin de la session, échangez des commentaires et des suggestions librement

Exercise en classe ! (suite)
Avez-vous observé beaucoup de problèmes ? Plus de problèmes que vous aurez pensé au départ ? Est-ce que vos deux participants ont eux des problèmes différents ? Donc, vaudrait-t-il la peine de tester avec encore plus d’utilisateurs ? Si vous aviez à refaire cet exercise, qu’est-ce que vous auriez fait différemment ?

D’autres techniques de prototypage
Pages web (HTML) statiques Images Visio Adobe PhotoShop, GIMP, Adobe Illustrator, Paint.NET (permettent de travailler avec des couches (“layers”)) (Démonstration de GIMP) Outils de présentation Director Du code exécutable, sans fonctionalité VisualBasic, Java, C++ (Qt), etc. Il existe des outils glisser-déposer pour créer une interface graphique avec des widgets standards (Exemple: NetBeans pour le Java) Questions: lesquels de ces techniques sont statiques / dynamiques, basse / haute fidelité, horizontal / vertical ?

Le « napkin look-and-feel »

D’autres techniques de prototypage (suite)
Le prototypage par la technique du “Magicien d’Oz” (“Wizard-of-Oz”) Exemple: simulation de reconnaissance de la voix parfaite Le prototypage par vidéos Utiles pour montrer une vision Exemples (montrer les vidéos): KnowledgeNavigator de Apple Questions: haute ou basse fidelité? Horizontal ou vertical? Interfaces pour écrans volumiques Wearable interface: « 6th sense » Nokia Morph Microsoft 2019

Systèmes de prototypage expérimentaux
SILK (Sketching Interfaces Like Krazy) Landay et Myers 2001

Systèmes de prototypage expérimentaux (suite)
DENIM ( Montrer la vidéo

Balsamiq

AppSeed http://www. kickstarter

Prototypage physique Pour les interfaces matérielles
Exemple: Les phidgets – “physical widgets” / Greenberg et Fitchett 2001 (montrer la vidéo)

Exemple Phidget: Un capteur “RFID” + téléphone cellulaire

Exemple Phidget: Jeu d’exercise avec Tetris et des poids

Prototypage physique (suite)
Exemple: BUG (buglabs.net)

Quels sont les avantages de prototyper plusieurs alternatives en parallèle ?
Permet d’explorer plus de possibilités et peut-être d’en combiner Permet d’éliminer une mauvaise idée de départ Séparation de notre égo des idées conçues – on accepte mieux les critiques Encourage la comparaison de différentes possibilités

Exemple de SIGA (logiciel pour accéder aux comptes financiers)

Fenêtre impossible à redimensionner
Fenêtre impossible à redimensionner. De plus, le scrollbar vertical fait un rafraîchissement seulement au relâchement. (Et, encore pire, anciennement, la colonne “solde” était complètement à l’extrémité droite.)

Pourquoi ai-je besoin de saisir une intervalle de temps et lancer une requête ? Par défaut je devrais voir toutes les activités récentes.

Ce n’est pas évident de savoir quel bouton appuyer.

Que veut dire “Réel”. Ah, ça veut dire “dépenses à date”
Que veut dire “Réel” ? Ah, ça veut dire “dépenses à date”. Pourtant, il y a suffisamment d’espace pour afficher une déscription explicite.

Les 6 premières colonnes me sont inutiles
Les 6 premières colonnes me sont inutiles. Je dois perdre du temps à scroller.

Rendu ici, j’ai compris que “paie” veut dire “bourse”
Rendu ici, j’ai compris que “paie” veut dire “bourse”. Cela m’a pris 14 clics pour savoir à quel étudiant j’ai donné cette bourse. Impossible de savoir le montant total donné à cet étudiant (sur plusieurs bourses) à date sans ouvrir chaque paiement un-par-un et faire la somme moi-même.

Les 4-5 premières colonnes me sont inutiles
Les 4-5 premières colonnes me sont inutiles. Je dois perdre du temps à scroller.

L’onglet “Référence interne” est vide; pourquoi alors le montrer par défaut ? L’onglet “Ventilation” semble prometteur …

Chiffres qui ne veulent rien dire pour moi
Chiffres qui ne veulent rien dire pour moi. Comment comprendre la raison derrière chacun des montants? Les loupes à côté de chaque montant sont grisées. J’essaie alors les loupes à droite.

Aucune information supplémentaire. Pourquoi alors m’offrir la loupe ?

Le système que nous venons de voir a été développé post-2005, et a coûté des dizaines (centaines?) de milliers de dollars à l’Université du Québec, et a été déployé à l’interne avec de cours pour former les employés. Pourtant, il m’est tellement inutilisable, que je m’en sers uniquement pour voir le solde actuel dans chacun de mes comptes de recherche. Sur mon laptop, je garde en local un fichier privé qui contient une liste de mes dépenses et des bourses que j’ai émises, en ordre chronologique inverse (comme un relevé bancaire), regroupées par compte de recherche. Je garde ce fichier à jour de façon réligieuse, et je serais perdu sans ce fichier. Et je sais que je ne suis pas le seul employé à utiliser un tel “système parallèle” pour me retrouver. Certains employés ont même rebaptiser le logiciel “SIGA” avec le nom semblable d’une maladie contagieuse …

L’interface utilisateur pour SIGA a peut-être été généré par un système de base de données (peut-être Oracle Forms?). Cela donne une interface centrée sur le modèle de données. En théorie, une telle interface permet de voir toutes les données, mais n’est peut-être pas du tout optimisée pour les tâches typiques des utilisateurs.

Une deuxième approche partirait des tâches des utilisateurs
Une deuxième approche partirait des tâches des utilisateurs. Prenons, par exemple, juste les tâches d’un seul intervenant: moi-même (un professeur). Mes tâches sont: - Voir une vue d’ensemble de mes comptes, pour voir le solde de chacun (pour m’aider à planifier des dépenses et des bourses) - Voir l’historique des dépenses+bourses venant d’un compte - Voir une vue d’ensemble de mes étudiants, avec peut-être le total des bourses qu’ils ont eu de moi à date, et peut-être la date et le montant de leur prochaine bourse de moi - Voir, pour un de mes étudants en particulier, l’historique des bourses qu’il/qu’elle a reçues de moi - Faire un transfert d’un montant d’un compte vers un autre - Donner une bourse à un étudiant (notez: la bourse peut venir de plusieurs comptes en même temps)

Cette deuxième approche, centrée sur les tâches, pourrait proposer une interface avec un menu principal qui permet de choisir la tâche: Vue d’ensemble des comptes … Historique d’un compte … Vue d’ensemble des étudiants … Historique d’un(e) étudiant(e) … Transfert entre comptes … Donner une bourse … On aurait alors une “fenêtre” ou un “wizard” pour chaque tâche, montrant seulement les informations nécessaires pour chaque tâche. Malheureusement, cela empêche à l’utilisateur de voir facilement une vue d’ensemble des données. De plus, seulement les tâches simplistes seront permises, et l’utilisateur pourra avoir de la difficulté à changer de tâche ou d’idée en cours de route. De plus, les mêmes informations peuvent être affichées dans plusieurs fenêtres, rendant le modèle conceptuel plus compliqué et difficile.

Une troisième approche propose de partir d’une liste des tâches, mais de concevoir des fenêtres autour des informations nécessaires pour une ou plusieurs tâches. On peut distinguer entre 3 étapes de conception dans cette approche: Le “information design” : décider quelles informations seront affichées, et où Le “interaction design” : décider quels seront les widgets, menus, boutons, etc. permettant de lancer les fonctionnalitées nécessaires dans chaque fenêtre Le “graphic design” : décider des couleurs, polices, style visuel L’approche des “fenêtres virtuelles” de Lauesen et Harning (2001) est une manière (parmi d’autres) de prendre cette 3e approche, et de faire le “information design” avant le “interaction design”.

La méthode des fenêtres virtuelles (Lauesen et Harning 2001)

Fenêtres virtuelles Introduction
Lauesen propose de concevoir l'interface utilisateurs en deux étapes Concevoir des fenêtres virtuelles, montrant les données, en fonction des tâches Correspond à la conception d’information (« information design »): on s’occupe de l’information qui sera présentée à l’utilisateur, et non de la façon d’interagir avec On ne met pas de boutons, menus, etc. dans ces fenêtres Ajouter les fonctionnalités (widgets) par la suite LOG350 A2006 Analyse, vision et domaine

Fenêtres virtuelles Processus de construction des fenêtres
Partir des tâches les plus fréquentes et les plus importantes Regrouper les données dans quelques fenêtres virtuelles Continuer les étapes 1 et 2 pour d'autres tâches Si les données sont dans une fenêtre déjà existante, essayer d'accomplir cette tâche avec la même fenêtre Si des données manquent à une fenêtre, augmenter celle-ci, si possible LOG350 A2006 Analyse, vision et domaine

Fenêtres virtuelles Règles de construction
Utiliser le moins de modèles de fenêtre possible Utiliser le moins d'instances de fenêtre possible pour une tâche Surtout pour les tâches importantes/fréquentes Évitez les séquences étape-par-étape extrèmes (exemple: les « Wizard ») Essayer d’avoir chaque donnée affichée dans une seule fenêtre, surtout quand les données seront modifiables Sinon, ça peut nuire à la formation d’un bon modèle conceptuel Les fenêtres virtuelles peuvent être plus petites que la taille réelle de l'écran Plus tard, elles pourront être combinées LOG350 A2006 Analyse, vision et domaine

Fenêtres virtuelles Règles (suite)
Une vue d'ensemble aide énormément l'utilisateur: à savoir où il est rendu à réduire le nombre d'étapes de navigation à prendre plus rapidement une décision … donc, essayer de donner des vues d’ensembles des données dans vos fenêtres! LOG350 A2006 Analyse, vision et domaine

Fenêtres virtuelles Règles (suite)
Baser les fenêtres sur des objets, pas sur des actions. Commencer par nommer les fenêtres par des noms d'objets plutôt que des nom de fonctions "chambre", "dossier client", "profile" pas: "entrer une réservation de chambre", "consulter un dossier client" Une tâche peut correspondre à plusieurs fenêtres virtuelles, et une fenêtre virtuelle peut permettre plusieurs opérations de base LOG350 A2006 Analyse, vision et domaine

Conception des fonctionnalités (widgets, interactions)
On repart avec chaque tâche, en ordre d'importance On identifie des « boutons » (peut-être, en fait, des commandes de menu) pour les différentes opérations (traitement) à effectuer recherche, création, ajout, sauvegarde, efface, calcul, envoie, … Les actions plus importantes / fréquentes, et moins dangeureuses (!) -> des boutons plus faciles à accéder LOG350 A2006 Analyse, vision et domaine

D'écrans virtuels à Réels Passage au réel
On procède à l'assemblage fenêtres virtuelles en écrans réels On peut regrouper plusieurs fenêtres dans un seul écran, gardant des séparations visuelles (encadrement, couleurs, distance, …) Regrouper les fenêtres virtuelles d'une même tâche Regrouper les fenêtres virtuelles séquentielles Optimiser les transitions/navigations LOG350 A2006 Analyse, vision et domaine

Historique d’un compte Historique d’un(e) étudiant(e)
Revenons à l’exemple de SIGA et mes 6 tâches: - Voir vue d’ensemble des comptes - Voir historique d'un compte - Voir vue d'ensemble des étudiants - Voir historique d'un(e) étudiant(e) - Transférer entre deux comptes - Donner une bourse Et les données qu’on pourrait montrer: Liste de comptes Liste d’étudiant(e)s Historique d’un compte Historique d’un(e) étudiant(e)

Et notons les données nécessaires pour chaque tâche: - Voir vue d’ensemble des comptes - Voir historique d'un compte - Voir vue d'ensemble des étudiants - Voir historique d'un(e) étudiant(e) - Transférer entre deux comptes - Donner une bourse Liste de comptes Liste d’étudiant(e)s Historique d’un compte Historique d’un(e) étudiant(e)

Comment alors décider des fenêtres réelles ? Une solution, permettant de réduire le nombre de fenêtres, serait de fusionner les informations concernant les comptes en une fenêtre, et les informations concernant les étudiants en une autre fenêtre. Ceci réduit le nombre de modèles de fenêtres. De plus, pour naviguer vers un historique de compte (ou un historique d’étudiant), l’utilisateur peut se servir de la liste de comptes (ou d’étudiants) comme point d’entré. Liste de comptes Liste d’étudiant(e)s Historique d’un compte Historique d’un(e) étudiant(e)

Seul problème restant: comment permettre facilement d’effectuer la dernière tâche, de donner une bourse? (N’oubliez pas qu’une bourse peut impliquer plusieurs comptes.) Solutions possibles: Demander à l’utilisateur de passer à travers les deux fenêtres ci-dessous, en un mode spécial ? À partir d’un étudiant dans la deuxième fenêtre, cliquer sur un bouton ou un lien “Donner une bourse” qui nous amène vers une troisième fenêtre ? Liste de comptes Liste d’étudiant(e)s Historique d’un compte Historique d’un(e) étudiant(e)

Comparons à un site bancaire: - Une page donnant une vue d’ensemble des comptes, avec une section (en haut à droite) pour les transferts (remarquez aussi le menu déroulant contenant les soldes de chaque compte!) - Des liens amenant vers l’historique de chaque compte

Remarques L’exemple précédent est simpliste, car il y a seulement un intervenant, quelques tâches simples, et nous n’avons pas analysé la fréquence des tâche.

Observation Si on avait à reconcevoir SIGA, les comptes bancaires et les relevés bancaires seraient de bons métaphores à utiliser Malheureusement, actuellement, un relevé historique dans SIGA n’est pas possible, et même le mot “compte” n’a pas le sens attendu

Pour un autre exemple de conception avec des “fenêtres virtuelles”, voir l’article de Lauesen et Harning (2001) ( , ) qui prend l’exemple d’un logiciel de réservations hôtelier

Points à retenir Il n’y a pas de solution unique
Il y a parfois des compromis à faire (minimiser le nombre de modèles de fenêtres versus minimiser le nombre d’étapes dans chaque tâche) et dans certains cas la justification d’un choix de conception peut sembler ad hoc Le plus important est d’essayer de commencer par le “information design”: concevoir les fenêtres autour des l’informations qu’elles vont afficher, et seulement plus tard rajouter les boutons, menus, widgets, etc. Éviter l’approche “wizard” avec des fenêtres servant à seulement une tâche, à moins que ça soit pour une tâche compliquée et/ou rarement effectuée (exemple: guichet bancaire; configuration compliquée) où on veut maximiser la facilité. Cette approche ne s’applique pas à toutes les interfaces (exemples: jeux, joueurs de médias, logiciels de création de dessins, …)

Question Est-ce que l’approche “information design” / “fenêtres virtuelles” vous aurait aidé dans votre exercise de conception papier de tantôt ?

Prototypage.

Présentations similaires

Présentation au sujet: "Prototypage."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Prototypage.

Présentations similaires

Présentation au sujet: "Prototypage."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back