Ceci est le pendant de « Dev ou designer. Pourquoi choisir quand on peut être les deux ? ». Cet autre article porte sur la décision de carrière. Celui-ci porte sur ce à quoi ça ressemble une fois qu'on a choisi. Les vrais avantages, les vrais défis dont personne ne vous prévient, et les pratiques de fonctionnement qui vous évitent de vous épuiser ou d'être discrètement sous-estimé.
La plupart des descriptions de poste vous demandent d'être une seule chose. Designer. Développeur. Ingénieur front-end. Chercheur UX. L'hypothèse organisationnelle est que ce sont des disciplines séparées qui collaborent via un handoff défini : le design produit des spécifications, le développement les implémente, la QA valide. Le modèle de chaîne de montage du logiciel.
Je n'ai jamais rentré proprement dans ce modèle. Je conçois l'interface puis je la construis. Je pense au comportement utilisateur pendant que j'écris du TypeScript. J'ouvre Figma et VS Code dans la même session. Pendant longtemps j'ai pensé que c'était un handicap. Que j'étais trop dispersé pour être excellent dans l'un ou l'autre. Seize ans plus tard je vois les choses différemment. Mais je ne vais pas non plus prétendre que ça a été uniformément positif. Il y a des coûts réels à ce parcours.
Les vrais avantages
Zéro friction de handoff
Le handoff design-développement est l'une des sources de gaspillage les plus coûteuses et les plus sous-estimées dans les équipes logicielles. Les designs arrivent techniquement irréalistes. Les développeurs implémentent quelque chose de légèrement différent parce qu'un détail n'était pas spécifié. Les revues font des allers-retours. Les cas limites ne sont pas couverts dans le design donc le développeur fait un choix.
Quand je fais les deux, cette friction disparaît. Je sais pendant la phase de design si une interaction est faisable et combien elle coûtera à construire. Je ne conçois pas de micro-animations qui prendront trois jours à implémenter en CSS pour un bénéfice utilisateur marginal. Je fais ces compromis en temps réel, avec le contexte complet. Le résultat : ce que je conçois, je le construis. Ce que je construis correspond à ce que j'ai conçu.
De meilleures décisions techniques
Comprendre les principes de design change la façon dont j'écris du code. Quand j'architecture une bibliothèque de composants, j'y pense aussi du point de vue d'un designer : de quelles variations l'équipe design aura-t-elle besoin ? Quels états. Vide, chargement, erreur, succès, désactivé. Chaque composant nécessitera-t-il ? Quels tokens d'espacement doivent être exposés comme inputs vs codés en dur ?
J'ai vu des bibliothèques de composants construites purement par des développeurs qui sont techniquement propres mais pratiquement inutilisables pour le design. Chaque prop est un paramètre technique, pas une décision de design. Chaque variation nécessite une modification de code. Une perspective hybride signifie que je construis avec le cas d'usage design en tête dès le départ.
Prototypage plus rapide
Quand je dois valider une idée de design, je ne la maquette pas dans Figma en attendant qu'un développeur fasse un stub. J'écris un prototype en Angular. Cela me prend à peu près le même temps que de construire un frame Figma haute fidélité, et le résultat est interactif, gère les vrais cas limites, et peut être donné à de vrais utilisateurs pour test. Le feedback que j'obtiens est beaucoup plus proche du comportement réel.
Les vrais défis
Le changement de contexte est coûteux
Les modes cognitifs du design et du développement sont véritablement différents. La pensée design est expansive. On génère des possibilités, on considère les utilisateurs, on explore des systèmes visuels. La pensée développement est convergente. On se concentre sur une implémentation correcte, on résout l'ambiguïté, on gère les contraintes.
Passer de l'un à l'autre dans la même journée est fatigant d'une manière spécifique. J'ai appris à les regrouper. Je fais le travail de design le matin quand mon cerveau est frais et plus génératif. Je fais le développement en blocs concentrés quand je me suis installé dans un mode focalisé. Les mélanger dans une même session produit des résultats médiocres dans les deux.
Être sous-évalué dans les deux camps
C'est ce que personne ne vous dit : quand vous faites les deux, certains spécialistes de chaque domaine vont subtilement déprécier votre expertise dans le leur. Les designers purs peuvent supposer que votre sens du design est compromis par le pragmatisme technique. Les développeurs purs peuvent supposer que la qualité de votre code souffre parce que vous passez du temps sur des préoccupations de design 'soft'.
J'ai été dans des réunions où un designer UX pur expliquait quelque chose sur les parcours utilisateur que je connais très bien, mais parce que mon titre dit développeur je suis positionné comme la personne technique qui a besoin d'être éduquée sur l'UX. C'est une expérience frustrante. La solution n'est pas de se battre en réunion. C'est d'établir sa crédibilité par les résultats au fil du temps. Mais ça prend plus de temps que ça ne devrait.
La question de la profondeur
Il y a des moments de doute authentique sur la profondeur. Suis-je aussi compétent en Angular que quelqu'un qui y a consacré 100 % de sa carrière ? Suis-je aussi compétent en recherche UX que quelqu'un qui s'est focalisé exclusivement dessus ? Probablement pas, en termes absolus bruts. Ce que j'ai à la place est un type de profondeur différent : la profondeur dans l'intersection. Je comprends des choses que les spécialistes de chaque côté ne voient pas parce qu'ils n'ont pas vécu dans le chevauchement.
Si cela a plus ou moins de valeur dépend entièrement du contexte. Dans une grande organisation avec des équipes design et développement dédiées, la profondeur pure peut être plus valorisée. Dans une équipe produit qui a besoin de quelqu'un capable de se déplacer rapidement sur toute la pile de la couche interface, l'hybride est souvent la personne la plus précieuse dans la pièce.
Ce à quoi ressemblait le rôle hybride chez BMO
Chez BMO, j'étais dans un rôle de Développeur logiciel senior (Angular). Mon background UX/UI se manifestait de manières spécifiques et pratiques : je soulevais les problèmes d'accessibilité dans un design avant de commencer à le construire. Je travaillais à l'intérieur du design system de la banque, qui appartenait à une autre équipe. Quand un design arrivait avec des états manquants, je les signalais proactivement plutôt que d'implémenter une spécification incomplète. Je revoyais les composants à travers un prisme de qualité de code et de cohérence visuelle.
Ce n'est pas un partage 50/50. Dans une grande entreprise, la fonction design est plus séparée. Mais le background façonne ma manière de travailler même quand je suis purement en mode développeur, et cela fait de moi un meilleur collaborateur avec l'équipe design que quelqu'un qui n'a jamais travaillé de leur côté de la table.
Tactiques opérationnelles qui comptent vraiment
Après des années à fonctionner dans cette position, voici les pratiques précises qui m'ont gardé efficace plutôt qu'épuisé. Elles sont tactiques, pas philosophiques.
- Regroupez vos modes. Le travail de design le matin quand le cerveau est génératif. L'implémentation l'après-midi en blocs, quand il est convergent. Les mélanger dans une même heure produit des résultats médiocres des deux côtés.
- Signalez votre primaire à chaque réunion. Les designers purs et les développeurs purs vont subtilement déprécier votre expertise dans leur domaine si vous ne le faites pas. Ouvrez avec ce pour quoi vous avez été embauché, puis laissez la seconde compétence apparaître à travers ce que vous attrapez et qu'ils ont manqué.
- Tenez un portfolio public qui montre les deux. La plupart des candidats montrent l'un ou l'autre. Afficher des wireframes avec leur justification à côté du code de production est le signal le plus clair que l'hybride est réel, pas aspirationnel.
- Choisissez des environnements qui récompensent le chevauchement. Les équipes de design systems, les startups produit, les cabinets de conseil boutique et les entreprises d'outils pour développeurs paieront pour l'hybride. Les grandes entreprises avec des échelles de spécialistes profondes ne le feront pas, sauf dans des rôles spécifiques comme Design Engineer ou UI Engineer.
- Limitez dans le temps l'exploration de nouveaux outils et frameworks des deux disciplines. L'hybride s'élargit plus vite que chaque spécialiste, ce qui veut dire que vous pouvez finir superficiel dans toutes les directions. Un budget strict par trimestre empêche l'exploration de grignoter la profondeur.
L'interface entre le design et le développement est là où vivent les problèmes les plus intéressants. J'ai décidé d'y vivre.
Références
- Nielsen Norman Group. From Confrontation to Collaboration: The Developer-Designer Relationship. https://www.nngroup.com/articles/developer-designer-relationship/
- IDEO. Design Thinking. https://designthinking.ideo.com/
- Smashing Magazine. Bridging the Gap Between Designers and Developers. https://www.smashingmagazine.com/2021/10/bridging-gap-between-designers-developers/