Présenter un visuel en cours de réalisation (1)
Faut-il présenter un visuel en cours de réalisation?
En règle général, les designers ne présentent des propositions graphiques que si elles sont « présentables », c’est à dire abouties dans leur forme, et répondant aux exigences du message à transmettre validé en amont. C’est la procédure traditionnelle. Cependant…
… il peut arriver, lors d’une mission que le designer ait à présenter un travail en cours de réalisation. Cette situation existe, généralement à la demande de l’annonceur. Elle est la conséquence de facteurs variés :
- L’annonceur souhaite contrôler l’avancée du travail des créatifs.
- Le designer travaille en régie chez l’annonceur, sans avoir la possibilité de garder son travail confidentiel.
- Une mauvaise gestion du projet impose de casser le rythme séquentiel du processus de production, et une partie du design doit être livrée prématurément pour commencer l’intégration d’un secteur du site.
- Le designer est en retard dans la livraison de ses productions.
La liste est, bien sûr, non exhaustive.
Disons-le clairement, et tout de suite, il n’est pas souhaitable de présenter un visuel inachevé au client, et il faut tout faire pour éviter cette situation.
La présentation du design est déjà une phase délicate dans la relation prestataire/annonceur. Le fait de présenter des visuels inaboutis peut avoir des conséquences dramatiques sur l’avancée du projet et dégrader significativement les relations entre les deux parties. C’est pourquoi il convient de tout faire pour garder les productions visuelles confidentielles tant que celles-ci ne sont pas abouties. L’argumentation s’articule autour des trois principaux risques induits par la situation :
Risque 1 : Quiproquo sur l’objectif de la réunion.
Avant de montrer des visuels inachevés à l’annonceur, il faut s’assurer pas qu’il y ait de quiproquos ou d’ambiguïté sur l’objet de cette présentation :
Tout d’abord, ce que l’annonceur va découvrir ne constitue pas des propositions visuelles, ce sont des tests, des recherches, des pistes exploratoires. Quel que soit le degré d’avancement de ces pistes, rien ne garantit qu’elles seront ensuite exploitées. Elles peuvent être abandonnées à tout moment.
Ensuite, comme les visuels dévoilés peuvent ne pas être adaptés au contexte du projet, les gens qui assistent à la présentation doivent comprendre qu’il ne leur sera pas possible d’évaluer l’univers en construction sur des données visuelles. Seul le discours du designer pourra les éclairer sur le devenir de ces compositions. Les visuels ne seront pas l’objet de la présentation, ils seront des supports pour que le designer puisse exprimer oralement le concept créatif naissant. Il leur faudra donc faire abstraction des visuels présentés. Rares sont les gens qui, sans être habitués à cette démarche intellectuelle y arrivent instinctivement. Il faut le souligner.
Enfin, cette réunion ne doit pas être abordée comme une réunion de présentation de visuels, mais comme un point de contrôle sur l’avancée du processus créatif.
Risque 2 : Atteinte à l’intégrité du projet.
Les visuels présentés ne sont pas aboutis. Naturellement les gens présents lors de la réunion auront tendance, à focaliser leur attention sur les bribes d’éléments en cours de conception, et demander des modifications sur ces éléments. Mais toutes ces interventions peuvent être déconnectées du projet, parce que les visuels présentés, eux-mêmes peuvent l’être. Ainsi, toutes les remarques émises lors de la réunion, impliquant des demandes de modifications, risquent de sortir le projet de son cadre initial. Dans le meilleur des cas, c’est une perte de temps que de faire des modifications sur des pistes qui sont amenées à être abandonnées par la suite. Dans le pire des cas, l’annonceur maintient ses demandes de modifications pour tenter de rendre conforme au projet une piste graphique qui aurait due être abandonnée. Dans ce cas, c’est toute la qualité générale du projet qui en pâtira.
Risque 3 : Dégradation de la relation prestataire/annonceur
En découvrant des pistes visuelles, le premier réflexe, bien humain, de l’annonceur sera de chercher à se projeter dans cette bribe d’univers graphique. Si les éléments présentés ne lui permettent pas cette démarche, ou pire, s’ils ne permettent pas de faire le lien entre elles et les recommandations stratégiques validées en amont, la situation engendrera forcement de la déception, et de la frustration chez l’annonceur.
Pour le designer, il est difficile de justifier un travail inachevé. La situation est même parfois discréditante. Bref, cette situation est aussi stressante pour l’annonceur que pour le designer. Sachons nous en préserver.
Pour compléter ce billet, je reviendrai sur le sujet la semaine prochaine, et j’évoquerai une approche possible pour présenter des visuels inachevés au client (méthodes, supports, attitude…).
A suivre …
1. Le jeudi 22 octobre 2009 à 22h03, par Jacques Bodin-Hullin
Ce principe est également valable en développement.
Je pense surtout au passage lié à l’intégration du design et aux différents tests sur certaines parties du projet.
Montrer l’avancement avec des éléments non intégrés, des bordures rouges, des fonds jaunes/violets/bleus ou encore pire des « erreurs » en haut des pages (un simple debug pour le développeur qui n’apparaîtra pas en production par exemple), peut rendre le développeur/intégrateur peu crédible sur ses compétences, même s’il s’agit là d’un passage obligé lors d’une intégration/d’un développement.
De plus le client, s’il n’est pas connaisseur, peut vite avoir peur et la mission risque d’être un peu secouée.
S’il le projet est gros et qu’il nécessite une validation partie par partie du client, pour être certain que ça avance comme il le souhaite par exemple (une application peut vite devenir très complexe et on a parfois besoin de se dire « ça c’est fait »), il faut le faire mais il faut se contraindre à ne montrer que des parties terminées.
C’est mon avis !
2. Le mercredi 30 décembre 2009 à 00h08, par Bruno N
Tout à fait d’accord, c’est exactement pareil pour l’intégration/développement.
Je travaille en agence et les chefs de projets, ainsi que les boss, ne pensent qu’à cela : donner la possibilité au client de voir l’avancement du travail au fur et à mesure, chose à laquelle je suis totalement opposé évidemment. Surtout que je bosse d’abord en local et environnement de dev, donc avec l’affichage des erreurs, parfois des variables de sessions ou autres… Combien de mails de clients n’ai-je pas déjà reçus, me disant qu’il y avait des erreurs, des blocs du wireframe qui ne s’affichaient pas, du texte en latin (lorem ipsum),… Venant du client, qui ignore bien souvent le processus d’intégration/développement) c’est compréhensible, mais quand ces remarques me sont faites par les chefs de projet ou par les boss (si si c’est arrivé)… No comment !
Mais cela arrive la plupart du temps (donc souvent dans mon cas) quand les délais sont totalement farfelus, voire inexistants. Si les délais de livraison sont bien définis avec le client, et que surtout on laisse à la prod l’occasion de les tenir, le client ne demandera pas de voir quoi que ce soit avant la finalisation du site, ou s’il demande à voir, c’est très facile de lui rappeler que les délais seront tenus pour le rassurer.