Projet

Objectifs

Le but de ce projet est de vous donner de l’expĂ©rience avec la conception centrĂ©e utilisateur: de la rĂ©colte de besoins, le prototypage, la rĂ©alisation, Ă  l’évaluation d’un système final.

DĂ©roulement

Les dates limites sont au dĂ©but de la sĂ©ance (sauf autrement indiquĂ©) en [crochets].

  • Formation de groupes. Élaboration du sujet
  • Analyse de tâches, rĂ©colte de besoins
  • Sketches, storyboards, prototypes sur papier ou vidĂ©os
  • Prototype informatique
  • ContrĂ´le (pas vraiment le projet, mais bon Ă  savoir)
  • Soutenances, rapport, prototype final

0. Formation de groupes et Ă©laboration du sujet

Dans un premier temps, il faut former des groupes de 4 Ă  5 personnes. Ensuite, il faut choisir le sujet du projet. Ci-dessous, quelques propositions.

  • Carte interactive dans un restaurant
    • Votre client est un restaurateur. Il veut remplacer les cartes imprimĂ©es sur papier qu’utilise actuellement son restaurant avec une solution Ă©lectronique, permettant aux clients du restaurant de passer leur commande Ă  table en utilisant votre solution.
  • Système de prise de notes en cours
    • CrĂ©er un système Ă©lectronique de prise de notes par des Ă©lèves en cours. Ă€ ne pas oublier : le contexte d’un cours, les besoins de tous les participants (e.g., le professeur).
  • Compagnon de voyage
    • Un système pour aider un voyageur lors de son voyage. ItinĂ©raires, sites historiques, restaurants, photos, etc.
  • Interaction avec une multimĂ©dia/set-top box
    • Un système pour contrĂ´ler son centre mĂ©diatique dans le salon. SĂ©lection de chaĂ®nes, de son, de vidĂ©os Ă  la demande, replay (e.g., pluzz), â€¦
  • Wassup
    • ÉvĂ©nements dans ma ville. Concerts, films, festivals, etc.

Si un autre sujet vous tient vraiment, il est possible de nĂ©gocier ce projet Ă  l’avance avec les encadrants (M. Eagan & M. Lecolinet). Dans ce cas, vous ĂŞtes fortement encouragĂ© Ă  le faire bien avant la date conseillĂ©e dessus.

Quoi que soit le projet choisi, il faut bien identifier et prĂ©ciser les types d’utilisateurs du système, les parties intĂ©ressĂ©es, le contexte de l’usage, et les besoins utilisateur. Attention : certains projets peuvent donner l’impression d’être plus Ă©vident que des autres. Dans tous les cas, il faut faire un effort de rĂ©ellement identifier les besoins d’un perspectif centrĂ©e utilisateur. RĂ©sister la tentation de faire une simple check-list de fonctionnalitĂ©s.

1. Analyse de tâches, rĂ©colte de besoins

Le but ici est de mieux comprendre le problème. Qui sont les utilisateurs potentiels du système. Qui sont les parties intĂ©ressĂ©es du système ? Souvent, il y en a plusieurs, chacun avec ses propres contraints et ses propres besoins, souvent en conflit les uns avec les autres. Quels sont les types d’utilisateurs ?

Vous avez vu en cours plusieurs mĂ©thodes de mieux comprendre le contexte auquel le système serait dĂ©ployĂ©. Quelles mĂ©thodes sont les plus adaptĂ©es Ă  votre situation ? Pourquoi avez-vous choisi la mĂ©thode employĂ©e ?

Qu’est-ce que vous avez dĂ©couvert ? Pour chaque type d’utilisateur, quels sont les tâches principales Ă  gĂ©rer ? Quel est le contexte d’usage ? Quelles sont les fonctionnalitĂ©s consĂ©quentes de ces tâches ?

Quels sont les contraints imposĂ©s par ce que vous avez identifié ?

Ă€ ce point lĂ , ne penser pas Ă  des solutions. Le design suivra. Ici on se concerne seulement de comprendre le problème.

Artefact

