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.