Simon Bédard

Dans un commentaire sur mon billet qui expose les vidéos de ma présentation sur le paper prototyping, Karl me pose une excellente question: quels sont les avantages d’utiliser le paper prototyping par rapport à une solution simple et intuitive de conception « basse fidélité » sur ordinateur, telles que Balsamiq Mockups et Napkee? J’en profite pour souligner le fait que cette question a justement été brièvement débattue lors de la journée WebÉducation à laquelle j’ai participé.

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.