Pour la sĂ©ance indiquĂ© dessus, prĂ©parer une description des parties suivantes :

  • Une prĂ©sentation du contexte du problème : le sujet, pourquoi un système est nĂ©cessaire, etc.
  • Une partie sur les utilisateurs
    • Quels types d’utilisateurs avez-vous identifiĂ© ?
    • Pourquoi ces types d’utilisateurs ? En quoi diffèrent-ils ?
  • Une partie sur les tâches
    • Les tâches principales
    • Les caractĂ©ristiques du contexte associĂ© aux tâches
  • Une partie sur le contexte
  • Une liste de critères ou principes pertinents pour juger l’utilisabilitĂ© de votre système Ă©ventuel
  • Les implications et consĂ©quences de ce que vous avez appris dessus

Vous auriez besoin de ces infos lors du TD sur les prototypes.

2. Sketches, storyboards, prototypes sur papier ou vidĂ©os

Dans la partie prĂ©cĂ©dente, vous avez prĂ©cisĂ© les utilisateurs, leurs besoins, les besoins fonctionnels, et le contexte d’usage du système. Vous avez des critères d’utilisabilitĂ© et une meilleure comprĂ©hension des buts du système. Dans cette partie, crĂ©er plusieurs alternatifs du design du système.

Commencer avec du brainstorming, des sketches ou esquisses sur papier. Le but est d’explorer beaucoup d’options rapidement. Ne pas vous laisser contraint par la technologie, par ce qui est facilement rĂ©alisable, par ce que vous avez dĂ©jĂ  vu dans d’autres systèmes. MĂŞme si les contraintes que vous avez identifiĂ©s lors de la rĂ©colte de besoins vont guider votre design, ne pas les laisser influencer le brainstorming.

Ensuite, faire des sketches ou des esquisses sur papier pour fusionner et dĂ©velopper les idĂ©es identifiĂ©es lors du brainstorming. Ce dĂ©veloppement aidera Ă  mieux explorer l’idĂ©e, l’organisation, le mĂ©taphore, ou l’interaction proposĂ©e dessus.

Finalement, dĂ©velopper l’une de ces idĂ©es dans un forme plus complet, en faisant des prototypes sur papier, peut-ĂŞtre filmĂ©s, qui peuvent servir pour :

  • montrer les interactions nĂ©cessaire Ă  faire les tâches reprĂ©sentatives identifiĂ©es dans la partie prĂ©cĂ©dente
  • Ă©valuer la performance en utilisant au moins une des mĂ©thodes d’évaluation vues en cours et compatibles avec une Ă©valuation d’un prototype incomplet.

IdĂ©alement, le choix qui vous a amenĂ© Ă  la version Ă©laborĂ©e devrait appuyer sur ce que vous avez identifiĂ© dans la première partie du projet : l’utilisateur, les tâches, la technologie, le contexte, et les critères d’utilisabilitĂ© choisis.

3. Prototype informatique

Jusque prĂ©sent, vous avez travaillĂ© dans un monde un peu idĂ©aliste, oĂą vous ne vous concerniez pas de comment rĂ©aliser les interfaces proposĂ©es. Le but de cette partie du projet est de gagner de l’expĂ©rience mettre en Ĺ“uvre une interface complète.

CrĂ©er une implĂ©mentation des interfaces et des interactions principales pour rĂ©aliser votre projet. Si, par exemple, votre projet est de crĂ©er une carte interactive dans un restaurant, vous devrez crĂ©er une interface fonctionnelle permettant de faire les tâches principales identifiĂ©es dans la première partie du projet, e.g., choisir entre plusieurs plats, modifier les ingrĂ©dients, passer une commande, etc. Ce n’est pas nĂ©cessaire d’avoir toute la vrai fonctionnalitĂ© derrière (e.g., base de donnĂ©es), tant qu’il y ait assez pour montrer et Ă©valuer l’interaction et l’interface.

Vous utiliserez le prototype informatique dans la prochaine Ă©tape : l’évaluation. Il faut donc que la version soumise du prototype informatique soit dans un Ă©tat assez complet pour faire passer ces Ă©valuations.

Ă€ rendre

Écrire un README dĂ©crivant les fonctionnalitĂ©s implĂ©mentĂ©es, l’interface, et l’organisation du code. Mettre-le avec le code dans un dossier portant les noms de tous les membre du groupe. CrĂ©er un .zip, un .tar.gz, ou un .tgz (pas d’autre format !) de ce dossier, qui s’extrait en un seule dossier avec le mĂŞme nom. Par exemple, extraire le fichier eagan-lecolinet-roy-wagner.zip devrait crĂ©er un dossier eagan-lecolinet-roy-wagner qui contient le README et le code. Soumettre cet archive dans le site de rendu des projets. (Le site de rendu n’accepte que trois noms, tant qu’il y en a au moins un indiquĂ©, je trouverai les autres.)

