Méthodologie de conception Analyse des besoins

1. Méthodologie de conceptionAnalyse des besoins Interfaces et Scénarisation (COM2571) 01 octobre 2013 Grégory Petit http://lrcm.com.umontreal.ca/greg/COM2571/

2. Il y a deux semaines … • Définition d’une problématique pour faire une évaluation • Méthodes d’évaluation • Tests utilisateur

3. Scénarisation interactive Analyse des besoins Objectifs de communication Cas d’utilisation, scénarios Maquette Description du contenu et exemples Design de la structure d’interaction Design des principaux écrans et des boutons Validation par le client Validation par les usagers Programmation

4. Et donc on fait quoi aujourd’hui? • Conception centrée utilisateur • Approche persona • Analyse des besoins • Un peu de design • Atelier

5. Conception centrée utilisateur

6. Conception centrée utilisateur Encore des préjugés chez les concepteurs … • « Bien sur que je sais quel genre d’utilisateur va utiliser mon produit! » • « J’ai été étudiant, donc je sais comment concevoir un produit pour des étudiants. » • « Si j’ai une bonne idée, les utilisateurs l’aimeront certainement! » • « De toute façon, les utilisateurs ne savent comment dire ce qu’ils veulent! »

7. Conception centrée utilisateur

8. Connaitre l’utilisateur!!! Koko et Penny Patterson : création d’un langage des signes adapté aux gorilles! http://www.koko.org/index.php Ordinateur pour Koko, le Koko’s Mac II qui lui permet d’activer des phrases vocales en touchant des icones sur un écran tactile : http://www.beanblossom.in.us/larryy/KokoChapter.html

9. Connaitre l’utilisateur!!! • Définir les caractéristiques de l’utilisateur : • Connaître la physiologie et la psychologie basique humaine • Groupe spécifique? (non-voyants, enfants, personnes âgées…) • Ses connaissances, compétences et expériences avec la technologie • Son éducation, sa profession • Ses habitudes de travail • Etc.

10. Conception centrée utilisateur • Produit d’un processus de consultation et de participation active des utilisateurs • Préoccupation en amont des utilisateurs, de leurs tâches et de leur environnement • Répartition appropriée des fonctions entre les utilisateurs et les concepteurs

11. Conception centrée utilisateur • Cycle de conception : itération de solutions  démarche qui boucle et reboucle jusqu'à ce que le système satisfasse aux exigences définies au départ • Intervention d'une équipe de conception multidisciplinaire • Spécification et poursuite d’objectifs précis d’utilisabilité

12. Cycle de conception centrée utilisateur Source: ISO 13407 Human-centered design processes for interactive systems

13. Approche persona

14. Approche persona • Persona  définir les profils d’utilisateurs • Ne pas définir un usager typique  décrire différents types d’usagers • Un persona permet de décrire un utilisateur spécifique, mais imaginaire, qui fait parti d’un groupe d’usager cible (nom, âge, profession, expériences et compétences avec l’outil informatique, etc.)

15. Approche persona Il faut généralement définir : • Informations générales (âge, sexe, situation familiale) • Éducation et expérience professionnelle • Rôle et/où responsabilité avec le futur produit • Compétences technologiques • Compétences dans le domaine concerné par le produit • Motivations et envies • Buts et attentes • Contraintes qui pourraient limiter l’utilisation du produit • Qualité unique http://www.ld-grid.org/resources/representations-and-languages/personas

16. Exemple – bibliothèque de l’UdeM • Michel est un étudiant de 21 ans, en seconde année de baccalauréat en communication à l’Université de Montréal. Il sait très bien rédiger ses idées sur papier depuis le secondaire. • Il vit en collocation avec 2 amis. Il a un ordinateur portable, une imprimante et une connexion internet chez lui. • Il utilise généralement son ordinateur pour écouter de la musique, écrire des articles pour le journal de l’université, envoyer des courriels et aller sur des réseaux sociaux. • Il tient régulièrement un jour un blog où il parle de sa passion pour la photographie. Il effectue d’ailleurs de petites contrats de photographie.

17. Exemple – bibliothèque de l’UdeM • Il utilise souvent le site Web de la bibliothèque de l’UdeM mais n’a aucune idée comment ce système a pu être conçu. • Il consulte le site Web de la bibliothèque pour emprunter les ouvrages pertinents pour ses cours mais aussi pour de la lecture personnelle. • Pour mieux se concentrer, il lui arrive de travailler à la bibliothèque.

18. Analyse des besoins

19. Analyse des besoins • Inventaire des attentes par rapport au système (fournisseurs et utilisateurs du système) • Analyser les expériences antérieures • Analyser ce qui existe, ce qui va bien et ce qui doit changer • Commencer à répertorier les objets, les actions, les attributs, le vocabulaire à utiliser • Caractéristiques des usagers potentiels, leurs compétences et attitudes • C’est dans cette étape que la conception centrée utilisateur et l’approche persona peuvent être utiles!

20. Analyse des besoins • Inventaire général des sources d'information, exemple de contenus, caractéristiques médiatiques du contenu, contraintes à l'accès • Ressources disponibles pour aider à l'élaboration, la mise en forme, la mise à jour • Description des contraintes techniques à considérer pour l'élaboration et la diffusion

21. Analyse des besoins – méthodologie • Étude ethnographique • Observation des activités, des tâches, de l’utilisation des systèmes existants • Identification des processus de communication, des goulots d’étranglement, observation et recueil en situation des besoins • Entrevues auprès des principaux acteurs concernés par l’élaboration du système • Entrevues auprès des usagers et clients

