Tout un WebÉduc sur les tests d’utilisabilité!

Voilà, la journée est finie! mais quelle journée! Et merde, je viens seulement de réaliser que je n’ai même pas pris de photos! argh!

La rencontre s’est faite dans un complexe G aux allures de Brazil… Voilà, j’étais fait! j’ai eu la musique du film (si bien connue) toute la journée dans la tête dès que je voyais des tuyaux de ventilation pendre du plafond!

Donc, une belle brochette d’invités: Daniel Lafrenière et Anastasia Simitsis de W.illi.am ont ouvert le bal avec une présentation des tests en 10 17 questions. Ce fut hyper instructif et les deux animateurs avaient une très bonne complicité. Comble de joie, ils se sont même proposés pour un complément durant l’hiver… plus à suivre.

Ainsi, quelques questions de base, qu’on se pose sur les tests: la pertinence, combien d’utilisateurs, le type de tests… On a même eu droit à un joli débat sur les prototypes papier vs les prototypes à l’écran. Daniel était tenant des premiers et Anastasia des seconds. Disons que le débat était constructif et que chaque méthode a ses plus et ses moins.

En après-midi, votre humble serviteur accompagné de Simon Bédard (Babluit, pour les intimes) ont présenté quatre petits vidéos (à venir sur ce blogue et YouTube) démontrant la réalisation d’un test d’utilisateur, de la scénarisation principale jusqu’à la réalisation du test. Quelques commentaires en superposition (pas toujours pertinents de ma part — je m’en excuse), des points de précision et une référence sur l’excellent livre de Carolyn Snyder, Paper prototyping, puis on passait déjà la présentation de Sol Tanguay.

Je ne connaissais pas Sol, et je dois dire que c’est ma découverte de la journée! Il a présenté un sujet assez aride, soit une étude en trois phases en cours au MSG en collaboration avec HEC Montréal, plus précisément, la Chaire RBC en Commerce Électronique.

En effet, diverses évaluation en accessibilité ont été réalisées sur des sites gouvernementaux, dans plusieurs contextes et à certains niveaux (précis, hein? — Sol était plus clair que moi!). Bref, des sites de M/O ont été testés et ont obtenu une «note».

Ces test servent à sortir divers constats et pourront être colligés dans une livraison ultérieure d’un guide de «bonnes pratiques» Web. J’ai bien hâte de le voir, celui-là!

Il y a eu une certaine surprise dans l’assistance, car des personnes représentant certains des organismes dont les sites ont été testés étaient présentes et ignoraient en tout ou en partie que de tels tests étaient effectués. Nous espérons tous bien pouvoir mettre la main sur les données, car elles peuvent grandement nous aider à améliorer l’utilisabilité des sites des organismes testés — et des autres!

Pour terminer la journée, une autre vedette: Michaël Carpentier, qui avait un rhume carabiné, nous a présenté le lien entre les tests d’utilisabilité et l’analytique Web. Fort à propos, c’est un complément d’information qui peut guider dans la création des scénarios de test.

Malgré son handicap et sa surdose d’acétaminophène, Michaël a livré une très bonne conférence et a su faire un lien étroit entre les deux approches. Bon, je devrai donc me taper un peu de doc sur Google Analytics pour configurer certains types de collecte de données, moi! eheh!

En conclusion, je crois que la journée a été fort appréciée par la «centvingtaine» de participants présents. Je suis d’autant plus heureux que plusieurs participants ne se connaissaient pas avant de se lancer dans l’aventure. De mon côté, l’objectif est atteint: sensibiliser les membres du gouvernement au bien fondé de faire des tests et démontrer que ce n’est pas compliqué.

En espérant que l’enseignement appris sera assimilé par tous!

Web éducation du 24 septembre sur les tests d’utilisabilité

J’en ai déjà parlé, mais c’est moi qui me suis mis la cravate dans le tordeur pour organiser le WebÉducation de septembre qui traitera des tests d’utilisabilité. Eh bien, ça avance rondement. Vous pouvez aller consulter le programme de la journée diffusé sur Google Docs et, pour les gens qui travaillent au gouvernement du Québec, l’invitation a été envoyée via la liste des Webmestres.

La journée s’annonce très intéressante. Nous avons des conférenciers vedettes, comme Daniel Lafrenière et Michaël Carpentier. Ce sont des habitués des Web Éducation, mais on ne se lasse pas de les voir. Nous aurons aussi droit à une présence de Anastasia Simitsis, de W.illi.am, une firme de Montréal qui n’est (à première vue) pas très connue dans la Capitale Nationale. Anastasia avait fait une présentation fort intéressante au dernier Webcom Montréal.

Je ferai moi même une petite présentation avec Simon Bédard où nous allons expliquer la création d’un prototype papier (basse fidélité) et le déroulement d’un test avec chacun des intervenants.

Nous avons fait un tournage vidéo de la conception du prototype et du test dans nos locaux il y a quelques semaines puis avons monté quatre petites capsules de 2 à 5 minutes. Pour les besoins promotionnels de l’événement, et pour le bénéfice de l’ensemble des personnes intéressées, je diffuse dans mon blogue l’une de ces capsules vidéo.

Veuillez noter que tout est fictif. Il n’y a pas de Ministère de la Gestion des permis, les adresses sont fictives. La lettre est fictive. Bref, n’accrochez pas sur ces détails, mais plus sur la conception du prototype lui-même.

Alors, chers collègues du gouvernement, je vous invite à vous inscrire au prochain Web éducation. Vous y verrez nos conférenciers ainsi que les trois autres vidéos agrémentés de commentaires. Au plaisir de vous y rencontrer!

Expérience utilisateur pour les nuls

Quel superbe article! L’expérience utilisateur pour les nuls, 101, démystifié… nommez ça comme vous voulez, mais c’est enfin un condensé de l’ensemble des théories, vues, visions et autres idées des grands penseurs de l’expérience utilisateur: Garrett, Nielsen, Morville

J’apprécie l’ensemble de l’oeuvre, mais tout particulièrement la portion où il est question de gestion de projet et de biens livrables. Effectivement, trop souvent, on se fait dire que d’implanter une approche centré utilisateur est difficile:

  • Quand doit-on faire des prototypes?
  • Quand doit-on faire des testes d’utilisabilité?
  • Quelles sont les étapes de réalisation?

L’auteur présente un schéma qui résume l’ensemble des tâches, biens livrables et les moments où on devrait faire des preuves de concept (prototypes). Juste ce petit diagramme vaut l’article au complet, pour mes besoins, du moins!

Je travaille dans un monde d’informaticiens qui sont habitués à travailler avec une méthode traditionnelle (voire rétrograde), ce qui, selon l’auteur de l’article, n’est pas adapté à une approche d’expérience utilisateur.

Effectivement, si on réfère à son avant-dernier diagramme, on voit bien vite que les méthodes dites agiles sont nettement plus adaptées!

N’allez pas croire que je renie le début de l’article, au contraire! il démystifie et explique ce qu’est le champ de travail de l’expérience utilisateur, les composantes, les théories…

Bref, pour ceux qui veulent faire comprendre que l’utilisateur est au centre du développement et que l’on devrait peut-être s’en soucier plus, histoire d’éviter des développements pathétiques d’applications telles que des SAGIR…

Séance de prototypage papier

Je travaille présentement sur un projet de développement d’un système de mission pour un organisme. Un assez gros système, avec pas mal d’intervenants et, surtout, un impact majeur sur les façons de faire actuelles.

Présentement, tout est géré «à la mitaine», «full» années ’80, avec des listes (imprimées) sorties d’un système développé dans les années ’70-’80 (via une interface en terminal genre «ambre sur noir»). Bref, plusieurs personnes qui ont à gérer plusieurs feuilles de papier et une autre qui collige le tout dans des fichiers Excel®.

La principale tâche consiste à sélectionner des éléments à mettre dans un calendrier. Simple en apparence, ces éléments, des audiences, peuvent jouer dans le temps, la durée, la salle… bref, tout un casse tête.

Nous avons trouvé une piste de solution, une méthode pour permettre une utilisabilité intéressante, tout en limitant la charge de dévelppement (le projet doit être livré assez rapidement). Bref, on avait une bonne piste, mais il fallait lui faire passer un test de réalité (reality check).

C’est alors que j’ai proposé une petite séance de prototypage papier. Nous nous sommes installés, une collègue, un anaylste et moi, dans une petite salle, avons pondu un scénario simple (fidèle à la grille que j’ai déjà présenté dans ce blog) et avons pondu notre «interface» en moins d’une heure.

Une fois le tout terminé, «l’ordinateur» a été démarré (l’analyste) et on pu procéder au test de réalité. Le pilote, l’architecte fonctionnel et, en ce moment même (en mon absence), un utilisateur du système, ont tous été confrontés au module que nous comptions intégrer dans le système.

En deux heures, conception du prototype inclus, nous avons été en mesure de réaliser des tests et s’assurer que notre idée était effectivement une bonne approche.

Le module a tellement été jugé utile qu’il sera élargi et sera intégré dans d’autre contextes du système, histoire de conserver un fonctionnement cohérent d’un bout à l’autre.

C’était un plaidoyer en faveur des prototypes basse fidélité!

Note: si je le puis, je publierai une photographie du prototype basse (très basse) fidélité éventuellement…