Projet de conception centrée utilisateur

Objectifs

Ce projet a pour but de vous donner de l’expérience avec le cycle complet de la réalisation d’un système interactif, de la conception centrée utilisateur jusqu’à l’implementation du système. Vous allez commencer avec la récolte des besoins, l’itération de plusieurs maquettes basse-fidélité, et réaliser un prototype fonctionnel.

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 maquettes 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 constituer un groupe de 4 personnes et raffiner le sujet du projet.

• Carte interactive dans un restaurant
  • Votre client est un restaurateur. Il veut un système numérique pour gérer les commandes dans son restaurant. Heureusement, il existe une grande école du numérique pour l’accompagner dans son projet ! Vous pouvez choisir entre remplacer les cartes papier par des cartes numériques (e.g. tablettes), une interface à destination des serveurs pour saisir les commandes, ou une borne de commande (genre McDo).
• 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, Netflix, etc. Vous pouvez choisir entre faire une télécommande sur smartphone/tablette ou faire une interaction à distance avec l’écran (genre télécommande).
• Créer un gestionnaire de liste TODO
  • Un système qui permet à l’utilisateur de saisir et gérer ses tafs.

Si un autre sujet vous tient à cœur, il est possible de le proposer sous réserve de validation au préalable par l’équipe pédagogique.

Attention : certains projets peuvent donner l’impression d’être plus simple à faire que d’autres. Dans tous les cas, nous cherchons un design réfléchi et approfondi, focalisé sur les objectifs de l’utilisateur du système. Le système final n’aura pas forcément besoin d’implementer toutes les fonctionnalités prise en charge par le design, mais devrait au moins montrer les composants nécessaires. Par exemple, pour une carte restaurant, vous n’avez pas besoin de communiquer avec une base de données pour mettre à jour les plats, tant que l’interface montre bien l’interaction. Ou une set-top box n’aurait pas besoin de réellement faire la liaison avec la télé, chaîne hi-fi, etc : cette interaction pourrait être simulé dans le prototype final.

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 s’intéresse seulement à comprendre le problème.

Livrable 1

Pour ce livrable, vous allez faire un document qui aborde les sujets dessous. Ce document peut être dans un style informel, genre blogue, mais il doit démontrer une réflexion approfondie des sujets dessous.

• Rappel du sujet
• La méthode choisie pour élucider les besoins utilisateur. N’oubliez pas d’inclure une réflexion sur pourquoi vous avez choisi cette ou ces méthodes, leurs limitations, etc.
• Ce que vous avez appris. Pensez aux conclusions qui pourraient avoir une importance pour le design ultérieur du système.
• Au moins trois persona que vous allez utiliser pour guider le design de votre système.
  • Pourquoi ces persona ?
• Au moins trois scénarios décrivant des tâches utilisateur différents
  • …ainsi que le raisonnement derrière ce choix des scénarios.
• Une liste de critères ou principes pertinents pour juger l’utilisabilité de votre système éventuel.

Soumettez ce document dans le Moodle.

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

2. Trois maquettes très basse-fidélité

Dans la partie précédente, vous avez identifié les contraintes utilisateurs, leurs besoins, leurs tâches, et le contexte d’usage du système. Vous avez identifié des critères d’utilisabilité et vous avez une meilleure compréhension des objectifs du système. Dans cette partie, créez plusieurs alternatifs du design du système.

En cours, nous avons fait un brainstorming préliminaire pour considérer des possibilités différentes pour le design du système. Continuez cette réflexion, cette fois en développant au mois trois designs distinctes sous forme d’esquisse sur papier. Notre objectif est de créer des dessins qui servent à explorer de différentes organisations, métaphores, ou interactions avec le système.

Chaque design doit contenir au moins un ensemble d’esquisses suffisant pour comprendre l’organisation du système, s’il ne réalise pas tous les éléments.

Livrable 2

Dans le Moodle, téléchargez un PDF de l’ensemble des esquisses. Pour chaque design, rajoutez un paragraphe qui décrit l’idée derrière le design.

Astuce : les imprimantes multi-fonction de l’école peuvent numériser vos dessins sous format PDF.

3. Maquette raffinée

Toujours sur papier, choisissez le design que vous allez implementer. Ce design suivra l’une des directions évoquées lors de l’étape précédente, mais intégrera sûrement des éléments différents des autres designs.

La maquette raffinée doit compléter les idées évoqués dans l’étape précédente afin de montrer tous les élément de l’interface que vous allez implementer. Il n’est pas nécessaire de faire une maquette haute-fidélité (e.g. avec les couleurs et aspects visuels des éléments), mais il doit montrer tous les éléments et leurs interactions prise en charge.

Cette maquette peut être interactif, comme on a vu en cours, ou bien démontrée par un prototype vidéo.

Rédigez aussi un peu de texte décrivant votre raisonnement dans le choix du design et dans les évolutions éventuelles par rapport aux idées précédentes. Là encore, nous cherchons une réflexion approfondie, qui va sûrement s’appuyer sur les contraintes utilisateur, tâche, technologiques, et du contexte identifié tout au début du projet.

Soumettez votre maquette raffinée dans le Moodle.

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

Livrable 4

Écrivez un README décrivant les fonctionnalités implementées, l’interface, et l’organisation du code. N’oubliez pas un lien vers votre dépôt Git. Soumettez votre README/LISEZMOI dans le Moodle.

(Si vous avez utilisé un dépôt privé, pensez à m’y donner accès. Si vous n’utilisez pas le GitLab de l’école, je suis eaganj sur GitHub, GitLab, et Bitbucket.)

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 n minutes (à déterminer) 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.