Communiquer sur le design
Par D Keith Robinson
L’autre jour, j’ai lancé une remarque sur Twitter à propos des « wireframes ». Cela m’a fait réfléchir au processus de design et à la façon dont les designers communiquent leurs choix de conception. Ce sont des sujets auxquels j’ai beaucoup réfléchi au fil des années [1]. J’ai eu la chance de pouvoir participer à pratiquement tous les aspects de la conception de produits numériques ; et de suivre ce processus tant du point de vue d’un chef de produit, que celui d’un designer, d’un développeur, d’un directeur artistique, etc.
Je pense avoir ainsi acquis un point de vue et une expérience personnelle assez uniques qui m’ont amené à la conclusion suivante :
Pour communiquer sur le « design », il faut en général moins de documentation et plus de communication claire, concise et continue.
En d’autres termes : passez du temps à concevoir, pas à documenter. Je ne sais pas pour vous, mais contrairement à ce que j’entends de certains designers, je ne suis pas là pour faire des organigrammes, des personas et des wireframes. Au final, ces choses ne comptent pas. Même dans le meilleur des cas, elles coûtent beaucoup de temps et d’énergie. Au pire, elles peuvent être source de problèmes de communication ou utilisées comme justification lorsqu’une conception de produit n’aboutit pas. J’ai vu de grandes idées mourir prématurément faute d’avoir atteint un consensus sur la documentation. C’est ridicule.
Très souvent, les designers consacrent beaucoup trop de temps à produire des livrables impressionnants mais inefficaces, et pas assez à s’assurer que les décisions, les choix au cœur de ces livrables soient compris de façon appropriée [2].
Communiquer les choix de conception (sans obligatoirement les documenter) est assurément une part essentielle du processus de design. Mais ce sont ces idées, ces décisions – et leur impact sur le produit final – qui comptent vraiment, non les documents en eux-mêmes.
Dans la plupart des cas :
- Si vous faites de la conception « haut niveau » (définition des buts, plans d’action, spécification fonctionnelle, planning de contenus, parcours de navigation, etc...), vous devriez passer votre temps à réfléchir et à résoudre les problématiques, et ensuite, aussi brièvement et clairement que possible, communiquer les résultats de cette réflexion.
- Si vous faites de la conception détaillée (conception graphique, interfaces utilisateur, conception d’interaction), vous devriez travailler sur les détails et les ressources qui participeront au produit final. Si vous en avez la capacité, vous devriez produire (ou produire en collaboration directe avec un ingénieur) des prototypes directement fonctionnels, ou, mieux encore, travailler directement sur le produit final en lui-même. Même si je ne code pas beaucoup, je suis un grand fan de l’approche « conception en direct ».
- Si vous faites de la conception intermédiaire – comme des wireframes ou des personas [3] – faites-le avec une attention extrême. Rappelez-vous que ce sont des moyens vers un but, une fin ; considérez-les ainsi et vous aurez beaucoup moins de problèmes.
Je me rends bien compte (faites-moi confiance) que tout ceci n’est pas toujours faisable. Habituellement, cela se joue à la composition de votre équipe. Vous pouvez avoir des concepteurs UX (ou ergonomes) qui ne sont pas très à l’aise avec l’apparence, ou un designer qui, comme moi, ne code pas beaucoup. Et cela peut marcher, encore une fois, s’il y a des personnes qui savent communiquer. Je ne vais pas relancer la polémique du « spécialiste contre le généraliste », à part pour dire que tout le monde, dans une équipe, devrait tendre vers une compréhension solide du travail de ses collègues [4]. Les designers devraient au moins être capable de communiquer efficacement avec les ingénieurs, et vice versa. Et si vous avez des personnes dont les talents englobent plusieurs parties des compétences en jeu, c’est génial. Même si elles n’accomplissent pas directement tout le travail. Par exemple, je peux coder, mais habituellement, il y a quelqu’un dans l’équipe qui est meilleur que moi pour cela. C’est une bonne chose que d’avoir cette capacité, d’être capable de discuter de cette partie, et en même temps de laisser mes collègues faire ce qu’ils font de mieux.
(Un petit aparté : j’ai remarqué que les grandes équipes sont souvent plus lentes. Plus de ressources ne signifie pas nécessairement un développement plus rapide ou meilleur. La problématique que ce billet essaie d’aborder est davantage liée au « process » en lui-même, mais je pense qu’une bonne part de ces problèmes pourraient être résolus simplement en constituant des équipes plus petites et plus concentrées.)
Communication
La capacité d’un designer à communiquer : écouter, répondre aux questions, etc. est probablement sa qualité la plus importante [5]. Garder une ligne de communication claire et ouverte entre vous, vos collègues et vos donneurs d’ordres peut ainsi faire toute la différence.
Tout cela nécessite de la confiance avec les personnes avec qui vous travaillez, ainsi qu’une volonté d’ouverture, de transparence. Vous pouvez avoir le sentiment que vous abandonnez le contrôle, et d’une certaine façon, c’est bien le cas ; mais à travers ce partage vous aurez souvent une meilleure emprise sur le rendu final. Vous savez, ce truc important sur lequel vous travaillez.
Je suis profondément convaincu que les designers devraient être plus désireux de partager, et d’accepter des remarques tout au long du processus. Je crois que le « bon design » nécessite une vision solide et personnelle mais je reconnais que permettre à plus de personnes d’interagir dans le déroulement peut être une bonne chose, si cela est bien fait. L’important n’est pas d’obtenir le consensus [6], mais plutôt de partager et tirer avantage de tous les talents de votre équipe. Vous pouvez avoir une vision forte, tout en étant ouvert à d’autres idées et remarques. En fait, c’est même en grande partie ce qui rend un designer meilleur.
J’aime l’idée de réduire le processus de conception à de très courts cycles de conception / réalisation, dans lesquels les designers et les ingénieurs travaillent de façon soudée et itèrent souvent. Ne vous y trompez pas, c’est difficile et demande une compréhension globale ainsi qu’une très bonne capacité à communiquer.
Cela étant dit, je pense que finalement, un designer devrait être flexible et capable de s’ajuster au processus qui fonctionne pour le reste de son équipe. Dans l’idéal, pour ma part, je préférerais passer une plus grande partie de mon temps à travailler sur le produit final plutôt que sur mes livrables de conception. Ce genre de choses peut être utile et parfois nécessaire, mais, à mon avis, l’attention devrait toujours être portée sur le produit final.
Et croyez-moi, tandis que vous êtes occupés à documenter vos idées, vos concurrents s’activent sur une réalisation, avec de vraies données. Plus tôt votre produit – même imparfait – est entre les mains du public, mieux c’est. Je pense que la plupart de mes lecteurs seront d’accord, alors pourquoi les designers perdent-ils encore autant de temps là-dessus ?
[1] J’ai même donné quelques conférences sur ce sujet, mais j’admets que ma pensée a quelque peu changé ces dernières années.
[2] J’ai écrit « compris » ici (au lieu de « appliqués »), car un des problèmes avec beaucoup de documents de conception, c’est de les considérer comme « finaux ». C’est un autre sujet, mais brièvement : la conception / le design sont des processus itératifs et vos livrables sont généralement périmés à la seconde où vous les considérez comme finaux.
[3] Ceux que j’appelle les « livrables flous ».
[4] Par exemple, j’ai essayé d’apprendre du mieux possible Python et Django pour m’aider à avoir une meilleure base de référence lorsque je travaille avec les ingénieurs.
[5] Ok, vous pouvez probablement considérer qu’« écouter » est la base du talent d’un designer. En partant du fait qu’ils écoutent vraiment, ce qui... enfin, bref...
[6] Rappelez-vous, Le consensus, c’est pour les perdants
http://www.dkeithrobinson.com/features/entry/thoughts_on_communicating_design/