image

Session Ergonomie aux TechDays 2011

Je viens de regarder la session “Changer la vie de vos utilisateurs en intégrant design et ergonomie” (étrange d’avoir un nom aussi long pour une session sur l’ergonomie…) d’un de mes ex-collègues Olivier Courtois de la société Bewise.

Cette session est très réussie tant au niveau de la forme (je n’en attendais pas moins de la part d’Olivier) que du fond.

Je vous invite donc à la visionner si vous vous intéressez de près ou de loin à ce sujet.

image

Suite à cette présentation, je me suis décidé à tester cette “conception centrée utilisateur” présentée dans cette session, sur le développement de ma prochaine fonctionnalité.

Je ne suis pas designer ni ergonome, je vais donc uniquement donner mon point de vue de développeur sur cette méthode de travail et pourquoi je me suis décidé à l’expérimenter.

L’objectif de débuter par la conception et la réalisation de l’interface utilisateur au lieu de débuter par la conception et l’écriture de code pour les couches sous-jacente est tout à fait pertinente puisqu’elle permet de se concentrer sur le principal acteur de votre application : l’utilisateur.

Celui-ci se moque éperdument de savoir si vous écrit du code ADO.net à la mano ou si vous avez utiliser le dernier ORM à la mode.

Les seuls interlocuteurs qui peuvent vous reprocher du code écrit avec les pieds et/ou non maintenable sont :

  • les développeurs de votre équipe qui vont potentiellement vous écharper d’avoir écrit du code en carton
  • vos responsables (chef de projet, n+1, etc.) qui verront d’un mauvais œil le fait qu’il soit nécessaire de passer 3 siècles à maintenir et faire évoluer une fonctionnalité qui certes est très bien d’un point de vue UI mais coute au final très cher en développement

Le fait de débuter par la création de l’UI présente les avantages suivants :

  • permet de faire des itérations de validation de la fonctionnalité d’un point de vue de son utilisation avant même de penser à l’implémentation technique sous-jacente.
  • Permet de ne pas bâcler l’UI et l’ergonomie. Si je dois mettre 5 jours à implémenter une fonctionnalité, et que je commence par la partie la plus technique, il y a des chances que le temps consacré à l’UI soit réduit, et que les solutions adoptées soient les solutions “au plus vite”
  • Permet d’éviter l’over-engineering. Si le développeur attaque débute par le développement de l’UI il y a de fortes chances qu’il n’est ensuite plus le temps de réfléchir à implémenter une solution technique inutilement complexe.

Il ne me reste plus qu’à expérimenter tout cela, que cela soit d’un point de vue du process (sketchs, itérations de validations, puis dév) que des outils (balsamiq, SketchFlow, etc.). Je ne manquerais pas de partager avec vous mes premiers retours à ce sujet !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *