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. [10/2/15]
• Analyse de tâches, récolte de besoins [10/2/15]
• Sketches, storyboards, prototypes sur papier ou vidéos [10/3/15]
• Prototype informatique [5/5/15]
• Contrôle, rapport, soutenances, prototype final [5/5/15]

0. Formation de groupes

Dans un premier temps, il faut former des groupes de 5 à 6 personnes. Chaque groupe à le même sujet :

• Carte interactive dans un restaurant
  • Votre client est un restaurateur. Il veut un système « hi-tech » pour remplacer les cartes imprimées sur papier qu’utilise actuellement son restaurant.

Même si le sujet est fixe, son interprétation laisse beaucoup de liberté, 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 : même si le sujet semble être simple, il peut y avoir de nuance et de facteurs complexes. Il faut faire un effort de réellement identifier les besoins du point de vue de l’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 pour 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.

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. L’idée est d’explorer beaucoup de pistes différentes. À ce point là, ne pas penser à la faisabilité des idées, à leur implémentation, etc. Après, faire le tri des idées et en choisir trois à élaborer. Ces trois idées plus élaborées peuvent fusionner des éléments de plusieurs idées proposées lors du brainstorming.

Ne pas oublier la technique de prototypage sur papier, qui peut bien aider à explorer un design sans écrire une seule ligne de code.

3. Prototype informatique

Parmi les trois designs élaborés, en choisir un à implémenter. Bien entendu, le contexte du système et interface proposé dessus ne correspondra probablement pas aux machines mises à disposition dans les salles de TP. La réalisation du prototype informatique peut être une adaptation de l’idée comme si implémentée pour une configuration bureautique, avec clavier et souris. Le but de cette partie du projet est de vous donner de l’expérience avec le développement d’une interface graphique et interactive, de mettre en œuvre ce que vous avez vu dans les séances de développement des IHMs.

Cette partie est à faire dans Qt ou, si vous préférez Java. Si tous les membres d’un groupe ont de l’expérience avec Androïd ou Objective-C, des projets réalisé pour Androïd ou iOS seront possibles aussi. L’utilisation de tout autre langage dont tous les membres de l’équipe partage des compétences devrait impérativement être validé par l’équipe enseignant. NB : Nous ne validerons pas de projets réalisés en JavaScript ou Flash.

4. Rapport, soutenances, prototype final

Le rapport

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 (§1 dessus)
  • Une description des utilisateurs
    • Les parties prenantes
    • Les caractéristiques des sous groupes éventuels des 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
• Une partie sur les designs
  • Un échantillon des sketches brainstormés
  • Les trois sketches élaborés
  • Des storyboards, maquettes sur papier des trois designs finaux
• Un plan d’évaluation
  • Quelle(s) méthode(s) à employer (et pourquoi ces méthodes choisies)
  • Comment appliquer la ou les méthodes choisies
  • Quelles critères d’utilisabilité ?

Vous avez de 10 à 20 pages, dans une police serif standard entre 10 et 12 pt., interligne simple, avec des marges raisonnables. Envoyer le rapport en format PDF à james.eagantelecom-paristechfr dans un mél avec l’objet « ANDROIDE/IHM : Rapport ». Tout document soumis non-respectant ces consignes sera considéré inadmissible et recevra automatiquement une note de 0.