22. Analyse des besoins – méthodologie • Recherche expériences similaires, systèmes existants, sources de contenus • Description fonctionnelle de l’application à développer • Intentions, cas d’utilisation, fonctions principales, scénarios • Esquisse générale de structuration des objets, du contenu • Estimation préliminaire des coûts et de l’échéancier

23. Analyse des besoins – produits • Texte décrivant les besoins et contraintes • Texte décrivant le contexte prévu d’utilisation • Texte décrivant la compétition et expérience antérieure  étude de l’existant • Texte spécifiant les objectifs et la stratégie privilégiée • Liste des acteurs, leur contexte d’utilisation et des exemples de fonctions • Liste de cas d’utilisation proposés et mis en ordre de priorité  diagramme de cas d’utilisation

24. Diagramme de cas d’utilisation Prépare les examens Dorment en cours Prépare le cours Donne le cours Suivent le cours Professeur Étudiant

25. Définition des objectifs de communication • Comment va-t-on répondre aux besoins définis? • Choisir parmi les besoins, les fonctions possibles et préciser la stratégie • Trop ≠ mieux • La meilleure approche ≠ la plus directe • Les fonctions et objectifs primaires et secondaires • Spécifier le message à passer et les fonctions visées • Définir les étapes de livraison

26. Définition des objectifs de communication • Choisir une métaphore si besoin et la justifier • Choisir les outils techniques à utiliser (environnement matériel et logiciel) • Choisir les techniques de médiatisation (composantes des médias) • Définir la stratégie générale de l'interface • Définir les critères de performance et d’utilisabilité visés.

27. Problèmes pouvant survenir • Ces objectifs peuvent évoluer en cours de projet • Évolution technologique • Analyse des besoins affinée après présentation des premiers objectifs aux utilisateurs finaux • Étapes de livraisons trop serrées • Mauvaise communication entre les différentes équipes du projets et avec les utilisateurs finaux

28. Un peu de design

29. Le design selon Weinscheink • Pour ce cours, on va suivre les indications de notre ami Weinscheink (Chap. 3 du livre présent dans les références) • Weinscheink s’intéresse aux GUI (GraphicalUser Interface) • On est toujours dans le processus de la scénarisation interactive!

30. Le design selon Weinscheink • S’assurer que les tâches se feront comme les usagers veulent les faire (théorie de l’activité) • Faire l’analyse des besoins et définir les objectifs de communication • Construire des scénarios d’utilisation • Décrire les objets, leurs attributs, les actions sur ces objets

31. Le design selon Weinscheink • Ne pas faire l’interface, mais la structure d’abord (voir le cours prochain sur les structures) • Faire une maquette assez détaillée pour permettre un parcours, une validation par des scénarios correspondant aux cas types • Ca reprend bien le schéma vu au début du cours que revoila!

32. Scénarisation interactive Analyse des besoins Objectifs de communication Cas d’utilisation, scénarios Maquette Description du contenu et exemples Design de la structure d’interaction Design des principaux écrans et des boutons Validation par le client Validation par les usagers Programmation

33. Création de maquette • Modèle général du contenu et exemples  les objets, leurs propriétés , leurs fonctions et les actions pouvant être faites sur ces objets • Structures statiques et dynamiques • Maquette basse définition des pages principales (boutons, menus, texte, illustrations, etc.) sans oublier la description des effets des pages et des interactions entre elles

34. Le contenu • Définir les contenus d’information • Définir les variables dont on aura besoin pour classer l'information et pour construire les pages d’accès au contenu • Définir comment les informations vont interagir, si elle doivent interagir

35. Le contenu – exemple Collectif de salles de spectacle • Catégories: • Spectacle : titre, artiste, date, heure, prix du billet • Salle de spectacle : nom, lieu, capacité de spectateur, superficie de la scène, type de forfait de location • Exemple! • Spectacle : The Flower Tour, Émilie Simon, 23 aout 2008, 20h, 35$ (régulier) • Salle de spectacle : Spectrum, Ste Catherine, 3000 spectateurs, 350 pieds carrés, [forfait 1 jour (2000$), forfait moins d’une semaine (1500$ par jour), forfait moins d’un mois (1200$ par jour)]

36. Méthode des cartes • Permet d’organiser le contenu • On choisit des individus parmi le public cible • Ces individus doivent classer par famille des cartes préétablies • Ils créent ensuite les structures d’accès, les choix de menu, les groupements d’items http://www.ergoweb.ca/cartes.html

37. Description des actions • Définir les principales actions que l’on veut faire sur les objets • Les actions de bases souvent utilisées : • Menus, barre d’outils • Trier • Rechercher et filtrer de l’information • Imprimer, enregistrer • Commenter • Décider des actions en fonction de la fréquence, des standards, du degré d’interaction désiré, de l’utilisation des clés de claviers, etc.

38. Exemple de structure

39. Atelier

40. Le respect de l’environnement • Le gouvernement du Québec veut ajouter sur son site Web une partie donnant des petits trucs pour mieux respecter l’environnement dans la vie quotidienne. • Vous êtes mandaté pour : • Créer un persona • Faire l’analyse des besoins (public cible, besoin de communication existant, métaphores et style à employer, intégration dans l’organisation, etc.) • Définir les objectifs de communication • Définir les différents contenus d’information