4. Évaluation du prototype informatique

Vous n’êtes pas loin de la fin. Vous avez fait une rĂ©colte de besoins, une analyse de tâches et avez crĂ©Ă© des maquettes sur papier/vidĂ©o/powerpoint. Vous avez crĂ©Ă© un prototype informatique qui rĂ©alise les fonctionnalitĂ©s principales que vous avez identifiĂ© dans la première partie du projet. Peut-ĂŞtre ce dernier est trop fort, comment savoir si le prototype informatique correspond vraiment aux besoins identifiĂ©s ?

Vous avez vu plusieurs mĂ©thodes pour concevoir et construire une Ă©valuation d’un prototype existant. Quels sont les critères de cette Ă©valuation ? En fonction de ces critères, du contexte prĂ©vu de l’utilisation du système et de l’état actuel du prototype, quelles mĂ©thodes s’appliquent ? Quelle(s) mĂ©thode(s) utiliserez-vous pour Ă©valuer le prototype ?

Faire passer une telle Ă©valuation de votre prototype.

5. Rapport et prototype final

Écrire un rapport avec :

  • Une description du projet dans un paragraphe. Quel est le projet choisi, le contexte, etc.
  • L’utilisateur
    • Quelle technique(s) avez-vous choisies pour identifier les besoins utilisateur ? Pourquoi avez-vous choisi cette technique ?
    • Quels sont les besoins du système ? Cette partie devrait prĂ©senter les besoins utilisateur principaux, du point de vue de l’utilisateur, et les fonctionnalitĂ©s systèmes associĂ©es. Quelles sont les critères de rĂ©ussite d’une tâche, les critères d’utilisabilitĂ© identifiĂ©es ?
  • Le design
    • Une brève rĂ©capitulatif des trois designs explorĂ©s dans la partie 2.
    • Le design final. Pourquoi avez-vous choisi ce design ? Ici, ça sera sĂ»rement utile de relier le design aux besoins utilisateur, aux contexte d’usage, et aux contraintes techniques identifiĂ©s dans la première partie. Quels objectifs rĂ©ussit-il bien ? Lesquels ne rĂ©ussit-il pas trop bien ?
    • Est-ce ces besoins ont Ă©voluĂ© lors de l’élaboration du design ? Pourquoi et comment ?
    • Comment marche ce design ? Pour chaque composant principale, utiliser des captures d’écran ou des photos pour montrer le design.
  • Le prototype
    • Quel est l’état du prototype ? Quelles fonctionnalitĂ©s ont Ă©tĂ© complĂ©tĂ©es ?
    • Comment l’avez-vous implementé ?
    • Un lien vers le dĂ©pĂ´t git du projet.
  • L’évaluation
    • Quelle mĂ©thode(s) avez-vous choisi pour Ă©valuer le système ?
    • Pourquoi cette mĂ©thode ?
    • Quelles sont les tâches reprĂ©sentatives que vous avez utilisĂ©es lors de l’évaluation ?

Ce rapport devrait faire entre 10 et 20 pages, dans une police sĂ©rif standard 12 point, inter-lignes simples, et des marges raisonnables. Soumettre ce rapport en format PDF dans le dĂ©pĂ´t de rapport. Tout rapport non-conforme sera considĂ©rĂ© inadmissible et recevra automatiquement une note de 0.

6. Soutenances

Chaque groupe aura 12 minutes pour prĂ©senter leur projet, dĂ©mo comprise, et 3 minutes pour les questions. L’ordre de prĂ©sentation sera dĂ©terminĂ© alĂ©atoirement le jour des soutenances. Le prĂ©sentation doit rĂ©sumer brièvement le contexte du projet : quel est le sujet, qui sont les porteurs du projet (e.g. les utilisateurs), quels sont les contextes d’usage, les tâches principales Ă  supporter, et les critères d’utilisabilitĂ©. Elle doit montrer le design retenu, et brièvement expliquer pourquoi vous avez choisi ce design. La plupart de la soutenance sera consacrĂ© Ă  une dĂ©mo du prototype, suivi probablement par une description des points forts et points faibles de ce design.