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

  • Formation de groupes. Élaboration du sujet [4/3/13]
  • Analyse de tâches, rĂ©colte de besoins [19/3/13]
  • Sketches, storyboards, prototypes sur papier ou vidĂ©os [2/4/13]
  • Prototype informatique [19/4/13] [22/4/13]
  • Évaluation du prototype informatique [26/4/13] [3/5/13]
  • ContrĂ´le (pas vraiment le projet, mais bon Ă  savoir) [30/4/13]
  • Soutenances, prototype final [3/5/13]

0. É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 Ă  la 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 multimedia/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 raisonnable pour 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.

Ă€ rendre

Un rapport qui rĂ©ponde aux questions dessus. Le rapport devrait suivre la structure suivante :

  • Une prĂ©sentation du contexte : le sujet, pourquoi un système est nĂ©cessaire, etc.
  • Une partie sur les utilisateurs
  • Une partie sur les tâches
    • Les tâches principales
    • Les caractĂ©ristiques du contexte associĂ© aux tâches
    • Une dĂ©composition hiĂ©rarchique du problème (potentiellement simplifiĂ©e)
  • 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 avez de 5 Ă  10 pages, dans une police serif standard Ă  10 pt., interligne simple, avec des marges raisonnables. Envoyer un document en format PDF Ă  james.eagantelecom-paristechfr dans un mĂ©l avec l’objet « INFSI 351 : Analyse de tâches ». Tout document soumis non-respectant ces consignes sera considĂ©rĂ© inadmissible et recevra automatiquement une note de 0.

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 contraints 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.

Ă€ rendre

  • Les sketches montrant trois idĂ©es diffĂ©rentes Ă©laborĂ©es après le brainstorming.
  • Le prototype (probablement sur papier, mais peut-ĂŞtre en vidĂ©o ou, si nĂ©cessaire, powerpoint) que vous avez dĂ©veloppĂ©.
  • Des sketches ou storyboards montrant l’usage du prototype dĂ©veloppĂ©.
  • Un document (une Ă  deux pages, maximum), dĂ©crivant :
    • Les trois idĂ©es explorĂ©es dans les sketches,
    • Pourquoi vous avez choisi la version dĂ©veloppĂ©e, et
    • Une description du prototype dĂ©veloppĂ©e.

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, 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 absolument 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.

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.

Ă€ rendre

Écrire un rapport avec :

  • un rĂ©capitulatif des critères d’utilisabilitĂ©, des points importants du contexte ou des contextes d’usage,
  • l’état du prototype,
  • la ou les mĂ©thode(s) choisie(s) pour l’évaluation,
  • une description des procĂ©dures suivies lors de l’évaluation,
  • les rĂ©sultats donnĂ©s,
  • les conclusions pour des amĂ©liorations au système.

Ce rapport devrait faire entre 5 et 8 pages, dans une police serif standard 12 point, inter-lignes simples, et des marges raisonnables.

5. Soutenances, prototype final

[Ă€ suivre…]