WIF12 : expérience utilisateur, expérience de designer

Bookmark and Share
Jeudi 29 mars 2012

WIF12 : expérience utilisateur, expérience de designer
Le 16 mars, se sont déroulées les présélections du concours du Festival international du design interactif de Limoges, mieux connu sous le nom de WIF (voire #wif12 pour les tweetos !). 24 heures chrono pour réaliser, en équipe de quatre maximum, un prototype d'interface ou service innovant. Cette année, le sujet de la compétition était "Design interactif et développement durable".

Une équipe de novusiens faisait partie des 200 équipes qui, à travers le monde, ont pris part au challenge. On a beaucoup parlé expérience utilisateur et, pourtant, j'en retiens une expérience de designer.


La team Novius était constituée d'un graphiste (Frédéric Jacquemoud), deux développeurs (Julien Guyomard et Sébastien Drouyer) et d'un UX designer (votre serviteur). Notre réalisation porte le nom de Backup Train. Il s'agit d'un prototype de service sur smartphone et mur intelligent (type tweetwall). Son objectif est d'aider les usagers des transports publics à trouver facilement et rapidement une solution de repli, en cas de perturbation du trafic.

Je vous laisse découvrir notre projet. Je vais plutôt vous parler de sa réalisation en marche forcée et des enseignements que j'en tire.

 

In-browser prototyping

En plus de dix années de web design, j'ai utilisé de nombreuses techniques de prototypage : maquettes ou wireframes cliquables (avec de bonnes vieilles images mappées ou, plus récemment, InVision), logiciels dédiés (Balsamiq, Axure), vidéos de démonstration, Flash, etc. Depuis plusieurs mois, je m'intéresse surtout à ce que ZURB appelle le in-browser prototyping.

En quoi consiste cette méthode ? Il s'agit d'attaquer le code le plus tôt possible, sans pour autant perdre en rapidité d'exécution ce qui est essentiel pour le prototypage. Concrètement, on utilise un inspecteur de code (Firebug) et un boilerplate comme Foundation, Twitter Bootstrap ou encore HTML KickStart. Ce sont de vrais kits à prototype. Ils fournissent des styles de base, une grille typographique, des éléments d'UI (menus, formulaires), des plugins jQuery (diaporamas, fenêtres modales), j'en passe.

Bref, la seule installation à faire est celle du boilerplate, on dispose alors de tous les éléments nécessaires pour prototyper. Cerise sur le gâteau, ces boilerplates sont tous à l'heure du multi-devices, contrairement à la plupart des autres techniques de prototypage. Ils sont ainsi en adéquation avec des méthodes future-friendly, comme le design universel et Mobile First.

Pour le WIF, là où le in-browser prototyping s'est révélé décisif, c'est qu'il n'y a pas de rupture entre le prototype et le produit final. Il n'y a pas à intégrer des maquettes, le prototype évolue naturellement en un site ou application, au fur et à mesure qu'on l'affine, qu'on rentre dans le détail. C'est ce qui s'est passé pour le site Backup Train : le site est le prototype. Nous aurions difficilement pu nous permettre de réaliser un site plus une application mobile en 24 heures, si nous avions choisi une autre technique de prototypage.

 

Réflechir longuement, produire vite

La question s'est tout de suite posée : doit-on se fixer des deadlines intermédiaires, étape par étape, pour tenir LA deadline, celle des 24 heures ? Nous sommes tombés d'accord, pas de limite à la réflexion. Ce n'était pas pour moi une décision évidente. J'étais tenté de dire : imposons une deadline, de la contrainte naîtra l'idée. Je me suis rendu compte a posteriori que nous avions fait le bon choix. Ou plutôt les bons choix, car en décidant de prendre notre temps pour réfléchir, nous actions que la production, elle, aurait à être rapide.

Backup Train n'aurait pas vu le jour si nous n'avions dédié que deux heures à la réflexion. Le concept nous est, en effet, venu relativement tardivement. Or, il s'agit de la fondation du projet, sur laquelle il est difficile de revenir après coup. Autant donc partir confiant, ce que nous avons fait.

Produire vite a aussi ses vertus. On se concentre sur l'essentiel, on touche plus rapidement au concret et, le diable étant dans les détails, cela révèle des zones d'ombre qu'il était impossible d'identifier lors de la réflexion initiale. Cela permet aussi de garder l'idée au chaud, que le développement ne devienne pas une fin en soi. Le in-browser prototyping s'inscrit parfaitement dans cette logique.

L'expérience d'un concours est-elle transposable à un cas réel, en agence notamment ? Au moment d'établir un rétro-planning, peut-on raisonnablement se dire : prenons tout le temps de la réflexion, on produira plus vite (et sans doute moins) ? Cela semble utopique, pourtant, l'idée est séduisante car elle impose des contraintes là où elles sont bénéfiques. Sur la production, pour séparer l'essentiel du superflu, plutôt que sur la réflexion, où le risque est d'aboutir à une idée mort-née.

 

Inter-disciplinarité obligatoire

Mon meilleur souvenir du challenge est le travail en commun et sans frontières. Bien entendu, nous avons tous nos spécialités, mais nous avons fourni un vrai travail d'équipe, décloisonné. Habituellement, nous travaillons par phase : la conception, puis le graphisme, puis le développement. Evidemment, les méthodes agiles permettent de casser ce cycle en V mais, cela n'empêche, les phases de travail simultanées entre les différents corps de métier ne sont pas si fréquentes que ça.

Pour le WIF, nous avons tous suivi le projet de A à Z. De l'idée à la mise en ligne. On ne demandait pas l'avis d'un technicien pendant la phase de conception ou celui d'un graphiste lors de la finalisation. Il s'agissait de l'avis d'un équipier, peu importe sa spécialité et peu importe la phase du projet.

C'est le rush qui nous a imposé cette inter-disciplinarité et c'est bien malheureux. Au quotidien, malgré toutes les velléités d'agilité et de transversalité, nous cloisonnons, souvent inconsciemment. Pourtant, rien de tel que de mettre la main à la pâte, au code pour un designer, au design pour un technicien, pour mieux comprendre l'autre et arriver, collectivement, à une solution plus intelligente.

 

Et maintenant ?

Les réalisations des différentes équipes ont été publiées il y a peu. Je n'ai pas eu encore l'occasion de tout regarder (je doute l'avoir un jour), mais j'ai déjà vu d'excellents projets. La partie s'annonce serrée.

Les résultats seront connus le 2 avril et je croise les doigts pour que la team Novius soit de la finale à Limoges. L'occasion de renouveler cette expérience de designer, au service de l'expérience utilisateur.

5 commentaires
  • Commentaire par Antoine Lefeuvre
    Lundi 2 avril 2012 18:25
    On va donc renouveler l'expérience. La team Novius est en finale http://webdesign-festival.com/2012/2012/04/les-finalistes-du-wif12-sont/. Limoges, nous voilà !
  • Commentaire par jfavlam
    Lundi 2 avril 2012 19:02
    Félicitation à la team Novius ! et merci pour cet article retour d'expérience.
    En espérant vous croiser à la finale ;)
  • Commentaire par Antoine Lefeuvre
    Mardi 3 avril 2012 13:05
    Merci bien, bravo à ton équipe aussi et on se voit à Limoges.
  • Commentaire par Etienne Delagrave
    Lundi 23 avril 2012 22:09
    J'aime cette approche également. Même pour la prod, il y a des avantages à utiliser un cadriciel. J'en parle ici:

    http://www.adviso.ca/blog/2012/03/27/framework-interface/

    Merci!
  • Commentaire par Antoine Lefeuvre
    Mardi 24 avril 2012 10:24
    Bonjour Etienne,

    merci bien pour ton commentaire car je découvre :
    1. un excellent article à ce sujet
    2. la traduction française de framework !

    A très bientôt sur votre blog ou le nôtre
Laissez votre commentaire :