Concevoir une interface : la part du désordre

« Conception centrée sur l’utilisateur », « Facteurs humains » ! Je souscris à ces paradigmes  et à l’esprit qui les anime. Mettre l’utilisateur au centre de la conception, une grande et belle idée, prendre en compte l’humain, une obligation éthique pour tout professionnel qui se respecte.

Penser aux employés ou clients qui utiliseront les interfaces que l’on conçoit, certes, mais peut-on y arriver en déshumanisant son propre travail ? Si un travail rigoureux individuellement est obligatoire, il faut savoir être souple et s’adapter aux habitudes et contraintes des autres intervenants d’un projet. Vous êtes un professionnel du design interactif, ils n’ont pas vos compétences et ne comprennent pas votre jargon. Ils ont des impératifs que vous n’avez pas et vous devez le respecter.

Aussi, inévitablement, un projet atteint une phase où tout semble s’être dispersé, chacun attendant sur l’autre. On fait face à un désordre épars de données, de documents, de livrables … En général c’est à ce moment que l’on a tendance à s’imposer encore plus de rigueur pour résoudre le problème, alors qu’il est plus productif d’organiser le désordre.

Quels sont les bons ingrédients d’un désordre organisé ?

Wireframes

Les wireframes (« fil de fer ») sont un excellent outil de conception.  Ce sont des documents esquissant sommairement la future interface.

Son aspect volontairement dénué de toute esthétique, voire volontairement brouillon, permet de se focaliser sur l’utilité et l’utilisabilité des composants d’interface, du parcours utilisateur choisi, de la correspondance de la proposition aux objectifs du commanditaire.

Prototypes

Pour aller plus loin, il est parfois utile d’envisager un prototype interactif.

Le prototype permet à la fois de tester les interactions et la navigation, si possible auprès de vrais utilisateurs, mais aussi d’avoir un livrable compréhensible pour les autres intervenants d’un projet, lesquels ne sont pas tous à même de déchiffrer un wireframe documenté avec des termes tels que « zone extensible », « carrousel », « navigation secondaire »…qui peuvent être mal interprétés.

En cela c’est un outil spectaculaire pour présenter le fruit de son travail, plutôt qu’un rapport indigeste que personne ne lira (conf. mon article « présenter sa documentation« )

Savoir s’arrêter

Il est tentant d’utiliser un prototype (ou les wireframes ayant servi à sa réalisation) comme document de référence, alors que ça n’est qu’un outil de mise à l’épreuve.

La conception d’une interface présente le paradoxe bien connu du serpent qui se mord la queue : il faut concevoir une interface ergonomique, mais on ne peut pas juger de son ergonomie tant qu’elle n’est pas créée. Et il n’existe pas de méthode pour concevoir une ergonomie parfaite dés la première itération. D’ailleurs la première itération est toujours mauvaise.

Une fois le prototype présenté et éprouvé apparaissent des erreurs et des réorientations, qui viennent valider ou invalider certains de vos choix.  Votre prototype est alors une base imparfaite mais aussi un point de référence. Il faut soit en faire une version 2, soit l’abandonner. Si vous travaillez sur des cycles courts comme c’est souvent mon cas, vous n’aurez pas les moyens ni le temps de refaire un prototype.

Mieux vaut produire de nouveaux wireframes ou corriger les premiers, dans le but d’augmenter le niveau de confiance de chaque nouvelle version. Le niveau de confiance, c’est la correspondance entre ce que vous avez conçu et ce que vous savez de sa pertinence. Par exemple vous savez que votre formulaire d’inscription est bien conçu car vous avez tous les champs et que vous connaissez le niveau d’expertise des utilisateurs, le niveau de confiance est élevé. Si, en attendant qu’on vous donne le détail exact, vous avez inventé les champs pour anticiper, le niveau de confiance est faible.

La référence définitive

La référence définitive est l’interface réalisée. Je suis ne suis pas de l’école « processus qualité » qui consiste à découper un projet en phases et postes biens définis avec un rétro-planning arrêté pour chaque jour de la semaine. La force des wireframe est leur rapidité d’exécution, c’est aussi leur limite. Faut-il créer un « wireframe avancé » annoté et plaçant chaque bloc au pixel près ? J’aurais plutôt tendance à croire que cela ralentit le projet et pêche par excès de confiance. Vous travaillez avec des humains, soyons souples. J’aime beaucoup l’illustration du processus organique réalisée par Nishant Kothary, designer chez Microsoft Mix :

Processus organique

Conserver le flottement

Voilà le moment de la conclusion polémique : je pense qu’il faut organiser un moment de flottement dès que vous sentez qu’il faut commencer à juger sur pièces. Quand vos wireframes et prototypes ont fait la plus grosse part du travail qu’ils pouvaient accomplir, vous ne pouvez plus réellement avancer sans voir le produit fini auquel seront confrontés les utilisateurs. Le niveau de confiance de chaque wireframe ne peut plus augmenter.

C’est le moment de passer à une nouvelle phase. Tester auprès d’utilisateurs, commencer le design graphique, voire même le développement, et de commencer une série de cycles  propositions/corrections très courts. C’est un moment clef où l’on pose les fondations et où l’on apprend beaucoup de choses qu’on n’aurait pu apprendre uniquement en interrogeant en amont et en planifiant. Vos collègues/prestataires/clients seront confrontés à des problématiques concrètes et pourront les reformuler dans leur langage pour les éprouver selon leur propre grille. C’est le moment où l’on se construit une image commune du projet, loin des diagrammes et schémas cloisonnés par corps de métiers.

Chaque phase doit être traitée avec sérieux et méthode, cependant c’est le professionnalisme qui impose de savoir s’orienter dans le désordre.