L’image suivante présente une brève synthèse du déroulement de la soirée:

J’en profite pour remercier tout le monde de leur généreuse participation! Mon seul regret est de ne pas avoir pu parler directement avec chacun!

Je crois qu’on peut affirmer que nous avons tous hâte à la prochaine édition!

Dans la tradition des barcamps, la non-conférence sera alimentée en sujets par les participants eux-mêmes. Chacun pourra proposer des thèmes à l’avance ou sur place afin de susciter la discussion avec ses pairs. Un animateur s’assurera de l’enchainement des présentations ainsi que de maintenir une certaine cohérence dans nos discussions.

Le tout aura lieu le 24 mars, de 17h à 21h, au Pub Galway, à Québec.

Pour plus de détails, rendez-vous sur la page de l’événement.

Alors, que vous soyez un professionnel ou un apprentis de l’expérience utilisateur, vous êtes bienvenue!

Cette conférence avait lieu dans le cadre du colloque annuel du RQuODE (Réseau québécois des organismes en développement de l’employabilité).

Voici le document de présentation:

Voilà donc enfin le document de présentation de la conférence que Hugo et moi avons donnée au sujet du processus de conception centré sur les utilisateurs (CCU).

Il est toujours étonnant de constater à quel point ce vaste domaine est peu connu! On a du pain sur la planche!

La conception d’un site Web performant, comme celle de n’importe quel produit ou service par ailleurs, nécessite de l’expertise et une certaine dose de talent. Ceci dit, on néglige trop souvent le fait que les utilisateurs eux-mêmes peuvent également nous être d’une très grande utilité lors du processus de conception. Il existe, en effet, une foule d’outils et de techniques nous permettant d’obtenir de l’information pratique de la part de ceux pour qui, finalement, nous effectuons tous ces efforts. Ils seront les premiers à bénéficier de nos réalisations et, par le fait même, ils seront les juges les plus sévères. Alors, pourquoi se passer de leur apport?

Pour vous inscrire, rendez-vous sur le site de la VETIQ.

J’en profite également pour vous montrer ma présentation:

Le Web a toujours été différent des médias traditionnels, en particulier de par son rapport au temps et à l’espace. Accessible 24 heures sur 24, le Web permet aux internautes de consulter l’information quand bon leur semble, ce qui fait s’écrouler peu à peu le sens de notions telles que les heures de tombée et les réseaux de distribution. Le contenu, produit de plus en plus rapidement par de plus en plus de gens et en plus grande quantité, est également consommé de plus en plus vite. Qu’advient-il quand cette information est accessible de manière instantanée et de n’importe où? Sujet passionnant, n’est-ce pas?

C’est ainsi que je me suis vu confier l’honneur d’organiser la journée WebÉducation du 19 novembre. Et c’est avec grand plaisir que je me suis attaqué à cette tâche. Je me suis rapidement adjoint une excellente équipe d’experts que sont Luc Vaillancourt, Sacha Declomesnil, Carl-Frédéric De Celles et Sébastien Provencher, tout en m’assurant du soutien d’un vétéran vedette des WebÉducations (il va aimer ça!), Thierry Goulet.

Je vous invite à découvrir le plan de la journée qui s’annonce fort intéressante. Vous y trouverez également tous les détails pour vous inscrire.

J’en profite pour vous rappeler que ces journées conférences sont organisées par le ministère des Services gouvernementaux pour les webmestres et les agents de communication de la fonction publique québécoise, mais que les portes sont grandes ouvertes pour tout le monde! Et c’est gratuit! Profitez-en! Dépêchez-vous, car le nombre de places est limité!

Qui aura raison, qui aura tord? Y aura-t-il des alliances stratégiques et des trahisons? Est-ce que le sang coulera à flot? C’est ce que vous verrez si vous venez y assister!

J’espère vous y voir!

Je sentais donc le besoin de mettre à jour le descriptif des services que j’offre. Vous trouverez donc plus de détails sur la page de mes services.

La réponse n’est pas simple et est toute relative. Chaque technique possède ses forces et ses faiblesses. Je vais tenter de départager les deux en considérant plus spécifiquement leur utilisation en lien avec les tests d’utilisabilité, puisque tel était le contexte de la question. Je tiens, en effet, à mentionner que ces deux techniques peuvent s’utiliser avantageusement dans le cadre de tout processus de conception d’interface, puisque qu’elles n’ont pas été principalement développées à des fins de tests, mais plutôt pour le prototypage rapide en général. Je précise également que mon but n’est pas de décrire le plus précisément possible chacune des solutions, mais plutôt d’identifier en quoi le choix de l’une ou l’autre peut s’avérer préférable et dans quel contexte.

Je dirais tout d’abord qu’il y a plusieurs aspects à considérer.

Premièrement, la vitesse. Aussi rapides et intuitifs que soient Mockups et Napkee, il n’y a rien qui batte en vitesse le griffonnage sur un bout de papier. Cet avantage ressort en particulier lorsqu’on se permet d’effectuer des changements pendant les sessions de tests. On peut ainsi valider très rapidement de nouvelles idées ou des corrections en cours de route. Mais, bien sûr, ce critère, si important soit-il, n’est pas suffisant et ne s’applique pas à toute situation.

Le « niveau de fidélité » ou, disons, la proximité du prototype d’une interface réelle, est nettement ce qui distingue le plus les deux approches et doit être un des principaux critères à considérer lors du choix de l’une ou l’autre des solutions. De par leur nature même, Mockups et Napkee permettent de tester une maquette dans une situation passablement semblable à celle de l’utilisateur final. De fait, plus le contexte du test est réaliste, plus on pourrait s’attendre à obtenir des résultats précis et significatifs. Par contre, ce n’est pas complètement vrai. Un utilisateur en situation de test n’agit pas exactement comme s’il était tranquille chez lui. Même de manière inconsciente, le stress de performance et l’environnement modifient le comportement. Le simple fait qu’il y ait des observateurs change l’état de ce qui est observé. C’est une loi de la physique quantique. En ce sens, le support de l’interface testé perd de son importance. Ce qui compte le plus, c’est la clarté du concept exposé au testeur.

Enfin, je considère également l’aspect collaboratif comme étant très important, même s’il a moins de liens avec les tests d’utilisabilité à proprement parler. Le prototypage papier se prête bien au travail d’équipe et favorise l’intégration de divers spécialistes (designer graphique, intégrateur, stratège, ergonome, gestionnaire, programmeur et même client) au sein du processus de conception. Mockups, et c’est à mon avis son principal défaut, ne gère pas cette collaboration, ou du moins pas directement. Le processus de conception, trop souvent découpé en étapes fermées, aurait avantage à s’ouvrir à une certaine fluidité, à une participation en parallèle des divers intervenants pour en arriver à un produit beaucoup plus complet.

Bref, les deux techniques possèdent de grandes qualités et, bien qu’assez proches, elles diffèrent suffisamment pour poursuivre des objectifs distincts. Dans un processus itératif de conception, on peut très bien utiliser les deux techniques, mais à des étapes différentes. Et plus on est au début du processus, plus on peut se permettre d’être en « basse fidélité ». La flexibilité quasi infinie du papier se prête bien à la validation de concepts de base. Tandis que le réalisme du prototype sur écran nous permet de tester des éléments déjà un peu plus peaufinés.

Au final, le plus important, c’est de développer l’habitude de se servir (et de bien se servir) des tests d’utilisabilité pour optimiser les résultats de nos processus de conception d’interfaces, quelles qu’elles soient.