Design Talks : Meilleure collaboration entre concepteurs et développeurs avec Aarron Walter d'InVision

Bienvenue dans notre série Design Talks dédiée au partage des idées des leaders d'opinion et des personnalités les plus engagées dans le design du monde entier. Nous interviewons des experts qui travaillent avec le design dans différents contextes, avec différents objectifs et à travers différentes approches. Dans ces séries, nous espérons fournir une inspiration intellectuelle et créative à tous nos lecteurs.

Les concepteurs ont souvent du mal à travailler avec les développeurs et vice versa. Les équipes des deux côtés pourraient apprendre énormément les unes des autres, mais des couches de résistance subsistent. L'invité de cette semaine est Aarron Walter, vice-président de la formation en design chez InVision et nous allons parler de la collaboration entre concepteurs et développeurs.

Aarron s'appuie sur 15 ans d'expérience dans la gestion d'équipes de produits et l'enseignement de la conception pour aider les entreprises à adopter les meilleures pratiques de conception. Il a fondé la pratique UX chez MailChimp et a aidé à faire passer le produit de quelques milliers d'utilisateurs à plus de 10 millions.

Ses conseils en matière de conception ont aidé la Maison Blanche, le Département d'État américain et des dizaines de grandes entreprises, startups et sociétés de capital-risque. Il est l'auteur du best-seller Designing for Emotion from A Book Apart. Vous trouverez @aarron sur Twitter partageant des réflexions sur le design et vous pouvez en savoir plus sur Aarron sur aarronwalter.com.

