Projet de conception centrée utilisateur

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, du prototypage, la réalisation, à l’évaluation d’un système final.

Déroulement

Il y a 6 étapes majeures du projet :

  • La formation des groupes et l’élaboration du sujet.
  • L’identification des contraintes utilisateur, de tâche, et du contexte d’usage.
  • L’élaboration des prototypes basse-fidélité.
  • La réalisation du prototype technique.
  • La soutenance du projet.
  • Le rapport final.

Les dates limites sont indiquées dans le syllabus, chaque livrable est à soumettre via le Moodle.

0. Formation des groupes et élaboration du sujet

Dans un premier temps, il faut former des groupes de 4 personnes et raffiner le sujet du projet.

  • Carte interactive dans un restaurant
    • Votre client est un restaurateur. Il veut remplacer les cartes imprimées sur papier utilisés actuellement dans son restaurant par une solution numérique. Heureusement, il existe une grande école du numérique pour l’accompagner dans son projet !
  • 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).
  • 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 le proposer sous réserve de validation au préalable par l’équipe pédagogique.

Ensuite, il faut bien identifier et préciser les utilisateurs différents du système, le contexte de l’usage, et les besoins utilisateur. Attention : certains projets peuvent donner l’impression d’être plus simple à faire que d’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 des besoins utilisateur

Le but ici est de mieux comprendre les besoins de l’utilisateur du système. Qui sont les utilisateurs potentiels du système. Qu’est-ce qu’ils essayent de faire, pourquoi, et dans quels contextes ? Souvent, il y a plusieurs types d’utilisateur, chacun avec ses propres contraints et ses propres besoins, souvent en conflit les uns avec les autres.

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.

Livrable 1

Pour ce livrable, vous allez soumettre :

  • Un document comprenant :
    • Un paragraphe de texte décrivant la méthode que vous avez utilisé pour élucider les besoins utilisateur,
    • Un paragraphe ou deux décrivant ce que vous avez appris,
    • Au moins trois persona que vous allez utiliser pour guider le design de votre système,
    • Au moins trois scénarios décrivant des tâches utilisateur différents,
    • Une liste de critères ou principes pertinents pour juger l’utilisabilité de votre système éventuel.

Pour la séance indiqué dans le Moodle, préparer une description des parties suivantes :

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

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 ?

Décrivez comment vous feriez une telle évaluation de votre prototype.

5. Rapport et prototype final

Écrire un rapport sur votre projet. Voici des éléments à inclure à minimum, mais vous serez évalué sur non seulement ces éléments mais aussi votre réflexion approfondie.

  • Un rappel de la description du projet (probablement environ 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 ?
    • Indice : des persona et des scénarios peuvent être utiles pour communiquer ces éléments.
  • 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 utiliseriez lors de l’évaluation ?

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

6. Soutenances

Chaque groupe aura 13 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.