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]
  1. É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.

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

  1. É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.

  1. Soutenances, prototype final ===============================

[À suivre…]