Sur le podcast Design Better, les animateurs Aarron Walter et Eli Woolery interviewent des leaders du design et des influenceurs qui partagent des histoires sur la façon dont ils résolvent les problèmes et leur cheminement de carrière. Parmi les invités figurent David Kelley (co-fondateur d'IDEO et fondateur de Stanford d.school), Julie Zhuo (VP Product and Design chez Facebook) et Jake Knapp (auteur à succès de Sprint), entre autres.

Bonjour Aarron, c'est un plaisir de vous avoir sur le blog Toptal Design. Les développeurs viennent-ils de Mars et les designers de Vénus ?

D'après mon expérience, les concepteurs et les développeurs ont probablement plus en commun qu'ils ne le pensent, mais il existe certainement des différences distinctes dans la façon dont nous pensons les choses. Les concepteurs adorent penser aux systèmes de conception, et les développeurs pensent à un code modulaire facile à entretenir. Mais la façon dont nous procédons peut être légèrement différente.

Les développeurs ont trouvé des moyens de décomposer leur travail en plus petits morceaux, et les concepteurs ont tendance à considérer le tout comme le "gâteau entier" et comment mangeons-nous tout le gâteau.

C'est un point où ils commencent à se cogner la tête. Les ingénieurs veulent pouvoir expédier du code par petites étapes et faire quelque chose très rapidement dans le cadre de la méthodologie Agile. Les concepteurs ont tendance à vouloir faire un grand pas en avant de manière holistique, ils veulent offrir une expérience cohérente. Cela peut être un point de discorde pour ces deux groupes.

Que peuvent faire les designers pour amener un peu les développeurs à notre point de vue ? Comment les concepteurs font-ils comprendre aux développeurs que chaque petite fonctionnalité fournie concerne également l'expérience ?

Il y a une opportunité pour les deux côtés de plier ici. Les concepteurs essaient parfois de convaincre un développeur que nous devons attendre et construire le tout, puis le faire sortir comme cette belle expérience complète.

Mais si le cycle de création est trop long, les produits risquent d'être tués. Les gens commencent à se désintéresser. Ils peuvent dire : « Cela crée-t-il réellement de la valeur pour l'entreprise ? Nous consacrons une tonne de temps, d'énergie et de ressources à cette chose, pourquoi cela prend-il si longtemps ? » Les concepteurs doivent réfléchir davantage au cycle des affaires.

Si Apple expédie un téléphone - un élément matériel qui a un problème - cela pourrait potentiellement leur coûter des milliards de dollars, mais si un logiciel est expédié et qu'il y a un problème, nous pouvons simplement le corriger, le réparer et l'expédier à nouveau. Aborder le processus de cette manière nous permet de nous reconnecter plus élégamment au cycle de travail de développement.

Les concepteurs pourraient également essayer de combler le fossé entre les deux groupes en impliquant très tôt les ingénieurs dans le processus de conception afin qu'ils se sentent inclus dans la phase d'idéation précoce, et pas seulement en aval. Les designers peuvent dire : "Nous avons eu cette idée géniale, allez-y, faites-la pour nous !" et cela donne aux développeurs l'impression qu'ils ne font pas partie du processus d'idéation. Ce ne sont que les mains et quelqu'un d'autre est le cerveau.

La relation la plus dysfonctionnelle entre les concepteurs et les développeurs se produit lorsqu'il existe une division du travail distincte. Plus cela commence à se mélanger et que ces équipes travaillent ensemble, mieux c'est. En conséquence, il y aurait de multiples perspectives et une propriété partagée, ce qui est vraiment essentiel pour que les concepteurs et les développeurs travaillent efficacement ensemble.

Mieux comprendre l'espace de l'autre…

Que peuvent faire les équipes pour mieux comprendre l'espace de l'autre ? Les designers doivent-ils se familiariser avec le développement et vice versa ?

Premièrement, les concepteurs et les développeurs pourraient parler davantage aux clients et en apprendre davantage sur le problème de l'espace ensemble . Ils pouvaient parler à trois ou quatre clients le matin autour d'un café ; tout le monde pourrait apprendre très rapidement et arriver à une compréhension commune de ce que sont les préoccupations.

Deuxièmement, en termes de processus de travail, il est important que les concepteurs et les développeurs aient – ​​peut-être pas la maîtrise – mais une certaine compréhension du langage de l'autre. Je ne veux pas dire qu'un designer doit savoir coder, ou que les développeurs doivent maîtriser la typographie, mais au moins il y a une compréhension commune.

Si les concepteurs pouvaient encadrer les choses dans un langage que les développeurs comprennent – ​​« tel ou tel ne fonctionne pas et c'est mauvais pour les affaires » – alors les développeurs comprendraient rapidement le problème. Ce n'est pas quelque chose qui vient naturellement aux designers, mais ils doivent mieux communiquer la valeur de leur travail quantitativement , pas seulement qualitativement . L'équipe commerciale, l'équipe marketing, l'ingénierie, les produits, les cadres, toutes ces personnes parlent en chiffres, elles parlent en quantité .

Cela dit, je crois que le design apporte quelque chose de très précieux, qu'il y a des choses qui comptent qui ne peuvent pas être comptées. L'expérience client, la joie, l'amour pour le produit sont extrêmement précieux, et c'est difficile à quantifier.

Il peut cependant être quantifiable, en bout de ligne, ce composant de qualité apportera un retour sur investissement quantifiable.

Oui, nous pouvons réduire les coûts de support client grâce à la conception, nous pouvons réduire le taux de désabonnement, nous pouvons augmenter la vitesse d'intégration. Avoir des métriques comme celles-là sur lesquelles viser aide la conception à aligner ses efforts sur les objectifs commerciaux. Plus les concepteurs peuvent faire cela, plus ils seront compris. Plus le design est valorisé dans l'entreprise comme un avantage concurrentiel, plus le potentiel d'investissements plus lourds augmentera.

Sur les pièges de la collaboration entre concepteurs et développeurs…

Quels sont certains des plus grands pièges que les concepteurs et les développeurs rencontrent en travaillant ensemble ?

L'un des plus gros pièges est de ne pas avoir de langage commun, de ne pas avoir d'objectifs communs et des ratios très disproportionnés. Parfois, il existe des équipes interfonctionnelles avec un concepteur et 75 ingénieurs. Cela semble fou, mais c'est assez courant.

La grande majorité de ces situations ne sont pas bonnes. Ce designer solitaire est un expatrié. Ils sont un étranger dans un pays étranger où ils ne s'intègrent jamais vraiment dans la culture… et leur système de valeurs est différent du système de valeurs de tous leurs collègues.

Dans cet environnement, plaider en faveur d'une fonctionnalité UX est extrêmement difficile pour un designer : "Nous devrions avoir cette animation dans le produit car elle va créer une expérience plus convaincante…" alors que 75 ingénieurs disent : "C'est 250 de plus lignes de code et deux jours de travail supplémentaires. Ça en vaut vraiment la peine?" Et ce n'est probablement pas le cas. Pour eux, cela ressemblera à du "glaçage". Mais ces micro-interactions animées avec un designer UX façonnent vraiment l'expérience client. Ils ne sont pas les seuls, mais ils sont importants.

Lorsque vous avez ces ratios inégaux entre les concepteurs et les développeurs, cela devient vraiment problématique. Cependant, il existe des solutions. Des entreprises comme Slack résolvent ce problème avec une "conception jumelée". S'il y a un designer pour 10 ingénieurs dans une équipe, et le même ratio dans une autre équipe, ces designers solitaires passent environ huit heures par semaine à travailler ensemble, à se présenter des solutions les uns aux autres : « Voici comment je résous ce problème, est-ce que cela sens pour vous ? Y a-t-il une meilleure manière de faire cela?" Ils peuvent s'aider mutuellement à se décoller et à ne pas se sentir comme s'ils étaient sur une île.

À propos des concepteurs qui transmettent l'importance de l'UX…

Comment les concepteurs peuvent-ils souligner l'importance d'une conception centrée sur l'humain avec des développeurs qui ne comprennent pas vraiment HCD ? Par exemple, comment les concepteurs font-ils comprendre que l'ajout de fonctionnalités ne sert pas nécessairement le client, que l'expérience d'utilisation du produit est plus importante que ses fonctionnalités ?

Il existe plusieurs façons efficaces de le faire. La plupart des concepteurs l'ont probablement fait de manière inefficace en disant directement aux développeurs : « Hé, ajouter plus de fonctionnalités ne rend pas une meilleure expérience. Les gens disent qu'ils le veulent, mais cela ne fait que compliquer le produit », et les développeurs sont susceptibles de répondre : « Je ne pense pas que vous ayez raison, c'est une opinion. Nous entendons cela de nos clients, nous devons donc les suivre.

Il est préférable de ne pas l'aborder de front, mais de le faire de manière oblique et de dire : "Mieux comprendre l'espace problématique ensemble". J'ai acheté le déjeuner pour nous demain et je me suis arrangé pour vous montrer cinq de nos clients utilisant notre produit.

J'ai vu des ingénieurs se tortiller sur leur siège lorsqu'ils regardaient un client utiliser le produit et se rendre compte : « Nous avons créé quelque chose d'assez difficile à utiliser et les gens en sont frustrés. Les ingénieurs veulent faire du bon travail, tout comme les designers. Souvent, ils n'ont tout simplement pas la possibilité de voir le résultat de leur travail.

Vous avez probablement entendu parler de Jeff Gothelf prêcher que nous devrions nous concentrer sur « les résultats, pas sur les sorties ». C'est une autre façon de recadrer notre réflexion, qu'un résultat est : "nous avons livré cinq fonctionnalités supplémentaires", par rapport à un résultat : "nous avons réduit le taux de désabonnement de 10 %.

Sur l'avenir de la collaboration entre concepteurs et développeurs…

Vous parlez à de nombreuses entreprises et voyez de nombreuses équipes de conception et de développement travailler ensemble. Les outils, les environnements et les méthodologies évoluent. Quel avenir pour la relation concepteur/développeur ?

Il y a de l'eau saumâtre qui se développe - lorsque l'eau salée et l'eau douce se mélangent - il y a une coalescence d'outils d'ingénierie et de conception. Au lieu d'un processus qui ressemble à un transfert où tout ce qui est design est ici et tout ce qui est ingénierie est là-bas, ils commencent à se mélanger.

Dans cette mesure, nous voyons des concepteurs passer beaucoup de temps dans Jira, penser aux user stories et commencer à penser avec un état d'esprit d'ingénierie également. Et vice versa, nous voyons des ingénieurs utiliser des outils comme InVision Inspect, où ils voient les spécifications et la décomposition d'un système de conception, et comprennent les composants de la façon dont tout cela s'emboîte. Grâce à ces outils et à un mélange de disciplines, une compréhension commune se développe.

Que vous soyez développeur ou concepteur, vous pouvez commencer à comprendre le point de vue de votre partenaire clé. Cela ne signifie pas que vous devez être un codeur expert en tant que concepteur. Mais cela ne va pas tuer un concepteur s'il sait un peu comment utiliser Git et comment écrire du HTML et du CSS, peut-être un peu de JavaScript. Cela va en fait aider les concepteurs à comprendre comment les choses sont construites et favoriser une meilleure collaboration entre concepteurs et développeurs.

Pour en savoir plus sur le blog Toptal Design :

• Comment aborder la conception pour les développeurs
• Design Talks : Recherche en action avec la chercheuse UX Caitria O'Neill
• Design Talks : Design émotionnellement intelligent avec Pamela Pavliscak
• Design Talks : la recherche d'un design basé sur la valeur avec Nick Disabato
• Comment passer de UX Designer à UX Consultant